[ntp:questions] TSC, default precision, FreeBSD

Dave Hart davehart at gmail.com
Tue Sep 8 17:40:05 UTC 2009


On Tue, Sep 8, 2009 at 12:40 PM, Miroslav Lichvar wrote:
> On Sun, Sep 06, 2009 at 03:53:23AM +0000, David Mills wrote:
>> No, what you suggest is properly called resolution, not precision. Do
>> your homework; -21 is just fine for a  Sun faster than mine, where the
>> precision is -20. Confirm that the jitter.c program, included in the NTP
>> distribution for just that purpose, shows the gettimeofday() routine
>> takes on average 500 ns per call.
>
> BTW, on current hardware the precision seems to be below the 100ns
> MINSTEP limit as used in the default_get_precision routine. If the ntp
> process wasn't interrupted the while loop might run forever.

Dr. Mills explained to me recently that this was added to deal with
one platform curiously returning the same time in successive calls
occasionally.  Miroslav, what value do you recommend for MINSTEP,
which would be below the execution time of getclock() on any machine
now or in the next few years?

> Also, the calculation doesn't work correctly if the precision is below
> resolution. The result is just a random value close to 100 ns. Maybe
> get_systime should be called multiple times before calculating the
> difference.

I've argued that it's also wrong on microsecond system clocks, where
get_systime() fuzzes below the microsecond, and that fuzz will
convince default_get_precision() the system clock ticks more often
than once per microsecond.  I believe both would be repaired by
deferring the addition of fuzz in get_systime() until after
default_get_precision() is done with it, which is to say, until after
sys_precision is nonzero.

I also believe there are paired bugs that mostly cancel each other out
initializing and applying sys_tick in systime.c, for nanosecond
resolution systems.  In that case, I believe sys_tick should be
initialized to 1e-9 (as the comment above the initialization
indicates), and get_systime()'s fuzz calculation should multiple
sys_tick by 1e9 to convert from seconds to nanoseconds.  Currently
it's 1e-6 and 1e6.  The paired errors cancel out, unless you override
tick from ntp.conf.  If you do, be aware this means the units of tick
are milliseconds on nanosecond-resolution systems, not the documented
seconds.  The units are seconds on microsecond-resolution systems.

Cheers,
Dave Hart




More information about the questions mailing list