[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