On Fri, Jun 24, 2022 at 03:50:46PM +0200, Martin Pecka wrote: > 38000 ns. But when I turn filling the corrections on, it seems linuxptp is > really struggling to understand what is going on. The master offset always > oscillates in the order of millions, as well as the estimated path delay. > What can be a reason for this happening? I'm testing this with default.cfg, > and also with our customized "Automotive profile with E2E delay mechanism". > Both behave the same in this regard. The testing setup consists of two > computers connected via the switch, each computer having a > hardware-timestamping-capable NIC.
Interesting issue. To me that sounds like a synchronization loop, e.g. the server or the switch is somehow synchronizing to the client. If you compare packet captures with the TC disabled and enabled, is the only difference in the correction field? On both the server and client side? Can you try it with software timestamping and also the free-running mode? > The only idea I came with is that the computers are two-step clocks, while > the switch behaves as one-step clock. But I thought this does not matter to > the PTP protocol. That shouldn't matter. The switch should forward unmodified follow-up messages. -- Miroslav Lichvar _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
