On Fri, Apr 27, 2018 at 06:41:49AM -0700, Richard Cochran wrote: > On Fri, Apr 27, 2018 at 03:24:48PM +0200, Miroslav Lichvar wrote: > > I think that might be even worse than making inaccurate corrections > > with zero frequency offset. If a TC and slave are (re)started at the > > same time, the slave's initial correction may have a large error, > > which will need to corrected later (when steps may already be > > disabled). It will also disrupt the slave's frequency estimate if the > > TC starts correcting the messages before the slave's estimation > > interval ends. > > So lets consider the magnitude of the error. On a switch based system > on my desk, the residence time is about 2 milliseconds. (This is > rather large because the timestamps come over MDIO). The frequency > offset is typically about 30 ppm, and so the induced error is 60 > nanoseconds.
That's for the case when the TC starts correcting messages immediately, just not having the correct frequency offset yet, right? If the TC doesn't make any corrections after start, the error is the residence time. With heavy network traffic the delays can be in tens of milliseconds or maybe even more? > Using HW time stamping, such small offsets are corrected at the slave > in a few seconds using small frequency adjustments. I think that depends on the servo and its configuration. A slave with a stabilized clock could very well use a much slower servo than the default PI in ptp4l. A 10 millisecond error measured over 10 seconds is 1000 ppm. That could take a while to correct. I'm wondering how do real switches with TC support behave on start. -- Miroslav Lichvar ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
