[ntp:questions] ntp discipline of local time?

Bill Unruh unruh at physics.ubc.ca
Wed Mar 26 10:49:33 UTC 2008


"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