"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
