[ntp:questions] Any chance of getting bugs 2164 and 1577 moving?

Richard B. Gilbert rgilbert88 at comcast.net
Thu Mar 22 18:59:24 UTC 2012


On 3/21/2012 7:39 PM, Alby VA wrote:
> On Mar 21, 7:36 pm, unruh<un... at invalid.ca>  wrote:
>> On 2012-03-21, Alby VA<alb... at empire.org>  wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Mar 21, 3:55?pm, unruh<un... at invalid.ca>  wrote:
>>>> On 2012-03-21, David J Taylor<david-tay... at blueyonder.co.uk.invalid>  wrote:
>>
>>>>> "unruh"<un... at invalid.ca>  wrote in message
>>>>> news:itmar.5841$yD7.508 at newsfe15.iad...
>>>>> []
>>>>>> But -19 is about 2 microseconds if I understand it correctly. That means
>>>>>> that the clocks are incapable of delivering more than about 2
>>>>>> microseconds of accuracy. What is you ?that last decimal digit of
>>>>>> accuracy in the offset is thus pure noise-- dominated by clock reading
>>>>>> noise. Why is it important for you then?
>>
>>>>> When I can see the decimal places, then I will know whether the precision
>>>>> estimate is reasonable. ?Just getting values such as -1, 0, 1 microseconds
>>>>> is insufficient to make that call.
>>
>>>> And how will the extra decimals help? The -19 was determined by making
>>>> successive calls to the clock and seeing how much it changed between
>>>> successive readings. That gives a good estimate of how long it takes to
>>>> make a call to the clock. Any precision in the answer beyond that is not
>>>> accuracy. I could give you the time to 60000 decimal places, each one of
>>>> the diffetent, but the last 5995 just being garbage (random numbers)
>>>> Would that tell yo uanything?
>>>> If for some reason you do not believe ntpd's estimation of your clock
>>>> accuracy, develope a better algorithm for determining it. It is a bug is
>>>> ntpd is reporting an accuracy much worse than it actually is.
>>
>>>> Ie, you have no data to make that call even if you get more digits.
>>
>>>>> David
>>
>>> unruh:
>>
>>>    My take is the precision output might say your device is -19 so you
>>> know its
>>> accuracy is around 2/microseconds. But the offset several decimal
>>> places
>>> allows you to see its ever changing accuracy within that 2/microsecond
>>> band
>>
>> But that is not accuracy. That is presumably (if that -19 is accurate
>> and not a bug) is simply noise. If your measurement technique is only
>> good to 2us, then any additional precision is just noise. It may be fun
>> to see the noise, but not terribly useful. If it is not noise, then that
>> -19 is wrong, and one has a bug in the determination of the accuracy of
>> the clock reading.
>>
>>> to a greater detail than just -1, 0, or 1 microseconds. I guess its
>>> just a matter
>>> of getting more granular details for cool MRTG charting. :)
>>
>> It could well be that charting looks better without just bands on the
>> page. But is it worth it if that detail is just junk? It certainly is
>> not great art.
>
>
>   It there any good way to determine what is noise and what isn't?
>
>

Try comparing against a known good source!  Time from sources on the 
internet is almost always noisy!  If you must use internet sources
try to query them between 0200 and 0400 local time; the net will be as 
quiet as it's likely to get!

Time/Frequency Standards are not cheap!  If you can afford one, the 
National Bureau of Standards, in the U.S., will be happy to calibrate it 
for you.  Governments of countries other than the U.S. should have
similar facilities.




More information about the questions mailing list