> -----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
