[ntp:questions] Re: Ntpd accuracy

David Woolley david at djwhome.demon.co.uk
Thu Jun 9 19:17:25 UTC 2005

In article <hLydncsOkqR23jrfRVn-sA at comcast.com>,
Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
> Eric Liu wrote:
> > Subject: Ntpd accuracy

This is misleading, because it is clear that you don't want accuracy but
simply that all machines have the same error.

> >server minpoll 4	# The dell computer is time server

You shouldn't override minpoll, especially if you are using Windows
as a server, as you need a reasonably long poll interval in order to
properly average the sampling variations, as noted below.

> >We can see that the offset varys in a very large range. How can I make the

Offset is not the same as the time error, and is generally larger than

> Your largest offset is 23 milliseconds (absolute value)  which is not 
> bad for a machine synchronized to a server using its local clock as a 
> reference.    The local  clock on virtually any computer will not 

It's not bad for a machine synchronised to loaded Windows system.

Unless temperatures are varying wildly, the second order (df/dt)
variations in computer clocks really aren't that bad.  The static
frequency error is likely to be high, but all the machines in this
isolated system are working with the same false idea of time and frequency
so the static errors don't matter.  (If the questions here reflect the
real use of ntpd, it is no longer used for its intended purpose, but
simply for measuring small time differences between the components of
isolated systems.)

However, in my experience, Windows is vulnerable to large scheduling
delays, of the order of 10 to 20ms, so if ntpd is run on a loaded
machine you can expect sampling variations of the order of the
scheduler time slice. Once scheduled, ntpd interpolates between 
clock interrupts and gives a more accurate time, but that is not
available to clients.  If it is synchronised to an external clock it
will average out its measurement errors, and it will trim the local
clock so that the time is very accurate on an interrupt.  However,
external queries are subject to scheduling and packet queueing delays.

Local applications on the Windows box will only see time to a resolution of
10 to 20ms, anyway.

The other problem that Windows has is losing clock interrupts - I suspect,
given the way that it slowly recovers, that the -23ms error is a lost

Something that should be borne in mind, though, is that, apart from lost
clock interupts, the ntpd loop filter on the clients will tend to smooth
out the sampling errors, so that the client machine clocks may well be
much closer to representing the same linear function of time than the
reported offsets imply.  Even when there is a lost interrupt, the clients
may well respond to it in the same way, so track together.

If he wants 1ms accuracy, even assuming he only needs that accuracy over
total intervals of 10s of ms, he needs to analyse the client machines
for interrupt and scheduling latency.  There is no point in having 500
micro second clock accuracy if you are timing external events and disk
interrupt processing can delay them by up to more than 10ms.

> The situation is analogous to one drunken driver trying to follow 
> another!  The server's clock drifts but the client assumes that the 

The distance beteen the two tailgating cars may actually be relatively
constant.  He's probably not interested in how far they are from the
kerb, or how far they have travelled, but only the bumper to bumper distance.

> The fix is to use a stable and accurate reference for the the server.  

This may make things worse for this, increasingly common, abuse of
the NTP protocol.  If the server is trying to track an upstream server
or a  reference clock it is going to hunting around the correct time,
whereas letting the local clock free run will give neither true time nor
frequency, but the clock phase will advance very uniformly with real time,
which is all you need for measuring small time differences.

In his situation, he should dedicate one of the PC104 machines to being
the pseudo-time server.  Ideally he would use the timed protocol, which
is intended for his sort of usage, but that isn't widely available.  The
PC 104 server will be unloaded and won't be running Windows.

More information about the questions mailing list