"David L. Mills" <[EMAIL PROTECTED]> writes: >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. Thanks Bill >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 questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
