On Mar 21, 10:10 pm, David Lord <sn...@lordynet.org> wrote: > 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 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....@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) _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
