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

[[e-mail]]

I agree with the faction who believes that things like temperature correction should be outside of a document whose main focus is the on-wire protocol part of NTP (be it version 4 or 5)

I would also prefer it if the on-wire protocol and any algorithms deriving offset/correction data from it would be split into different documents, with potentially a third one for the actual techniques used for clock disciplining.

This would mean quite a lot of work in the short term, such as defining interfaces for what the single modules need from one another. 

But I think the clarification would be worth it (for example, it would create a place where integrating temperature corrections makes sense).

Best regards,

Kristof

-----"ntp" <[e-mail]> schrieb: -----

An: "[e-mail]" <[e-mail]>
Von: "FUSTE Emmanuel"
Gesendet von: "ntp"
Datum: 09.12.2020 10:55
Betreff: Re: [Ntp] Antw: [EXT] Re: Temperature Compensation for NTP?

Le 09/12/2020 à 08:05, Ulrich Windl a écrit :
>
> As said before, I think describing the protocol without the algorithms and clock model behind does not make sense, and when describing the clock model, one has to explain where clock wander and error estimate mainly comes from.
> Also one of the design goals of NTP has been to provide "reasonalbe" time and error estimate even when there are no servers available and to lengthen the polling interval. I think considering the temperature (optionally), can help improving those capabilities, so why ignore?
>
Because improving capabilities of the oscillator is not the NTP job. NTP
algorithm is a consumer of those capabilities, we should have way to
provide these capabilities to the NTP algorithm but it is not the job of
NTP to interfere with them.
Chrony implement poor man temperature compensation, great. But if I use
TCXO or OCXO considering the temperature (and which one ?) is non sense.
And I could even implement this basic crystal TC in a kernel driver for
better integration with the timekeeping machinery and interface for the
same result, NTP is completely out of the picture.
If I know the aging curve I could implement it too in this same driver
or in chrony to better free running precision.
An oscillator could characterized by stability temp stability in ppm/c,
Alan variance, phase noise, aging curve and more.
For sure, only a metrology lab or the oscillator maker could give you
the characteristics of an oscillator and on most hardware and computers,
the oscillator spec are not provided or know.
NTP appliance provider job is to use such advanced oscillators and
compensation technique to provide better global characteristics and be
better clock source for serving NTP.
The job of NTP is to steer the system clock and so possibly the
underlying oscillator in one way and to provide measurements in the
other way.
So the only question is : what property/characteristics/metric of the
underlying oscillator/clock the NTP servo/clock model need to do its job
better rather than default values ?
With the modern granularity and precision of measurements thanks to HW
time stamping availability and oscillators quality, the spectrum of
possibility is too wide for hard coded good for all default values.

Regards,
Emmanuel.
_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp