[ntp:questions] Re: program to test actual resolution of Linux?

David L. Mills mills at udel.edu
Wed Sep 10 01:47:14 UTC 2003


For whatever good or bad come come of it, the actual ntpd precision is
calculated by calling get_systime(), which reads the system clock with
the highest resolution syscall available. So, what ntpd calls precision
is actually the time to cycle through the kernel and read the clock, not
the inherent resolution of the clock counter, which can be much less
than the precision. For instance, a Sun Blade 1000 has a clock counter
resolution of a bit more than a nanosecond, but a precision of about 400
ns. But, the actual resolution when reading the Blade clock is rounded
up to the next nanosecond.

While the procedure reads the clock several times, it is a bit more
tricky than first apparent. Some kernels (nanokernel/microkernel at
least from here) require Lamport's happens-before relation be rigorously
defended, so if the clock counter is really gross, like old Sun 500
microseconds, and the clock is read several times during that clock
tick, the time advances by une unit (nano or micro) for each read.
Unless detected and avoided, this could mislead the results. Time is so
fickle and intricate.


Ulrich Windl wrote:
> Drk,
> call gettimeofday() twice and subtract. If you won't believe in the
> method, describe what you are expecting as result.
> Regards,
> Ulrich
> P.S: If you are lazy:
> ntpq> rl
> status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
> version="ntpd 4.1.1 at 1.786 Tue Feb  4 16:39:46 UTC 2003 (1)",
> processor="i586", system="Linux2.4.19-4GB", leap=00, stratum=2,
> precision=-18, rootdelay=44.226, rootdispersion=275.741, peer=23695,
> refid=lanczos.maths.tcd.ie,
> reftime=c30861df.02caab8a  Tue, Sep  9 2003 16:27:43.010, poll=7,
> clock=c308624c.95697f1f  Tue, Sep  9 2003 16:29:32.583, state=4,
> offset=23.011, frequency=-15.395, jitter=15.000, stability=25.487
> Precision means 2^-18 seconds...

More information about the questions mailing list