[ntp:questions] Stabilizing the drift file?
mills at udel.edu
mills at udel.edu
Wed Nov 22 16:42:35 UTC 2006
I've had this discussion literally hundreds of times over the last 25
years. Somebody tells me they absolutely must have residual error less
than x millisconds guaranteed not more than y minutes after startup. But
this pits the Principle of Least Astonishment against the constraints of
physics. There is a tradeoff between the precision in estimating the
intrinsic frequency of the oscillator and the time to make and refine
When first starting ntpd without the drift file, by default the state
machine takes fifteen minutes to directly compute the initial frequency
estimate within about 1 PPM, then enables the native clock discipline
algorithm. You can change this using the "tinker stepout" command to
shorten the initial time; however, the estimation error will be worse
and could well cause the succeeding offsets to exceed 10 ms until the
loop settles down.
The clock discipline algorithm takes far longer than five minutes to
refine the time and frequency estimate within 10 ms confidence. At the
lowest poll interval of 16 s, the discipline crosses zero in about
fifteen minutes, but the frequency convergence can take four times as
long. So, even if you shorten the stepout threshold to five minutes and
rely on the discipline to complete the initial convergence, you are
still left with some uncertainty that your 10-ms constraints might be
Notwithstanding the constraints you are faced with, the following are
your ONLY choices:
1. Pay more money for the oscillator and/or select the crystal within a
tolerance of 10 PPM or less. That's what Digital did for the Alpha. I've
never seen an Alpha with more than 5 PPM frequency error.
2. Provide a fine oscillator frequency adjustment (VXO) and calibrate
during initial test.
3. Measure the oscillator frequency error during manufacturing and save
this in the BIOS flash where the operating system can find it.
4. Set the stepout interval to five minutes and accept what errors
remain once the state machine has enabled the discipline.
5. Don't do anything and require a hot spare is always available with a
burn in of several hours.
Robert Wachinger wrote:
> Maarten Wiltink <maarten at kittensandcats.net> wrote:
>>"Robert Wachinger" <job at Robert-Wachinger.de> wrote in message
>>news:ek175f$sp9$1 at daniel-new.mch.sbs.de...
>>>We have here the requirement to have a replaced board (a fresh one
>>>from the factory, where a correct content of the drift file is
>>>unknown) up after 5 minutes in a cluster, which also means, that
>>>its time does not stray more than 10ms (within the cluster).
>>>We tried here to "play" with minpoll, burst, initial drift files
>>Iburst would start you with a low offset. But that has really
>>absolutely nothing to do with intrinsic frequency error.
>>Can you run (NTP on) the board outside the cluster? Your problem is
>>that you don't know the correct drift value. It seems simple then:
>>you should find out.
> That would mean additional manual handling (and is therefore costful).
>>I'm not sure if limiting maxpoll is guaranteed to keep your offset
>>low the way running ntpdate often would; frankly I doubt it.
> So no idea, to reduce the time until a drift value is stable enough.
>>Doesn't the cluster allow you to add nodes in standby mode?
> Hm, nice idea. Maybe that could work ...
> Regards, Robert
More information about the questions