[ntp:questions] Any chance of getting bugs 2164 and 1577 moving?
albyva at empire.org
Wed Mar 21 21:20:04 UTC 2012
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
My take is the precision output might say your device is -19 so you
accuracy is around 2/microseconds. But the offset several decimal
allows you to see its ever changing accuracy within that 2/microsecond
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. :)
More information about the questions