[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,
>>
>>
>> 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.
>>
>>
>>
>>
>>>>

```