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

Alby VA albyva at empire.org
Thu Mar 22 11:01:09 UTC 2012


On Mar 21, 10:10 pm, David Lord <sn... at lordynet.org> wrote:
> Alby VA 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" <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?
> >> 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 atwww.ko4bb.comandwww.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.... 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



Thanks David.   U Da Man.  :)

-Alby (KK4DLV)



More information about the questions mailing list