[ntp:questions] Re: is there a way to "lock" the drift frequency
terje.mathisen at hda.hydro.com
Sun Nov 16 14:31:22 UTC 2003
> 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.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
More information about the questions