[ntp:questions] ntp discipline of local time?

David L. Mills mills at udel.edu
Thu Mar 27 19:13:39 UTC 2008


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.

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