Subject: [Ntp] Temperature Compensation for NTP?

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 08 Dec 2020 10:35:45 +0100

Hi!

The avarage computer oscillator is mainly controlled by temperature. Up to now NTP does not have a computational model to consider the temperature nearby the oscillator, while most modern systems have some temperature sensor(s).
In contrast chrony has a "tempcomp" configuration directive that allows to consider the environmental temperature. Just two short quotes from the manual page:

           The frequency compensation is calculated (in ppm) as

               k0 + (T - T0) * k1 + (T - T0)^2 * k2

           An example of the use is:

               tempcomp /sys/class/hwmon/hwmon0/temp2_input 30 26000 0.0 0.000183 0.0

Should NTPv5 have such a (similar) capability?

Regards,
Ulrich

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 8 Dec 2020 11:00:15 +0100

> The avarage computer oscillator is mainly controlled by temperature. Up to now NTP does not have a computational model to consider the temperature nearby the oscillator, while most modern systems h…

I don't see how this is related to NTP. Is the current specification
preventing servers or clients from implementing a software temperature
compensation?

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Tue, 08 Dec 2020 03:30:10 -0800

> Should NTPv5 have such a (similar) capability?

My opinion.  No.

I think we should separate the protocol description from the implementation 
details.

-- 
These are my opinions.  I hate spam.

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 8 Dec 2020 13:04:44 +0100

> Should NTPv5 have such a (similar) capability?

I'm not sure what you're asking. This just seems to be an
implementation detail. You apply a correction, and as a result,
hopefully, your maximum error should get smaller. I don't see
how it's relevant for the protocol.

Should the RFC also cover which corrections you can all apply, and
how that has an effect on the values you send to the client? There
is at least a proposal where that would be outside the scope.

Kurt

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 08 Dec 2020 16:06:46 +0100

>>> Miroslav Lichvar <[email-masked]> schrieb am 08.12.2020 um 11:00 in
Nachricht <20201208100015.GU2352378@localhost>:
>> The avarage computer oscillator is mainly controlled by temperature. Up to

> now NTP does not have a computational model to consider the temperature 
> nearby the oscillator, while most modern systems have some temperature 
> sensor(s).
> 

If the protocol standard does not specify a clock model, I'm fine. However
(e.g.) the increase of dispersion (which is way too large IMHO) will mostly
depend on the environental stability. So to get that value right or atr least
close, one would have to take temperature effect into account.
Or alternatively: Quickly explain how the increase of dispersion was
determined ;-)

Regars,
Ulrich

> ‑‑

---

From: Philip Prindeville <[email-masked]>
Date: Tue, 8 Dec 2020 10:29:14 -0700

> On Dec 8, 2020, at 5:04 AM, Kurt Roeckx <[email-masked]> wrote:
> 

I think what Ulrich is pointing out is that the specification, rather than calling out specific requirements for the algorithm, actually specifies a/the algorithm, at least in v4.

Given we have better understanding now of the thermal stability of solid state (crystal) oscillators, why not include that into the algorithm if we’re going to flesh it out specifically?

---

From: Hal Murray <[email-masked]>
Date: Tue, 08 Dec 2020 13:44:21 -0800

[email-masked] said:
> Given we have better understanding now of the thermal stability of solid
> state (crystal) oscillators, why not include that into the algorithm if we’re
> going to flesh it out specifically? 

I think the algorithm(s) should be split out to a separate document, if any.

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 8 Dec 2020 13:50:52 -0800

> I think the algorithm(s) should be split out to a separate document, if any.

In which case somebody will only implement the protocol and do whatever
they want with the algorithms, and clients will connect to this server
and there will be a significant chance that because of the different
algorithms, the behavior will be different and there will be train wrecks.

We've already seen what happens when people put leap smearing servers on
the public internet, and somebody says "Oh, I got bitten by not having
enough servers last time, so I'll use 4 now" and then the learned that
during the next leap event two of their upstreams offered correct time
while 2 offered smeared time, so "no consensus" on time and off they went.

Different timing algorithms will cause much bigger problems.

NTP is all about a defined impulse response.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 8 Dec 2020 23:31:26 +0100

On Tue, Dec 08, 2020 at 01:50:52PM -0800, Harlan Stenn wrote:
> >> state (crystal) oscillators, why not include that into the algorithm if weâ€™re

