[ntp:questions] SHM sensitivity to maxpoll

Serge Bets serge.bets at NOSPAM.laposte.invalid
Fri Nov 25 16:40:53 UTC 2005


Hello,

There is something strange with ntpd reaction to the maxpoll option for
a shared memory reference clock. The poll interval always stays at 6.
But ntpd behaviour is different if there is a "maxpoll 6", or not.

Running a Linux stratum 1 server running ntp-dev-4.2.0b-20051110.tar.gz,
configured with one single SHM(0) refclock, with a 641138 Conrad DCF77
receiver, driven by Jonathan A. Buzzard's radioclkd 1.0 (patched to deal
with leap seconds). In ntp.conf, I have:

| server 127.127.28.0	maxpoll 6
| fudge 127.127.28.0	time1 0.020	refid DCF

Everything works OK: The poll interval shown by "ntpq -p" is 64s,
"ntpq -c rv" shows poll=6, and "ntpq -c rv <assid of refclock>" shows
hpoll=6 and ppoll=6. Graphed over a day, the offset stays inside a
-0.3 +0.3 ms interval. Any brutal change in temperature or machine load
is amortized in some tens of minutes, visible immediatly on frequency
graph. Fine.


But if I let poll interval free, removing the "maxpoll 6":

| server 127.127.28.0
| fudge 127.127.28.0	time1 0.020	refid DCF

The poll interval shown by "ntpq -p" is still always 64s, on this recent
ntp-dev version. But "ntpq -c rv" shows poll=10 (?!), and
"ntpq -c rv <assid of refclock>" shows hpoll=6 and ppoll=10. And the
offset and jitter values are higher. The graphed offset shows it
wandering up to +1 ms during 2 hours, then correcting down to -1.2 ms
during 5 hours, and so on. A brutal temp/load change can take half a day
to be amortized. Frequency graph is unnaturally stable, to not say quite
horizontal... until a late change to another stable horizontal value.

In fact offset graph looks more or less like when with an older Debian
ntp version 4.2.0a at 1:4.2.0a-8-r, a free SHM was polling at 1024s
interval (after initial stabilization).


I do use maxpoll. But doesn't all this hide a feature in ntp-dev code?


Serge.




More information about the questions mailing list