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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
