On 2012-03-21, Alby VA <alb...@empire.org> 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?
Not without hardware. You could put a scope on the intput and have the interrupt service routine switchon one of the ouput pins to the parallel port and see what the delay is between the input and that output. Of course the slew rate of the parallel port drivers might to too small to get a reasonable result (although it looks like it should be more than about 30V/us to meet the timing specs) You could put out a pulse to one of the pins just before the timestamp, and another just after and see how long it takes to read the clock. But I donot know if that you would consider "good". > > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
