[ntp:questions] delay in stats

Richard B. gilbert rgilbert88 at comcast.net
Thu Mar 1 19:15:45 UTC 2007

edouard funke wrote:
> Hi,
> I am running some tests on the NTP protocol for my company : I need to
> achieve (if possible) in LAN a precision (for clients) of about 1
> millisecond (or less :-))
> 1. the following properties are studied :
> - the time for a client to "calibrate" its clock
> o with/without iburst mode

iburst gives you faster startup; 16 seconds vs. more than 5 minutes!

> o with/without drift file
A drift file should help you get faster startup; assuming it's still valid.

> o with fixed drift
Bad idea!  (If I understand what you mean.)

> o with different values for max polling
Don't mess with the MINPOLL or MAXPOLL parameters.  Ntpd will adjust 
these for best performance.  Normally you would start polling at 64 
second intervals and ntpd would adjust to longer intervals as it pulled 
into synchronization.

> - the maximum precision achievable for clients :

The "precision" achievable by clients is determined by the client 
hardware and Operating system.  The "accuracy" is determined by the 
quality of the time source and the quality of the network path between 
server and client.

> o with different values for max polling
Don't mess with it!

> o with huff n'puff filter
The "huff n'puff" filter was intended for slow internet connections; 
e.g. dialup with variable or asymmetric round trip delays.

> o with all clients in « peer » mode or at least some of them
> the NTP  server clock reference will be :
> o undisciplined local clock
Bad idea.  You get no guarantee of correct time and poor stability!

> o internet stratum 1 or 2

> o GPS (i have a meinberg lantime M300 and PCI card + GPS receiver on loan)
Expensive but very good!  The last price I heard for these was over 
$1000 US.
This should give you high accuracy and stability.

> I am trying to know here which configuration parameters can improve
> the "calibration" speed and maximum precision of clients clock.
> I am not trying to have the exact time on clients but rather, that all
> clients have the same time.

How close must your clients be?  Using an undisciplined local clock as a 
source, the clients are likely to behave in a manner similar to one 
drunken driver trying to follow another.  You could have a spread of two 
or three seconds between any two randomly selected clients.  It probably 
wouldn't be quite that bad but there's no guarantee!

Using GPS as a reference the clients should synchronize quickly and tightly!

If the clients are configured to use "iburst" they should have a 
reasonable approximation of the correct time within twenty to thirty 
seconds.  In thirty minutes they should be within a few milliseconds of 
the server and each other.

> I must run NTP daemon on Windows Server 2003 SP1 and it almost sure
> that, in the end, NTP servers wont be able to have internet connection
> or even GPS : 

Bad idea!
>they are included in tests because i want to determine
> the impact of the server precision on the client precision.

Good idea but, given the underlying bad idea I'm not sure how much it 
will help.

> For the GPS, i know there is some hardware solution that can run in
> free-run mode after 24h calibration (meinberg).

Computers were NOT designed to keep time!  The typical computer clock 
uses components costing less than $2 US and is not adjusted or regulated 
in any way.  A good clock might gain or lose as much as 4 seconds per 
day!  The manufacturers will not spend more money on the clock than they 
absolutely must.  Since people who want the time tend to buy a clock 
rather than a computer. . . .

More information about the questions mailing list