Andreas Krüger wrote:
> Hallo, Alby,
>
>> My NTP server is running with a Sure GPS as my Stratum-0 device and I'm
>> able to get microsecond level of accuracy. Averaging an offset of
+/- 10µs.
>
> I understand any GPS device needs to know the time down to a
precision of some
> 20..50 nanoseconds or so. It simply takes that kind of precision clock
> internally to display the position as accurate as these gadgets do.
>
> Now, some GPS devices may take more care to export the time with good
precision
> to the outside than others. Personally, I never had a GPS hooked up
as a clock
> source. My ntpd are always stratum 2 or more. But I am surprised that
you get
> only +/- 10µs. This is some 200x worse than I would have speculated.
>
> Are you sure your clock isn't actually much, much better than that?
How do know
> it isn't?
GPS receivers surely have an internal accuracy of a few nanoseconds.
The question is how to get this accuracy into your computer or application.
Even if you use a 1 PPS signal wired to a pin of a serial or parallel
port there are
a number of facts which can affect the resulting accuracy:
- How long does it take until the interface chip recognizes a 1 PPS slope
and generates an IRQ?
- How long does it take until the IRQ handler is activated?
- What if the PPS IRQ is shared with a different driver which has
registered its
IRQ handler earlier, and thus is called before the PPS handler
everytime the
shared IRQ has been generated?
- How long does it take for the IRQ handler to read the interface chip
registers
to see if the PPS device has really generated the IRQ, and not a
different device
which shares the same IRQ?
- What happens if a different IRQ with higher priority is actually being
handled
and thus the PPS IRQ handling is delayed?
- How long does it take in the PPS handler to read the current system time?
- Which resolution and accuracy has the system time stamp?
- Once ntpd has computed the difference between the current system time
and the PPS time, how does the kernel clock react if an adjustment
is applied?
- How stable is the OS system clock with regards to temperature changes?
Finally, what ntpq reports as offset is only ntpd's estimate based on its
earlier measurements which can not account for systematic errors, like
the mean interrupt latency.
Of course, some of the effects mentioned above can often be neglected if
you are *sure* the resulting errors are ranges smaller than other effects
limiting the resulting accuracy, and errors due to other effects can be
minimized
by an elaborate implementation, but to be able to *measure* the true offset
you need another independent, accurate time source, just like Andreas
has said:
> Just comparing with other ntpd out in netland doesn't count. Ntpd
will allow you
> to see clock imprecision up to somewhere in the single-digit µs
range, if you
> are careful and a bit lucky. Below that, with today's typical network
package
> delays, ntp is blind. So you'd need something else, something better
than plain
> ntp, to compare your clock to.
Regards,
Martin
--
Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
