Hi Richard and Jacob, The most interesting is that on RHEL7 the 36 second offset occurs after the tx_timestamp_timeout error and after that the offset only drifts further away. (After staying ‘synchronised’ in the 36xxxxxxxxx range for a little of time)
I had tried the exact same thing between two HP Z440 PC’s (including the exact same Ethernet adapter + driver) running Ubuntu (instead of RHEL7). The tx_timestamp_timeout erorr occurred also on this slave server when pushing an .iso of +-5GB over the Ethernet line, except it didn’t got an offset of 36 seconds, and it even re-synchronised after a while, while the RHEL7 slave only drifts further away when pushing a lot of network traffic from that PTP slave server over the network. Jord On 10 Aug 2018, at 17:11, Keller, Jacob E <[email protected]> wrote: >> -----Original Message----- >> From: Richard Cochran [mailto:[email protected]] >> Sent: Thursday, August 09, 2018 6:16 PM >> To: Keller, Jacob E <[email protected]> >> Cc: Jord Pool <[email protected]>; Cliff Spradlin via Linuxptp-users >> <[email protected]>; Chris Caudle <[email protected]>; >> Cliff Spradlin <[email protected]> >> Subject: Re: Fixing offset jump at reset? >> >>> On Thu, Aug 09, 2018 at 07:10:44PM +0000, Keller, Jacob E wrote: >>> Would it make more sense to have some "timecounter_reset()" function, >> which uses the current nsec value and just resets the internal cycles? Then, >> as >> long as the timecounter was updated as close as possible to before the >> hardware >> reset, we'd only lose a few cycles, instead of getting the UTC/TAI >> conversion. >> >> I guess it makes some kind of sense. BUT still the new time will be >> wrong. And now it will be subtly wrong. Maybe that would be even >> more harmful, because it degrades the time quality while papering over >> the driver/HW issues. >> >> Thanks, >> Richard > > I'm just thinking in terms of the fact that if a reset occurs, that hardware > will simply have the wrong time now. It's faster for ptp4l to recover from a > small offset, than it is for it to recover from a 36second offset. > > Hmm.. I suppose one could argue "why is it resetting in the first place" > though. Perhaps the driver is being overly aggressive about the reset, or > "resetting" ptp functionality even when it didn't have a proper hardware > reset. > > Thanks, > Jake > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Linuxptp-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/linuxptp-users ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-users
