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

Terje Mathisen terje.mathisen at hda.hydro.com
Mon Nov 17 18:11:25 UTC 2003

Craig wrote:

> wayne <wayne at midwestcs.com> wrote in message 
>>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.
> I'd also like to second this observation.  I run NTP in a very
> controlled lab-like environment where I have a direct connection to a
> stratum 1 server, and a small class C GB-ethernet network. I'm mostly
> running Linux,  and nominally I see offsets under 1ms even during high
> CPU/network loads.
> What kills me is when the OS misses an interrupt (mostly due to a
> kernel module that holds off interrupts for to long), and my offset
> jumps upwards of 10ms or more (HZ=100). At this point NTP responds by
> bumping the frequency up by 200% or more (-150 to 120ppm), and slowly
> works it back down over an hour or so.  This is with maxpoll==6,
> burst, and using tinker step 0.008 & tinker stepout 8.

'maxpoll = 6' means that you cannot get the automatic damping that's 
inherent in the larger poll intervals.

What about 'tinker huffpuff xxx'?

This was created specifically to survive times of asymmetric network delays.

> I'm currently using 4.1.1a.

Why not 4.2.0?

This is the current stable version, it has behaved very well here.

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

More information about the questions mailing list