Re: ntp discipline of local time?
- From: Unruh <unruh-spam@xxxxxxxxxxxxxx>
- Date: Tue, 25 Mar 2008 20:27:41 GMT
"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.
Let me concentrate on the situation without the PPS signal.
Is the code in ntp_loopfilter.c the code which disciplines the clock?
If so, then what it reads like to me is that ntp_adjtime (adjtimex in
Linux) is used to alter the clock frequency each time a valid offset is
delivered from the clock filter/peer finder routines. That frequency
adjustment is a multiple of that offset (that multiple depending on the
poll interval, etc) using the ntp_adjtime routine. Then that offset itself
is driven to zero by using adjtime once per second and adjusting the clock
by a small multiple of that offset. (something like 1/(16 times the poll
interval) ) (let me not worry about the allan intercept stuff for now).
Is my reading of the code correct? What I describe would, in the long term
be a simple second order loop-- its interaction with the "clock-filter"
algorithm is rather more complex than that, but lets leave that aside for
now. Also the fact that the adjtime part of the routine simply throws away
the part of the previous adjustment that was not completed-- I assume this
is done because it almost never actually has any uncompleted adjustment.
Is there anything else that is going on? Is "kernel discipline" anything
more than the ability to change the frequency of the clock ( or rather
change the factor that translates the CPU cycle counter to time)?
Sorry to ask such detailed questions, but I am having a hard time
disentangling the code to see what is really happening.
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.
- References:
- ntp discipline of local time?
- From: Unruh
- Re: ntp discipline of local time?
- From: David Woolley
- Re: ntp discipline of local time?
- From: Unruh
- Re: ntp discipline of local time?
- From: David L. Mills
- ntp discipline of local time?
- Prev by Date: Re: ntp discipline of local time?
- Next by Date: Re: ntp discipline of local time?
- Previous by thread: Re: ntp discipline of local time?
- Next by thread: Re: ntp discipline of local time?
- Index(es):
Relevant Pages
|
