[ntp:questions] NTP offset doesn't change.

William Unruh unruh at invalid.ca
Thu Feb 12 17:19:58 UTC 2015


On 2015-02-12, Philip Homburg <philip at ue.aioy.eu> wrote:
> In article <54DB57A8.4030203 at oracle.com>,
> brian utterback  <brian.utterback at oracle.com> wrote:
>>Dr. Mills crafted a wonderful piece of software, amazing for its time,
>>but he no longer actively engages us much at all. I understand, that
>>isn't his fault. But no one who does actively engage really understands
>>it or knows how to improve it. Unruh has a point, we don't know if there
>>isn't a better way built on statistical analysis. Perhaps a hybrid
>>between the two approaches would be better still. But we don't even know
>>the consequences of changing a single constant with any degree of
>>certainty.
>
> Some time during the mid 90s, I created a new type of control loop and wrote
> an NTP implementation that uses it. In testing I verified that it is stable at
> slew rates of 100000 ppm. No need to go beyond that. 
>
> But I have no way of proving that it is correct. At the time I felt it would
> take too much energy to convince Dave Mills to adopt it, and I didn't want to
> promote a competing NTP implementation either. So I'm just running it for
> my own ammusement.
>
> If people feel a strong need to go beyond what NTP does (and are willing to
> write the specs, code, etc.) then I can try to dig out what I still have
> in this area.

chrony already does this on Linux. It uses both the fine slew and the
tickadj on adjtimex to enable slew rate up to 100000 ppm, the limit of
the tickadj.
The complaint of the ntpd people is not the stability of the machine
itself, but the stability of the network, where for example A could use
B and B use A in determining its own time. Is the whole network stable
under this kind of loop. And what happens to B when A suddenly begins to
slew at 2000PPM?
Note the "suddenly". Rarely is it the case that the drift rate of A will
suddenly change by 500PPM. But that A's clock could be stably out by
500PPM IS possible. ntpd does not differentiate between those cases. 

Also ntpd has to concern itself with cases in this it is not the kernel
that adjusts the drift, but ntp itself with its own "once per second"
internal slewing. That this takes place only once per second adds in an
additional problem. chrony does not have its own internal slew. It only
uses the kernel (adjtimex) to alter the clock rate.


>
>



More information about the questions mailing list