[ntp:questions] Re: ntpd transmit timestamp precision
David L. Mills
mills at udel.edu
Tue Feb 14 17:58:15 UTC 2006
Brian,
The fuzz indeed is intended only for gettimeofday() and is not effective
in simulation. My commment on simulation should have been on the
roundoff/bias considerations and the tick interval. I have run the
simulation with a simulated tick interval of one second (!) and the
algorithms work rather well. In other words, the expected errors
relative to a fine-grained resolution are suprisingly small. It all
depends on careful residual management and unbiased averaging.
Brian Utterback wrote:
> I think that this is Damion's point. If you look at the code itself,
> the fuzz code is not used if:
>
> 1. You are using clock_gettime.
> or
> 2. You are using getclock
> or
> 3. You are using the simulator.
>
> So, the fact that the simulator is doing okay is irrelevant, since it
> does not use the fuzz code. But more to the point, the clock_gettime and
> getclock functions claim to return nanoseconds, so there are only two
> bits available to fuzz, so the code does not bother to fuzz those last
> two bits. Damion's point is that the actual precision of the clock
> on his system is much more coarse, so more bits are really
> non-significant and should be fuzzed, but they are not.
>
> I don't think he is actually commenting on the accuracy of the time
> derived from fuzzed values, just the fact that he is not seeing any
> fuzz at all.
>
> David L. Mills wrote:
>
>> Damion,
>>
>> THe ntpd in ntp-dev has been run in simulation with tick = 10 ms and
>> done amazingly well. The low order nonsignificant bits are se to a
>> random fuzz that apparently averages out just fine.
>>
>> Dave
>>
>> Damion de Soto wrote:
>>
>>> Brian Utterback wrote:
>>>
>>>> Yes and no. If your system supports either clock_gettime or getclock,
>>>> then the code does not bother with the random bitstring, since there
>>>> are only two unused bits to set. Not worth the trouble.
>>>
>>>
>>>
>>> Thanks, but I have a system here that has very low resolution system
>>> clock,
>>> ntpd correctly detects this via default_get_precision() as:
>>> Feb 13 07:01:31 ntpd[59]: precision = 10000.000 usec
>>>
>>> I have clock_gettime() available to me, but the nanoseconds values
>>> will be mostly wrong, since 10ms only gives me 7 bits of precision.
>>> This means all 64bits of the fractional seconds in the Transmit
>>> Timestamp are nearly always the same.
>>>
>>>
>>> Has no-one else ever run into this before?
>>>
>>> Regards,
>>>
>>>
>
>
More information about the questions
mailing list