I think we should not say how it should be implemented, but explain what
is expected of what is put in all the fields. For instance, it
should explain how to calculate the errors, and what you
optionally do to minimize the errors.

> NTP is all about a defined impulse response.

I think defining NTP as a impulse response is the wrong approach.
It's an implementation detail. If other systems use different
algorithms, it should only have an effect on the uncertainty. If
it causes big problems, it's an implementation problem.

Kurt

---

From: Hal Murray <[email-masked]>
Date: Tue, 08 Dec 2020 15:32:26 -0800

Harlan Stenn said:
>, the behavior will be different and there will be train wrecks.

One man's train wreck is another man's innovation.

How do I decide if I'm allowed to implement a feature/idea that isn't 
mentioned in the RFC?  Temperature compensation is the obvious example.

> NTP is all about a defined impulse response.

Then an RFC should describe the constraints, not bury it as an obscure 
parameter hidden deep inside an algorithm.

[email-masked] said:
> I think defining NTP as a impulse response is the wrong approach. It's an
> implementation detail. If other systems use different algorithms, it should
> only have an effect on the uncertainty. If it causes big problems, it's an
> implementation problem. 

Not quite.  It's easy to get problems when chaining PLLs.  I don't understand 
it well enough to explain and I don't have a handy reference.

The typical problem is that somebody tweaks a time constant so his system 
recovers faster, then months later something crazy happens when triggered by 
the right input data.

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 09 Dec 2020 08:05:04 +0100

>>> Hal Murray <[email-masked]> schrieb am 08.12.2020 um 12:30 in
> I think we should separate the protocol description from the implementation 

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?

Regards,
Ulrich

---

From: FUSTE Emmanuel <[email-masked]>
Date: Wed, 9 Dec 2020 09:55:15 +0000

> 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 t…
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.

---

From: [email-masked]
Date: Wed, 9 Dec 2020 13:04:27 +0100

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" <[email-masked]> schrieb: -----

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

Regards,
Emmanuel.
_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 9 Dec 2020 14:25:52 +0100

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.

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, [email-masked] 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" <[email-masked] <mailto:[email-masked]>>
> schrieb: -----
> An: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> Von: "FUSTE Emmanuel"
> Gesendet von: "ntp"
> Datum: 09.12.2020 10:55
> > 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?
> >
> [email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/ntp>
>

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 09 Dec 2020 14:45:23 +0100

>>> Magnus Danielson <[email-masked]> schrieb am 09.12.2020 um 14:25 in
> isn't because it failed, and I've seen such cases with NTPv4.

OK, convinced ;-)

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 9 Dec 2020 15:37:40 +0100

Ulrich,

>> isn't because it failed, and I've seen such cases with NTPv4.

Great! :-)

Cheers,
Magnus

---

From: Warner Losh <[email-masked]>
Date: Wed, 9 Dec 2020 09:33:16 -0700

> >> isn't because it failed, and I've seen such cases with NTPv4.

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.

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.

Warner

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 9 Dec 2020 20:45:46 +0100

> recovers faster, then months later something crazy happens when triggered by 

As far as I know, NTP's impulse response overshoots to have a
faster response. And gettings a chain to work with overshooting
complicates things, because it's possible that each next host
overshoots more. As I understand that, to avoid that problem,
NTP does not tell what it's best estimate of the time is, but
slowly moves to that time.

Kurt

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 9 Dec 2020 23:05:36 +0100

Warner,

On 2020-12-09 17:33, Warner Losh wrote:
>
>
> On Wed, Dec 9, 2020 at 7:37 AM Magnus Danielson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Ulrich,
>
>     >>>> Magnus Danielson <[email-masked]
>     <mailto:[email-masked]>> schrieb am 09.12.2020 um 14:25 in
>     > Nachricht <[email-masked]
>     <mailto:[email-masked]>>:
>     >> Hi,
>     >>
> 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

---

From: Philip Prindeville <[email-masked]>
Date: Wed, 9 Dec 2020 15:16:08 -0700

It also makes it a lot easier to incrementally obsolete parts of the protocol, algorithm, etc. without having to rewrite everything from scratch…

> On Dec 9, 2020, at 5:04 AM, [email-masked] wrote:
>

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 9 Dec 2020 23:34:15 +0100

Warner Losh wrote:
> 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.

I think the way the control loop works depends strongly on the target
system, and on the application.

On the target system there can be an oscillator that can be precisely
disciplined, e.g. via a control voltage, or a simple XTAL with a fixed
frequency which varies more or less with the ambient temperature.

