Alby VA wrote:
On Mar 21, 8:16 pm, David Lord <sn...@lordynet.org> wrote:
Alby VA wrote:
On Mar 21, 7:36 pm, unruh <un...@invalid.ca> wrote:
On 2012-03-21, Alby VA <alb...@empire.org> wrote:
On Mar 21, 3:55?pm, unruh <un...@invalid.ca> wrote:
On 2012-03-21, David J Taylor <david-tay...@blueyonder.co.uk.invalid> wrote:
"unruh" <un...@invalid.ca> wrote in message
news:itmar.5841$yd7....@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?
ntpq -c rv gives output including precision= , which on
my server indicates precision=-19 which is 1/(2^19) or
approx = 2us
David
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
be
in getting a better stratum 0 device?
Probably not but it depends on the specification of
your GPS. The problem is in getting the PPS pulse into
the computer.
Take a look at www.ko4bb.com and www.febo.com.
I'm not sure if it's a soekris board that can be modified
to accept a PPS signal via an input pin rather than via
rs232 and interrupt.
David
assID=0 status=0415 leap_none, sync_uhf_clock, 1 event,
event_clock_reset,
version="ntpd 4.2.6p5@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
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
