Re: [gpsd-dev] Clarifications needed for the time-service HOWTO

[Andy Walls]

On Mon, 2013-10-21 at 18:43 -0400, Greg Troxel wrote:
> "Eric S. Raymond" <address@hidden> writes:

>   Some public S1s are very good, and some aren't.
> The real barrier to accuracy is having a way to read the system clock on
> a PPS edge, for example a counter card that can be triggered, so it's
> really reading the clock, together with using that counter for system
> timekeeping.

Yup.

GPIOs aren't as good a a counter-timer.  With a GPIO interrupt for
reading the PPS rising edge, I have a latency of ~8 msec with a jitter
of about +/- 1 msec. :(

With a counter-timer measuring the PPS, I've got ~150 nsec of latency
with a resolution of about 77 nsecs (13 MHz sample clock).  I can just
about observe the PPS jitter (which is specified at +/- 25 nsec at 1
sigma).  The system clock is lower resolution, using 30.5 usecs ticks,
so that's the limiting factor in keeping time. 


>    But the point is that with gpsd and a GPS receiver with
> PPS, one can do very well.
> 
> Another point which should be addressed is:
> 
>   ntpd has builtin support for reading some GPS timing receivers.  How
>   should one decide to use ntpd's support vs gpsd?  Does it matter?

If you need to distribute position and time to processes other than
ntpd, then the answer is obvious: gpsd.

If you don't need to distribute time and position to other processes,
then why deal with gpsd at all?

Regards,
Andy

> And I'm not sure of the answer (my XL-DC machine just uses ntpd).