> -----Original Message----- > From: Richard Cochran [mailto:richardcoch...@gmail.com] > Sent: Thursday, August 09, 2018 6:16 PM > To: Keller, Jacob E <jacob.e.kel...@intel.com> > Cc: Jord Pool <jord.p...@outlook.com>; Cliff Spradlin via Linuxptp-users > <linuxptp-users@lists.sourceforge.net>; Chris Caudle <ch...@chriscaudle.org>; > Cliff Spradlin <csprad...@waymo.com> > 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 Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
