[ntp:questions] Stabilizing the drift file?

mills at udel.edu mills at udel.edu
Wed Nov 22 16:42:35 UTC 2006


Robert,

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 
that estimate.

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 
violated.

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.

Dave

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).
>>>
>>>Any tips?
>>>We tried here to "play" with minpoll, burst, initial drift files
>>>(value 0).
> 
> 
>>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 mailing list