[ntp:questions] ntp discipline of local time?

Unruh unruh-spam at physics.ubc.ca
Wed Mar 26 22:48:33 UTC 2008


"David L. Mills" <mills at udel.edu> writes:

>Bill,

>You are going about this the wrong way. The discipline has its own 
>chapter in my book, but you might not want to go there. An appendix of 

I finally did order your book, but it will take a while to get here. 

>rfc 1305 discussed it in a primitive way. The Clock Discipline 
>Principles and Precision Time Synchronization briefings on the NTP 
>project page are old but applicable. The details you are asking for are 
>carefully explained in the NTPv4 spec.

Thanks. 1305 is just the start I want. 
Where is the NTPv4 spec located?

>Notice the second-order transfer function given both in my book and rfc 
>1395 hss components of both phase and frequency. So the proper question 
>for you to ask is whether the implementation faithfully computes that 
>function. I claim it does and confirm by empirical verification of the 

I am willing to believe, barring contrary evidence, that your faithfully
implimented the protocol. (and that the Linux people faithfully implimented
the protocol in the kernel discipline routines).

I am still trying to get a handle on why ntp has much worse behaviour than
chrony does. I think I understand the chrony model ( although I would like
to find somewhere where the raw adjtime ( not adjtimex) routine (or should
I say the adjtimex SINGLESHOT routine) works. 

Anyway, thanks.


>impulse response as reported previously, both for the kernel and for the 
>daemon. For the same time constant they both have the same response.

>Dave

>Bill Unruh wrote:

>> "David L. Mills" <mills at udel.edu> writes:
>> 
>> 
>>>Unruh,
>> 
>> 
>>>The kernel discipline is almost identical to the daemon discipline with 
>>>the exception that the fancy code to combine the PLL and FLL near the 
>>>Allan intercept is absent. Without the PPS signal, the discipline 
>>>behaves as a second-order loop; with the PPS it behaves as two separate 
>>>first-order loops, one for phase, the other for frequency. When 
>>>necessary to set the freque directly, ther kernel is use for that. Note 
>>>that the peripheral functions, like the clock state machine and 
>>>poll-adjust algorithm continue in the daemon.
>> 
>> 
>> OK, I have now gazed at the code some more, and see where the information
>> is passed to the kernel discipline. But I am still confused. The discipline
>> does two things-- set the system clock frequency (ie adjust the conversion
>> factor from CPU cycles to time) and get rid of the offset. I am having a
>> hard time figuring out exactly how it does the former. The later I
>> understand is done by driving the offset to zero over a time scale
>> something like 16 times the poll interval. But I do not understand the
>> former. I think it looks something like
>> 
>> F'=F+(offset)/constant. 
>> But I cannot figure out where this is actually done, and what that constant
>> is. 
>> Thus, if you feed the system with an offset, the time goes like
>> 
>> t=(F'T +offset (1-exp (T/C))
>> where t is the clock time, T is the "raw" time,(CPU cycles) ,C is some
>> constant like 16 times the poll interval, 
>> 
>> Bill
>> 
>> 
>> 
>> 
>>>Dave
>> 
>> 
>>>Unruh wrote:
>>>
>>>>David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:
>>>>
>>>>
>>>>
>>>>>Unruh wrote:
>>>>>
>>>>>
>>>>>>How does ntp actually discipline the local clock? I have a gps received
>>>>
>>>>
>>>>>If you are using the kernel time discipline, which you should be using 
>>>>>for high accuracy, nptd doesn't discipline the clock; it is the kernel 
>>>>>code that does that, based on measurements provided by ntpd.
>>>>
>>>>
>>>>I do not think that this is right, unless you are referring to  a PPS
>>>>sounce. ntp sets the frequency of the kerhel clock (Is that change in
>>>>frequency what you mean by kernel time discipline) by a very simple second
>>>>order PDE feedback, and the offset by and exponential first order feedback
>>>>scheme. At least that is what it looks like to me trying to read
>>>>ntp_loopfilter.c
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>attached to a computer which is disciplined by a remote clock over an ADSL
>>>>>>line. (Ie, the gps does not act as a refclock -- it is purely to measure
>>>>>>the actual offset of the system. It is only the remote server that actaully
>>>>>>acts the ntp reference source.)
>>>>>>I can watch how ntp alters the local clock in response to remote
>>>>>>offsets. The response is not linear. rather it is "curved" as though the
>>>>>>rate of the local clock were exponentially eliminating the offset. But this
>>>>
>>>>
>>>>>That sounds very plausible. The clock discipline code solves for both 
>>>>>frequency and phase errors.  The phase error is probably being filtered 
>>>>>using an IIR filter, and that is what you are seeing, and also the 
>>>>>mechanism ntpd uses to stop wandering off if it stops receiving updates 
>>>>>(the frequency measurement error can produce unbounded phase errors, but 
>>>>>the phase error correction is bounded).
>>>>
>>>>
>>>>
>>>>>>is between two succesive runnings of the loopstats. Where is this behaviour
>>>>>>determined? -- ie which routines determines the response of the system
>>>>>>between to successive measurements of the offset?
>>>>
>>>>
>>>>>If you don't use the kernel discipline, on Unix-like systems, it will 
>>>>>implement the same filters in user space and apply phase adjustments at 
>>>>>each kernel update.  For ntpv3, those updates were every 4 seconds; for 
>>>>>ntpv4, I believe it does them every second.  A normal Unix-like system 
>>>>>will implement the phase change by increasing or decreasing the amount 
>>>>>by which the software clock is updated for every tick by +/- 500ppm, 
>>>>>until the adjustment is complete.
>>>>
>>>>
>>>>It is the linux system I am interested in. It looks to me like it adjusts
>>>>the frequency with a simply second order feedback loop  using the
>>>>ntp_adjtime system call, and then drives the
>>>>offset to zero with an exponential run once a second (?? I cannot
>>>>disentangle the code to really be sure of this) using the adjtime system
>>>>call. That exponential has a huge time constant-- something like 16 times
>>>>the poll interval.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Windows has a different kernel interface, and I believe that ntpd 
>>>>>modulates the effective length of a tick.
>>>>
>>>>
>>>>>Note, in spite of what other replies may imply, the physical clock 
>>>>>frequency is never actually changed; what is actually changed is the 
>>>>>amount by which the software clock is incremented for ever n-cycles of 
>>>>>whatever is used for the reference frequency.
>>>>
>>>>
>>>>Of course. There is no way that the physical clock can be influenced by
>>>>software. The system simply changes the relation between harware cpu cycle
>>>>counts and time. 
>>>>
>>>>
>>>>
>>>>
>>>>>If you want the actual code and fine details, you will be able to find 
>>>>>them as easily as I will, so I'll leave that as an exercise for the reader.
>>>>
>>>>
>>>>I guess I was hoping that perhaps the person/people who actually wrote the
>>>>code could tell me what was going on in the code. While the code is
>>>>reasonably annotated, those annotations do not give me at least a good
>>>>sense of the overall picture. 
>>>>
>>>>
>>>>
>>>>
>>>>




More information about the questions mailing list