[ntp:questions] Best solution for millisecond accuracy

David Woolley david at djwhome.demon.co.uk
Sat Mar 24 10:40:31 UTC 2007

In article <46043069.1010200 at comcast.net>,
Richard B. gilbert <rgilbert88 at comcast.net> wrote:
> edouard funke wrote:

> > - change OS (again what is the impact ?)
> Some operating systems keep time a little better than others.  Windows 
> and Linux have both been known to lose clock interrupts during periods 
> of high disk usage.  I've had good results with Solaris (8, 9, & 10) but 
> others here seem to have had results differing from mine!

Also, Windows, in default configuration, will only provide a resolution
of about 15 to 20ms (whatever the clock interrupt rate is) in the times
provided to application programs.  ntpd plays tricks to make its own times
more accurate, and therefore the phase of the system clock more accurate,
but, in my experience, that breaks down when the system is heavily loaded.

It is possible that enabling multimedia timers will improve the resolution
of time supplied to application programs; I haven't tested this.  However,
I would think that the probability of lost interrupts will be increased.  It's
absolutely essential that you do not change the enablement state of these
timers, as the transition causes a shift in the time seen by ntpd.
> > is the accuracy of a millisecond "achievable" in those conditions ? If
> > not, what can i do to achieve it ?

> Without a UTC reference (hardware reference clock or at least one (four 
> or more are best practice) internet server) your clocks WILL drift. 
> They may drift badly.  Synchronization between systems may be fairly 
> loose (many milliseconds difference between different machines).

I imagine he is only concerned about the synchronisation between machines.
Especially with a TXCO, that should be better than WAN sourced time, because
there will be little network jitter.  They will drift in relation to
true time, but ought to keep together well, as long as there isn't too
large an offset between server and client natural clock frequencies.

However, for a high percentile of system times being within 1ms of the
reference, he probably should be using PPS timing with equal length 
cables between the timing source and all the machines.  Note that
no-one can guarantee a 100 percentile <1ms performance.

One other factor to bear in mind is that time is of no use without some
real world event to time.  Interrupt latencies or polling delays for the
device drivers that capture those events may also compromise the
1ms.  The reason that both Linux and Windows lose interrupts is that they
have interrupt latencies longer than the chosen clock tick (especially
if Linux tick gets set to 1000Hz (1ms).

> The 20 millisecond network delay between buildings seems excessive and 
> may cause problems.  The maximum error in transmitting time from server 

That certainly rings alarm bells.  One really needs to know much more
about the technology involved.  Only if the delay were purely the result
of using an analogue delay line (which is a silly suggestion), in both
directions, would it not affect timing.  What matters is any asymmetry,
and the uncertainty in the delay from packet to packet.

More information about the questions mailing list