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

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

Terje Mathisen <terje.mathisen at hda.hydro.com> wrote in message news:<bpb30e$vad$1 at osl016lin.hda.hydro.com>...
> 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

It's a two edged sword.  If I increase the maxpoll, it takes longer to
converge initially (the lab machines are up and down frequently), and
longer to re-converge after a missed interrupt.  In my experience, it
also does not help much with the missed interrupt case.

I don't think the huffpuff filter is applicable, as I do not have
asymmetric network delays. Quite the opposite.

I do plan to move to 4.2, but nothing I've seen in the release notes
implies that the behavior I need was added.  Am I wrong on this?

Over the years, I've expected someone to fork a version of NTP that
has been tweaked to satisfy the "small LAN" community, with no joy to
date.  This hypothetical version of NTP (say Local NTP), would be
tailored for small switched networks characterized by fast/symmetric
delays, plenty of bandwidth, a directly connected high stratum server,
and strict requirements for fast initial convergence (assuming known
drift) and narrow offset margins (forward steps always acceptable). 
Here, the server is always trusted (within reason), the network is
very reliable, and any errors or discontinuities are assumed to be
caused by the host (again within reason).

Still waiting for that someone (smarter than me),

More information about the questions mailing list