[ntp:questions] Linux vs. ntpd 4.2.4p4

David Woolley david at ex.djwhome.demon.co.uk.invaild
Wed Jan 16 22:05:53 UTC 2008

In article <478dc0c1$0$90272$14726298 at news.sunsite.dk>,
Heiko Gerstung <heiko.gerstung at meinberg.de> wrote:

> My first tests showed that this version of ntp seems to converge very 
> slooooow despite an initial offset of +/- 500us. It seems that ntp's 

You need to start with an error of more than 128ms if you don't have 
a valid saved frequency correction, or at least that was the case 
about a year ago.  I think starting without a drift file may also force
a complete calibration.  Starting with a valid frequency correction, but 
with an offset less than 128ms will result in a slow convergence but 
shouldn't be shooting out to several ms.

> frequency adjustments are not "aggressive" enough, because the offset 
> grows from 0.5ms to 10ms after ~ 2 hours (with deceasing speed) and then 
> it turns around and takes another 2-3 hours before it reaches our 
> beloved zero line.

I think that is about the right value when the loop is locked.  It needs to
long to reject jitter.

Again subject to any recent workarounds, if the time appears good enough
to avoid an initial calibration, ntpd will treat the time error as though it
is within the jitter noise, not as a systematic error.

> In order to get it to correct the clock / frequency faster, I changed my 
> kernel settings from HZ=250 to HZ=1000 and voila, it looks much better. 
> Conversion is faster and with a correct drift file takes only ~10-15 

I think that just demonstrates that Linux is broken when HZ <> 100.  Changing
HZ shouldn't change the loop time constant.

> minutes until the offset reaches my "target area" of +/- 5us .

More information about the questions mailing list