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

[Ulrich Windl <[e-mail]>]

>>> Magnus Danielson <[e-mail]> schrieb am 09.12.2020 um 14:25 in
Nachricht <[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 ;-)

> 
> What we can do is to refactor the lockin mechanisms, because it can be
> made more robust and also overcome problems with incorrect offset files,
> that may rended intermediary nodes and client nodes problematic. That
> would still not be part of the core protocol, but may be relevant as a
> side protocol.
> 
> Cheers,
> Magnus
> 
> On 2020-12-09 13:04, [e-mail] wrote:
>> 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] <mailto:[e-mail]>>
>> schrieb: -----
>> An: "[e-mail] <mailto:[e-mail]>" <[e-mail] 
>> <mailto:[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] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/ntp 
>> <https://www.ietf.org/mailman/listinfo/ntp>
>>
>> _______________________________________________
>> ntp mailing list
>> [e-mail] 
>> https://www.ietf.org/mailman/listinfo/ntp