[ntp:questions] Re: ntp performance, jitter, etc and its implications for test/verification of a timing source

David Woolley david at djwhome.demon.co.uk
Mon May 8 20:59:09 UTC 2006

In article <445EDEB5.1060907 at gmail.com>,
jim.cromie at gmail.com (Jim Cromie) a wrote:

> stratum=4, precision=-18, rootdelay=96.293, rootdispersion=325.746,

> I would however expect much better timing jitter from a 
> null-ethernet-cable 'network'
> without any other nodes, switches, just some traffic between the 1 boxes.

There is no network at all involved for the local clock (the addresses
may look like loop-back addresses, but they are actually magic tokens).
The offset is zero, by definition.  However, there is still an uncertainty
in the value because, amongst other things, there is a finite minimum
difference between successive readings of the system time.  This is
due to a combination of the time it takes to process the request and
the interval between the smallest measurable unit (a zero difference
doesn't count as the presumption is that this arose because the samples
where made closer together than the resolution of the clock).

For Windows, this figure is around 10ms. For modern Unix-like systems running
on modern Intel chips, it can be sub-microsecond.  For older Unix-like
systems on PC-like hardware, it is limited to one microsecond by the
Counter Timer Clock hardware.

When it starts, ntpd samples the clock to work out this value and encodes
it, logarithmically, as the precision.  I could be wrong, but I think
your -18 means 4 microseconds, which is the error value being reported
for the local clock.

Incidentally, your delay figures for the remote servers are very large
for anything except a modem connected system, and their variability 
seems to suggest that your link is heavily loaded, but not 
consitently, and that your service provider isn't prioritising 
NTP traffic (not that many would).

More information about the questions mailing list