Re: [Ntp] Antw: Re: Antwort: Re: Antw: [EXT] Re: Temperature Compensation for NTP?

[Magnus Danielson <[e-mail]>]

Warner,

On 2020-12-09 17:33, Warner Losh wrote:
>
>
> On Wed, Dec 9, 2020 at 7:37 AM Magnus Danielson <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Ulrich,
>
>     On 2020-12-09 14:45, Ulrich Windl wrote:
>     >>>> Magnus Danielson <[e-mail]
>     <mailto:[e-mail]>> schrieb am 09.12.2020 um 14:25 in
>     > Nachricht <[e-mail]
>     <mailto:[e-mail]>>:
>     >> Hi,
>     >>
>     >> In a similar notion, I do not see temperature compensations to be
>     >> anything but local clock maintenance. This can be done in so
>     many ways
>     >> that I do not think it will be useful to clutter core mechanism
>     >> descriptions with it. There can be hardward compensations
>     already in the
>     >> use of temperature compensated oscillators (TCXO) or oven stablized
>     >> oscillators (OCXO) or even atomic reference based. You can also do
>     >> software based compensation from trivial simple to advanced
>     self-tuning.
>     >> That would still not relate to the core mechanisms of NTP. You may
>     >> benefit from feeling the correct time from NTP as you do such
>     training,
>     >> but just like the oscillator offset file, it's a local issue,
>     until it
>     >> isn't because it failed, and I've seen such cases with NTPv4.
>     > OK, convinced ;-)
>
>     Great! :-)
>
>
> You'd only need to include it if it were to affect the core mission of
> NTP: exchanging time and frequency measurements. Since it doesn't do
> that in any meaningful way, it likely should be omitted from the
> protocol doc.
I would agree, but your statement would need further qualifications. If
you look carefully, you will see that source, intermediary and client
nodes will get degraded performance. Some of it is tracked in by NTP,
but you get more dynamics from a bad clock. So, that will reduce the
performance in terms of stability. But this is not directly to the
protocol itself, but parameter setting, just as it is for say a GPSDO as
the optimum balance point differs depending on the noise of the local
oscillator. It can be understood by the low-pass filtering of the
reference (and that include the additional noise as picked up from the
network) and the high-pass filtering of the local oscillator. The better
local oscillator, the higher tau for cross-over point and better overall
performance can be found. Typically this is better analyzed in the
phase-noise domain rather than ADEV domain, but it aims to achieve the
same thing and differences between analysis is small. NTP builds it's
analysis on the ACTS analysis of Judah Levine, while I think the
behavior of the NTP noise differs from that of the original ACTS system.
For NTP it is the "Allan intercept point" scheme. But, to challenge that
I think may be rocking the boat a little too much in the short term. So,
technically we need to confine how far we go, and I think we should not
go much further than making some notes in the RFCs about quality of
oscillator will have impact of performance.
>
> It falls into the large bucket of 'local errors'. Your local
> oscillator will have some error to how true it is. Temperature
> compensation tries to reduce that error. It will also have errors as
> well, so it will affect the stability of the local clock (for good or
> for ill). But that's on the same magnitude, one would hope, as diurnal
> environmental changes. So it won't put the quality of the local
> oscillator outside the bounds that NTP assumes are in place. Those are
> the more important things to have in the document: what's the error
> tolerance of this system (and possibly reporting a local system's
> estimated error bars). How a local system accomplishes this should be
> up to the local system.

Yes, but we need to say it as it is, you get what you pay for. Poor
design will behave worse than good design. We can make no real
assumption of how bad or good things can be. For instance, if you have
hardware time-stamping in your NTP, yes that exists, then you get much
better node performance too. We do not write anything about hardware or
software time-stamping, it is kind of assumed. It will however affect
performance. The actual diurnal environmental properties of the actual
link is fairly small. Variations due to heating and AC can be much worse
as acting on the local clock. Local clock may be worse than +/- 100 ppm
and that says that there is no temperature compensation. The local clock
may be an oscillator sitting near CPU and other components which have
forced cooling and high dynamics in how much heat they produce. You
milage will vary on that one.

So, we should not dwell too much into these details in the protocol
design, but we should allow for flexibility in polling rate as means to
achieve flexibility that may be needed to encompass different oscillator
stability challenges. If people fancy informational material, that can
be provided to the side of the core protocol documents, and I would be
in support of doing that, to guide implementers and users to an
understanding.

So, now comes the question of how to nicely scope the parameter freedom
that we might want to allow for in relation to this.

To complex the issue, there is other concerns relating to polling rate
that one could consider, but I think that it would be outside the scope
of a quick resolution.

Cheers,
Magnus