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

Craig Craig.e.johnston at boeing.com
Mon Nov 17 17:55:05 UTC 2003


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.

The step (if offset>8ms) occurs fairly soon, but the frequency still
takes a while to recover to the point that I'm back under 1ms of
offset.  I too would like to have the option to heavily dampen the
frequency changes, and have NTP assume that large offsets are due to
errors on the local machine, and not the network or server.  After
all, I'm talking to a stratum 1 server on a network that never
exhibits delays of more than 6ms average over any 8 samples (burst).

I'm currently using 4.1.1a.



More information about the questions mailing list