On Thu, 22 Aug 2019 at 19:05, Richard Cochran <richardcochran@xxxxxxxxx> wrote: > > On Thu, Aug 22, 2019 at 05:58:49PM +0300, Vladimir Oltean wrote: > > I don't think I understand the problem here. > > On the contrary, I do. > You do think that I understand the problem? But I don't! > > You'd have something like this: > > > > Master (DSA master port) Slave (switch CPU port) > > > > | | Tstamps known > > | | to slave > > | Local_sync_req | > > t1 |------\ | t1 > > | \-----\ | > > | \-----\ | > > | \----->| t2 t1, t2 > > | | > > | Local_sync_resp /------| t3 t1, t2, t3 > > | /-----/ | > > | /-----/ | > > t4 |<-----/ | t1, t2, t3, t4 > > | | > > | | > > v time v > > And who generates Local_sync_resp? > Local_sync_resp is the same as Local_sync_req except maybe with a custom tag added by the switch. Irrelevant as long as the DSA master can timestamp it. > Also, what sort of frame is it? PTP has no Sync request or response. > A frame that can be timestamped on RX and TX by the DSA switch and master, that is not a PTP frame. > > But you don't mean a TX timestamp at the egress of swp4 here, do you? > > Yes, I do. > > > Why would that matter? > > Because in order to synchronize to an external GM, you need to measure > two things: > > 1. the (unchanging) delay from MAC to MAC > 2. the (per-packet) switch residence time > But since when are we discussing the synchronization to an external grandmaster? I don't see the connection. > Thanks, > Richard Regards, -Vladimir