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

Frederick Bruckman fredb at immanent.net
Fri Nov 21 15:56:50 UTC 2003

In article <bec993c8.0311210546.25280b6 at posting.google.com>,
	shoppa at trailing-edge.com (Tim Shoppa) writes:
> fredb at immanent.net (Frederick Bruckman) wrote in message news:<6t6dneNTQLsZ4yCiXTWQlg at ripco.com>...
>> 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.
> Remember, if the network delays keep up for long periods of time
> (more than a few ppm frequency error for a full day will qualify) then
> you're likely going to need to step when the delays come back down and
> the servers become reachable again, even with a tweaked MAXDISPERSE.
> Although I agree that one step in the right direction seems better
> than one wrong followed by one right.

I've found that by simply filtering the packets with a delay greater
than 250ms, there won't be any stepping for at least a day, and then
when the network finally normalizes, it's still close enough that ntpd
doesn't need to step. That's way better than the result with huff-puff.

If long downloads go a couple days, though, it bounces all over the
place, again. I think it might do better if the filtering is early
enough so that the servers are declared unsynchronized, so ntpd can
just get out of the way until the network normalizes. I see that
MAXDISPERSE defaults to "16.". What scale is that in? To get the
equivalant of "delay < 250", I would have to reduce MAXDISPERSE to 
less than "1."?


More information about the questions mailing list