"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 questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
