[ntp:questions] Re: NTP stepping issue
David L. Mills
mills at udel.edu
Sat Oct 23 15:34:41 UTC 2004
Philip,
I'm sure you know there has been considerable discussion, research and
experimentation on the points you raise. There are briefings, papers,
reports and white papers at the NTP project page linked via www.ntp.org.
I would like to enthusically encourage you to participate in this area
of research; however, we need to speak a common language. What you
describe was first suggested by Judah Levine at NIST and later
incorporated as a component of the NTP discipline algorithm. It is
useful primarily at long poll intervals where errors are dominated by
the intrinsic frequency stability (wander) of the clock oscillator. At
shorter poll intervals the errors are dominated by phase errors due to
network and operating system latencies. The trick is to combine then in
an intelligent hybrid loop, as described on the NTP project page.
There is a genuine opportunity to test your theories. See the NTP
simulator, which is included in the software distribution. The best
place to experiment is in the ntp_loopfilter.c file. The simulator can
generate ramps, constant offsets and various combinations of random
phase and frequency errors. You can also record real-world data and feed
that to the simulator.
Should you choose to do some experiments, please share the results with
this community.
Dave
Philip Homburg wrote:
> In article <I5KdnepkpvfUFuvcRVn-hg at comcast.com>,
> Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
>
>>You have two potential, and, almost always both are real errors, to
>>correct; the time and the clock frequency. Both errors must be
>>corrected by changing the clock frequency, either temporarily or
>>permanently.
>>
>>Step 1. Record the present offset of the clock from the reference
>>Step 2. Wait ten minutes and record the offset of the clock from the
>>reference..
>>Step 3. Find the difference between the two offsets
>>Step 4. Calculate the correction to the frequency that should cause the
>>clock to
>> advance exactly ten minutes in exactly ten minutes.
>>Step 5 Apply twice that correction (f=f+2*deltaf)
>>Step 6 Wait ten minutes and record the offset which should be close to
>>zero.
>>Step 7. Remove the over correction of frequency (that corrected the time)
>> ( f = f - deltaf)
>>Step 8 Go to step 2
>>
>>The interval that I gave as ten minutes will have to increase as the
>>frequency error decreases. I have assumed that the time error is
>>sufficiently small that it can be corrected with the available frequency
>>adjustment. If this explanation convinces you that I should stick to
>>counting on my fingers, you are probably right!!
>
>
> I implemented something similar to this, and it does work. The main
> additions are:
> - a filter to reduce the noise component of the signal
> - phase and frequency errors are tracked separately. Instead of 2*deltaf
> there is a correction for the frequency error and a temporary frequency
> correction for the phase error
> - under-correction is used to improve stability.
>
> It has been some time since I tested stability, but I think I tried 10
> second pp white noise with a maximum slew rate of 100000 ppm.
>
> Getting the noise reduction right is the tricky part, and is left as an
> exercise to the reader.
>
> I think that NTP assumes that the local clock is unstable compared to
> the reference clock, and uses relatively large corrections to keep the
> clock synchronized. (With the disadvantage that the amount of noise may
> exceed to capabilities of NTP to slew to clock).
>
> In a situation where there is a lot of noise, it might be better to assume
> that the local clock is relatively stable, and use that as a basis for
> filtering the noise. The disadvantage is that it takes more time to converge,
> but arbitrary amounts of noise can be tolerated.
>
>
>
More information about the questions
mailing list