Also, different target systems may provide different API calls to apply
corrections from the control loop, which can be more or less precise.
See for example Unix vs. Windows.

Finally there may be systems that require a very stable frequency, or
where the frequency can not be directly adjusted. On these systems you
have to insert or delete oscillator clock ticks to adjust the length of
a second of the system time, or compensate a time offset.

On other systems you can really increase or decrease the oscillator
frequency until the time offset becomes as small as possible. The
maximum allowed frequency offset also determines how long it takes until
a time adjustment is applied.

So IMO there is not a single "best" solution for a control loop.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 10 Dec 2020 08:56:27 +0100

>>> Kurt Roeckx <[email-masked]> schrieb am 09.12.2020 um 20:45 in Nachricht
<[email-masked]>:
> On Tue, Dec 08, 2020 at 03:32:26PM ‑0800, Hal Murray wrote:
>> [email-masked] said:

I'm not deep in that subject, but couldn't a non-overshooting response be
compensated by feeding samples at a higher rate (smaller "poll")?

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 10 Dec 2020 20:39:08 +0100

Hi,

> compensated by feeding samples at a higher rate (smaller "poll")?

Ooo... this is tricky.

As you change the poll rate in a control loop, you effectively change
the loop gain. As you change the loop gain, you need to alter the
control loop parameters to compensate.

Changing the poll rate single-mindedly will be very dangerous, the right
way to do it is to have the loop parameters scaled with the poll-rate as
needed to maintain loop properties.

If you do a simple PI-loop for instance, now this is from the top of my
memory so it may not be 100% correct, which is what should be there in
the first place, you need to scale the P and I paths differently. If you
scale those with poll-rate as needed, you can control the damping of the
loop trivially through scaling of the P.

So, the P factor will be proportional to the PLL bandwidth f0 and
damping factor d, and anti proportional to the poll-rate fp

P = Kp * f0 * d / fp

The I factor will be proportional to the squared f0 and
anti-proportional to fp as in

I =  Ki * f0^2 / fp^2

Where Kp and Ki is fixed gain constants.

If you try to regulate on the poll rate fp you will scale the PLL
bandwidth also, which is not what you want, and you will change the
damping factor, which was what you attempted to control.

Instead, scaling the parameters properly you can choose a damping factor
and the other parameters can be chosen independently.

Besides, doing a proper PI loop calls for a very simple and
well-understood mechanism that is guaranteed to lock up and be
well-behaved. Core loop code is

Vd = Vref - Vosc
Vi = Vi + Vd*I
Vf = Vi + Vd*P

Vosc is the phase of the phase-accumulator being controlled, and Vf is
the update frequency control. The integrator of the Vi will pull
detected phase Vd to 0 and the Vd*P will only handle the AC-path for
dynamics, which is where the damping properties resides.

In practice one has a scaling factor for Vf in many applications, but
that is more an implementation issue. Also you typically add a fixed
offset so that initial state can be to drive I to 0.

Doing this, changing the poll-rate will only control the rate at which
measurements are done, and that have other implications, but it should
never be used to control overshoot, that would be result of bad design.

Also, you want a damping factor of at least 3.

Cheers,
Magnus

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 10 Dec 2020 21:09:27 +0100

> compensated by feeding samples at a higher rate (smaller "poll")?

I'm not sure what you mean with compensated.

If you have a higher sample frequency with the same impluse resonse,
you will also faster change your phase to match. The same impulse
response at different sample frequency means that it takes the
same amount of samples.

Note that if you want the same impulse response at different
sample frequencies, you need different feedback parameters.

So with a damped / undershooting response and a higher sample
frequency you can have a faster response.

Kurt

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 11 Dec 2020 08:52:47 +0100

>>> Kurt Roeckx <[email-masked]> schrieb am 10.12.2020 um 21:09 in Nachricht
> On Thu, Dec 10, 2020 at 08:56:27AM +0100, Ulrich Windl wrote:

...
> I'm not sure what you mean with compensated.

I mean the time until the offset is below a specific threshold.
In my simple memory there exists one parameter that is the highest that does not cause overshoot; I'd consider that to be the optimal parameter.

> you will also faster change your phase to match. The same impulse

Yes, Intended.

> response at different sample frequency means that it takes the

Guessed so.

> frequency you can have a faster response.

...without overshoot. So what are the drawbacks?

Regards,
Ulrich