[ntp:questions] Has anyone thought about this?

Terje Mathisen terje.mathisen at tmsw.no
Thu Apr 10 14:21:26 UTC 2014


Brian Utterback wrote:
> On 4/10/2014 3:22 AM, Terje Mathisen wrote:
>>
>> The maximum ntpd slew is � 500 ppm, which means that the absolute
>> maximum possible slew between UTC and the local clock would be 1000
>> ppm (i.e. the clock is maximally bad, at +500 ppm, and we are
>> currently slewing at -500 ppm), in which case the maximum error
>> component from this would be 1/1000th of the actual time delta. (In
>> real operating systems the actual errors are several orders of
>> magnitude less! Typical clock frequency adjustments due to temperature
>> cycling are in the single ppm range, but even a few tens of ppm gives
>> relative errors in the 1e-4 to 1e-5 range, which doesn't impact the
>> control loop at all.
>
> I am pretty sure that the � 500 ppm is absolute and is already the sum
> of the frequency correction and the current clock slewing. But one of

Oh sure, that is why I wrote that this is the theoretical maximum 
possible, with real-life servers being at least an order of magnitude 
better behaved.

> the reasons for having a maximum in the first place is to put a cap on
> the error introduced because if the instantaneous frequency corrections
> taking place at the time the timestamps are taken. This is all covered
> in chapter 11, Analysis of Errors, in the first edition of Das Buch
> (Computer Network Time Synchronization, Mills, 2006). I am pretty sure
> that it is also in the 2nd ed, but I don't have access to that one.

Neither do I, but I am absolutely sure Dr Mills included this error 
component in his stability and convergence calculations. :-)

If you do allow far higher slew rates, like some other programs do, then 
you would indeed have to separate the offset slew from the frequency 
correction, and use the frequency clock only to measure delta-Ts.

The easiest way to do this is of course to keep a sw delta clock around, 
this one would start out the same as the OS clock, but then only include 
any frequency adjustments to its rate, and not any slew adjustments. At 
this point either HPET or RDTSC could be used as the common frequency 
source for both clocks.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



More information about the questions mailing list