Linux 2.6.23.13(PPS) vs. ntpd 4.2.4p4
Heiko Gerstung
I observed a strange behavior of the Linux kernel 2.6.23.13 which I
patched with Rodolfo's LinuxPPS in order to support the PPS of my
Meinberg GPS receiver.
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
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 there was some discussion on the hackers list in the last days
in regards to PLL constants, this might be a related issue.
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
minutes until the offset reaches my "target area" of +/- 5us .
A strange side effect keeps me from using this kernel setting: When I
plug in a USB stick (without doing anything with it, no mounting or
anything else) and remove it , ntp immediately reports an offset of
10ms (or sometimes even 40ms). IMHO this indicates time jumps caused by
lost timer ticks, but I am just wild guessing here. At least it is fully
reproducible and after plugging the USB stick in and out for a while
(ignoring the ridiculous comments from my co-workers), the offset grows
to 150ms and more, depending on the number of times I removed the USB stick.
This definitely is a kernel issue and has nothing to do with ntp, but I
would like to know if someone else has the chance to try this out on a
machine where she/he can modify th kernel configuration.
I will do some further testing before I report a (kernel) bug, but I
would be happy to get some more results before doing that.
Best Regards,
Heiko
David Woolley
Heiko Gerstung <heiko.g...@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.