[ntp:questions] Change poll interval at runtime?

A C agcarver+ntp at acarver.net
Sun Feb 26 17:40:09 UTC 2012

On 2/25/2012 23:19, David J Taylor wrote:
> "A C" <agcarver+ntp at acarver.net> wrote in message
> news:4F49CA89.9090409 at acarver.net...
>> On 2/25/2012 21:55, Ron Frazier (NTP) wrote:
> []
>>> # GPS Lines
>>> server prefer minpoll 3 maxpoll 6 mode 72
>>> fudge time2 0.3100 refid GPS1
>>> # Internet server lines
>>> # NIST New York
>>> server nist1-ny.ustiming.org minpoll 8 maxpoll 13
>>> # other internet server lines similar
>>> Sincerely,
>> I know I can do that to the config file but then it takes forever to
>> synchronize. As I said, the idea was to not give a min/maxpoll so that
>> ntpd would converge on a clock adjustment quickly (polling once ever
>> 64 seconds) and then, after a couple days, I could throttle back the
>> polling interval without restarting the server and changing the
>> configuration file.
> "Takes forever" is the problem you should try to solve. With the systems
> here, which have a GPS/PPS ref clock, they are synced within a minute of
> NTP starting, although it takes longer to get the ultimate accuracy.
> What version of ntp are you running, what OS, and what ref clock?

It's the latest dev version on NetBSD using five network servers plus 
the SHM refclock plus the ATOM refclock.  The SHM is not very stable 
with its offset so I don't use it right now which leaves me ATOM plus 
network (one of the network servers is marked prefer).  (Don't ask about 
using NMEA with PPS enabled, it doesn't work due to the serial drivers 
on NetBSD/sparc so PPS has to be separate via a second serial port).

If I set minpoll to 8 or 9 to be nice to the network servers, it takes 
six or eight polling periods before ATOM turns on and becomes the system 
peer.  If I leave out minpoll, ATOM clamps the polling period to 64 
seconds.  It still takes six to eight polling periods to activate ATOM 
but 8 * 64 is much less than 8 * 256 or 8 * 512.

More information about the questions mailing list