[ntp:questions] Re: is there a way to "lock" the drift frequency
shoppa at trailing-edge.com
Fri Nov 21 13:55:06 UTC 2003
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.
More information about the questions