On Fri, Apr 27, 2018 at 07:40:42AM -0700, Richard Cochran wrote: > On Fri, Apr 27, 2018 at 04:06:27PM +0200, Miroslav Lichvar wrote: > > 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? > > I must have misunderstood you. The TC must correct the residence > time. The question is whether to apply the frequency correction to > the residence times reported in the correction field.
Ok. I probably misread your earlier mail and thought the TC doesn't touch the correction field on start. > I thought you meant that the TC should drop packets until it has > measured the frequency offset. Because the error in the residence > time is so small when free running, I think it better to simply apply > the frequency correction to the residence time when it becomes > available (two or four seconds after the TC boots). I just think it would be cleaner to wait for the frequency to be known before forwarding PTP messages, unless it breaks the protocol or has some other problem. It's like a boundary clock, which waits for its clock to be synchronized before switching its ports to the master state. It probably doesn't matter that much. -- 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
