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

Frederick Bruckman fredb at immanent.net
Fri Nov 21 02:55:00 UTC 2003

In article <bec993c8.0311170445.617b4c4a at posting.google.com>,
	shoppa at trailing-edge.com (Tim Shoppa) writes:
> wayne <wayne at midwestcs.com> wrote in message news:<x4smkqvhvv.fsf at footbone.midwestcs.com>...
>> Is there a way to "lock" down the pll frequency to some value around
>> what is in the drift file?
>> The two most common causes of this are when my ADSL line gets
>> saturated for a long period of time (usually due to people trying to
>> download my entire 2GB website)
> For this case, a patch to NTP's "MAXDISPERSE" value might do some good.
> (Actually, it's peerdelay/2 + peerdispersion that this is compared to.)
> By lowering it you could cause your peers, when they don't respond
> quickly (and you would set the threshold to be a chunk above "normal"
> network load) to appear unreachable.  Your machine will keep it's
> nominal frequency and "drift" until the network load reduces and you
> trust it again.  When the delay comes back down and they are deemed
> reachable, then you meet the problem found in the "pinball" thread, though.
> (A case of "a hole in the bucket"!)
> MAXDISPERSE is in include/ntp.h in the NTP source tree.
> If you really don't like tweaking MAXDISPERSE you could add another
> test based only on peerdelay in ntp_proto.c.  It could be added near
> test 8, in particular.

Those both sound like good ideas. I've been running with a hack that
filters packets greater than a given delay, and it works really well
for the nailed-up ISDN connected host. I've been doing it later,
though, where the popcorn spikes are filtered. That has the drawback
that ntp thinks the clock is still synced to something, even when it
really isn't. I think I will try the MAXDISPERSE thing.

"huff-puff" doesn't cut it -- the delays aren't perfectly asymetric,
so what happens, is, ntp eventually steps the wrong way, and then later
steps back.

I suspect capping the DISPERSE/DELAY would also help intermittently
connected dial-up hosts, though I haven't tested much. What I have
observed, is several servers delivering packets with seconds-long
delays right after connecting. You don't even need a static IP to
see it, just a NAT router/IPv6 tunnel host running a persistent pppd.


More information about the questions mailing list