Re: [Linuxptp-devel] [PATCH RFC 0/6] Transparent Clock - third and final part

[Miroslav L. <mli...@re...>]

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