[ntp:questions] ntp discipline of local time?

Unruh unruh-spam at physics.ubc.ca
Thu Mar 27 23:31:03 UTC 2008


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

>Unruh,

>The NTPv4 spec is an Internet Draft and can be found in the usual way. 
>It can also be found on the NTP project page 
>www.eecis.udel.edu/~mills/ntp.html. Look for NTPv4 specification project 
>documents.

Thanks
Bill


>Dave

>Unruh wrote:
>> "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