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

Terje Mathisen terje.mathisen at hda.hydro.com
Tue Nov 18 08:02:46 UTC 2003


Craig wrote:
> 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.

If you actually have lost timer ticks, then you need to fix this first, 
instead of relying on NTP to patch your clock for you:

Specifically, you should look into (assuming open source os) methods to 
detect said lost interrupts, most probably by looking at any available 
separate hw clock, like the RDTSC counter on x86.

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

You can't have it both ways:

Either you have some kind of asymmetry (not neccessarily in the network 
itself!), or all ntp exchanges will be correct, right?

If the NTP packets are OK, then a sudden jump in offset would indeed be 
a clear indication of a dropped timer tick.

> 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).

So basically you want a custom ntpd that quickly 'fixes' any lost timer 
ticks, instead of having an OS (+ hw & drivers) that doesn't suffer from 
the problem in the first case, right?

Terje

-- 
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"




More information about the questions mailing list