[ntp:questions] Re: is there a way to "lock" the drift frequency

Terje Mathisen terje.mathisen at hda.hydro.com
Sun Nov 16 14:31:22 UTC 2003


wayne wrote:

> In <bp4uuh$2mt$1 at osl016lin.hda.hydro.com> Terje Mathisen <terje.mathisen at hda.hydro.com> writes:
> 
> 
>>Coasting past periods of widely variable basic cpu frequency is
>>reather hard, I believe you have to either disable APM, or live with a
>>sawtooth clock performance.
> 
> 
> I agree that ntp simply can't correct for APM mucking up the cpu
> clock, however, having ntp react by changing the frequency just
> doesn't work very well.
> 
> Over the last couple of years of watching ntp, I *know* that when
> everything is running fine, the frequency is x +/- 5%.  When ntp
> either gets bad data from the net or bad data from the clock, it will
> often try changing the frequency by more than 100% and it can take
> hours or days for things to settle back down.  It seems wrong to need
> another program running to watch ntp and reset it when it goes off
> into lala land.
> 
> This is why I'm wondering if there is a way to "lock" the drift
> frequency to always be within a certain range.

The capture range (== maximum frequency offset) used to be 100 ppm, it 
is currently 500 ppm.

It would seem possible to patch & recompile to only allow some 
relatively small range around the initial ntp.drift value.

Terje
-- 
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"




More information about the questions mailing list