Re: ntp discipline of local time?

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@xxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> 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.





.

Relevant Pages

  • Re: ntp discipline of local time?
    ... Principles and Precision Time Synchronization briefings on the NTP ... does two things-- set the system clock frequency (ie adjust the conversion ... factor from CPU cycles to time) and get rid of the offset. ... frequency and phase errors. ...
    (comp.protocols.time.ntp)
  • Re: NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)
    ... correction of offset errors is enough time to collect enough samples to ... 500ppm to prevent NTP network instabilities. ... +-100000PPM) The clock always runs forward. ... like a step from the point of the coarse sampling done by chrony or ntp, ...
    (comp.protocols.time.ntp)
  • Re: NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)
    ... you really need to provide an analysis on the errors this creates when reading the clock during the slew. ... The problem is not the residual time offset but the rate at which time changes. ... The NTP design carefully limits this to no more than 5 microseconds per second without the kernel and even smaller with the kernel. ... like a step from the point of the coarse sampling done by chrony or ntp, ...
    (comp.protocols.time.ntp)
  • Re: NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)
    ... training should recall exactly how such a loop works and how it responds ... Eleven seconds after NTP comes up the mitigation ... immediate offset value to control a feedback loop with a very long time ... When you say "the clock is set" what do you mean? ...
    (comp.protocols.time.ntp)
  • Re: SABERTOOTH X58 clock drift
    ... Network time protocol (NTP), can do a couple things for you. ... Say the hardware clock source (oscillator) ... real computers you also have the issue of SMM. ... On your computer, when an interrupt ...
    (alt.comp.periphs.mainboard.asus)