[ntp:questions] NTP roadmap (was Re: Poul-Henning Kamp and re-write of NTP)

William Unruh unruh at invalid.ca
Tue Dec 9 18:12:32 UTC 2014


On 2014-12-09, Harlan Stenn <stenn at ntp.org> wrote:
> William Unruh writes:
>> On 2014-12-09, skillzero at gmail.com <skillzero at gmail.com> wrote:
>>> On Sunday, December 7, 2014 7:25:01 PM UTC-8, Harlan Stenn wrote:
>>>> Rob writes:
>>>>> It has been discussed before that reference clock drivers should be
>>>>> loadable modules or even separate processes.
>>>> 
>>>> A complete rewrite of the full NTP software is slated for post-4.2.8.
>>>> 
>>>> We're expecting (the names might be changed):
>>>> 
>>>> - tsc - Time Sync Client: a leaf-client.  PHK is working on this.
>>>
>>> Are there any plans to incorporate ideas from RADclock? The PLL that
>>> PHK mentions on his site implies a feedback model. I'm wondering if
>>> any thought has been given to a feed forward design (e.g. determine
>>> frequency based on raw ticks). Or was that model considered and
>>> rejected?
>> 
>> Why would one want feedforward? You surely want the system to correct
>> the errors in the local clock, and those are not constant or
>> predictable. Temperature, crystal aging, maybe even computer load and
>> voltages will all affect the clock in undetermined and undeterminable
>> ways. 
>
> Bill, have you read about RADclock?

No. I just looked at it quickly. I am not sure I would call it
feedforward, but at least it tells me what was meant by the use of the
term in this context. 
There are aspects of chrony which could then also be called feedforward
but it is at best a mixed system. I agree with the authors that it would
require extensive kernel changes, and would also make getting time from
the kernel slower-- you (or the kernel) has to post process the
measurements much more to deliver a time it would seem to me. 

>
>> It would seem to me that the key parameter is the reach of the
>> feedback-- does one only use the current error to correct the system,
>> or does one use a longer stretch of errors to correct the system. The
>> latter allow one at least in part to separate the random influences
>> from the uniform errors-- the random errors get knocked down by the
>> averaging of the fluctuations. Exactly which is best for time control
>> still needs more study, but as mentioned, in the comparison of ntpd
>> (PLL) and chrony (regression) it seems as if chrony wins in its speed
>> of response to outside influences and in its ability to control the
>> clock to track UTC.
>> 
>> But I guess we all have our favourites.
>
> Yes, and your/chrony's definition of "best time" isn't the same as the
> one NTP uses.
>
> If you use NTP's model, NTP keeps better time than chrony.
>
> If you use chrony's modle, it keeps better time than NTP.

I do not know what these models are. I call keeping good time, the
comparison of the time offered by the system clock with an independent
good time source. Ie, I used a gps pps to look at the time variation
given by both ntpd and chrony using a local network time negotiation
with another stratum 1 pps server as the source. And the offsets of the
system time disciplining the system clock from a pps source. 
What definitin of "better" do you use?

Would you also say that radclock delivers worse time than ntpd under
ntpd's model? (Note using NTP for ntpd is a bit confusing since ntp is
primarily a time exchange protocol, and has no model)




More information about the questions mailing list