[ntp:questions] Any chance of getting bugs 2164 and 1577 moving?
unruh at invalid.ca
Thu Mar 22 03:02:40 UTC 2012
On 2012-03-22, Alby VA <albyva at empire.org> wrote:
> On Mar 21, 8:16?pm, David Lord <sn... at lordynet.org> wrote:
>> 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:
>> >>> ? 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?
>> ntpq -c rv gives output including precision= , which on
>> my server indicates precision=-19 which is 1/(2^19) or
>> approx = 2us
> Yup. I'm getting the same thing, precision = -19
> In the math, I get 0.0000019073486328125 (1.907/microseconds).
> To improve this to better precision, would the only path of success
> in getting a better stratum 0 device?
No. That is a measure not of how accurate your clock is, but of how
accurately the system clock can be read. If I remember correctly, ntp
takes a number of successive readings of the system clock. It then looks
at the difference between those readings. Since the launching of the
instruction itself is in the ns range, that gives a measure of how long
it takes the system to read the clock and thus the error in any clock
reading. Thus all timestamps are simply not accurate to a better time
than that. This says nothing about how the time is represented. The time
structure may have room in it for picoseconds, never mind nanoseconds.
But most of that is completely meaningless.
You can improve it by getting a better computer, and rewriting the time
handling routines in the operating system.
Note that interrupt servicing takes a certain minimum of time as well.
Teh computer needs to recognize that an interrupt has occured, page out
the currently running program, page in the interrupt handling code, and
finally farm out the interrupt to some driver. That all takes time, and
often in ill determined amount of time.
> assID=0 status=0415 leap_none, sync_uhf_clock, 1 event,
> version="ntpd 4.2.6p5 at 1.2349-o Mon Feb 20 22:00:33 UTC 2012 (1)",
> processor="amd64", system="FreeBSD/9.0-RELEASE", leap=00, stratum=1,
> precision=-19, rootdelay=0.000, rootdisp=0.297, refid=PPS,
> reftime=d314f812.ee1ec4ca Wed, Mar 21 2012 21:00:02.930,
> clock=d314f817.b13ef313 Wed, Mar 21 2012 21:00:07.692, peer=21829,
> tc=4, mintc=3, offset=0.002, frequency=-24.569, sys_jitter=0.002,
> clk_jitter=0.002, clk_wander=0.001
More information about the questions