Jussi Kauppinen wrote: > [EMAIL PROTECTED] 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 ntpd/ntp_loopfilter.c. 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? Danny _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions