[ntp:questions] Poll timing

Danny Mayer mayer at ntp.isc.org
Thu Aug 16 12:21:44 UTC 2007

Jussi Kauppinen wrote:
> Paul.Croome at softwareag.com wrote:
>> Jussi,
>> Why should the exact instant when NTP polls be important? It doesn't
>> matter whether the polling interval is 64 seconds or 64.1 seconds or
>> whatever.
>> IIRC, there is some logic in NTP that deliberately staggers the
>> polling of servers when NTP starts up. If this were not done, NTP
>> would try to poll all its servers more-or-less simultaneously,
>> causing
>> bursty network traffic. See
>> http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html#op: "In order to
>> protect the network from bunching, the initial poll interval for each
>> server is delayed an interval randomized over a few seconds."
>> Paul
> I'm developing a system that utilize NTP. Unfortunately, the details of 
> the system are confidential. For this system to work properly, it is 
> essential that polling phase inside a second is approximately constant 
> related to the clock of the client, like I explained earlier. I'm using 
> only one NTP server to poll from.
> Can you tell me what files/parts/functions in the source code do the 
> polling, from where I can check it out how the timing works.
> Jussi

In that case you should start by looking at the ntpd/ntp_timer.c code
which is what does the work. You can also look at ntpd/ntp_peer.c and

What is the reason for the restriction, without violating confidentiality?

One thing you can do to help yourself with this is to make sure that the
system has only the processes that are absolutely necessary to run. That
will increase the likelihood of NTP getting it's CPU slice frequently
enough that it will send out the packet when you expect it. However, you
haven't said much about receiving the return packet and when you want to
get that packet.

Another possibility you might want to consider is to use multicast. Set
up the server to multicast to a multicast address and the client (your
system) will just be picking up the received broadcast mode packets. You
should set up Autokey on these systems, not so much for authentication
(which is also essential) but it gives the client a chance to calibrate
itself with the server and estimate the delay. Note that autokey
reauthenticates itself once per day. Multicast sends out packets every
64 seconds. If you really need it every 16 seconds you will need to go
into the code to change that since it's a fixed frequency.

Does this help?


More information about the questions mailing list