[ntp:questions] ntp discipline of local time?

David L. Mills mills at udel.edu
Tue Mar 25 19:28:14 UTC 2008


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.

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