[ntp:questions] ntpd stuck at default minpoll on stratum one
David L. Mills
mills at udel.edu
Sat Oct 6 20:22:53 UTC 2007
There's a small matter of physics here. The PPS driver clamps the poll
interval and time constant to minpoll, since that's consistent with the
nominal Allan intercept and gives the best overall performance. The
general rule is that the server poll interval must not be greater than
the time constant in order that the feedback loop is never undersampled,
even under conditions of clockhop from one source to another. Otherwise,
should the PPS signal fail and the prefer peer take over poll interval
much higher, the loop can become unstable.
Usually, the PPS is used in conjunction with a local reference clock, so
this is not an issue. It is in principle possible to poll the outside
server at a longer interval, but the complexities of this and the
clockhop issue don't seem to be worth the hazards.
Per Hedeland wrote:
> In article <hoikt4-f6p.ln1 at osl016lin.hda.hydro.com> Terje Mathisen
> <terje.mathisen at hda.hydro.com> writes:
>>Dennis Hilberg, Jr. wrote:
>>>I have a stratum one server running ntpd 4.2.4p3 at 1.1502 with a Garmin
>>>GPS 18 LVC as a refclock. I use the shmpps driver from
>>>http://time.qnan.org/ . Since this driver only provides the PPS signal,
>>>I need to have a few other servers defined in my ntp.conf so that my
>>>ntpd knows what time it is.
>>>Here's my concern: the poll interval on those servers is always stuck at
>>>the default minpoll (64sec), even though I have not specified so. I
>>>would rather not poll those servers at such a rapid rate, but ntpd seems
>>>to be doing this on its own, as far as I know.
>>I think this is a known problem/bug/feature: The prefer peer responsible
>>for naming the PPS ticks is clamped at minpoll. In fact, if you adjust
>>minpoll to 4 (i.e. 16 seconds), which can be a good idea for a GPS-class
>>PPS signal, then you'll also lock your prefer peer at the same rate.
> AFAIK it's not limited to the prefer peer - note that Dennis' ntp.conf
> didn't have 'prefer' on *any* of the remote servers, I believe having
> one used to be a requirement for a PPS-only clock to work, but
> apparently that has changed. I.e. if you have a reference clock, *all*
> remote servers will be clamped at minpoll for the reference clock.
> --Per Hedeland
> per at hedeland.org
More information about the questions