Re: [gpsd-dev] Mysteriously vanishing bugs don't make me happy

[Andy Walls]

On Mon, 2013-11-04 at 15:46 -0500, Eric S. Raymond wrote:
> Gary E. Miller <address@hidden>:
> > FYI, after many days of running chronyd my clock stability is now down
> > to +/- 400 nSec.  Yes, nSec, not uSec, but it takes a while to get there.
> 
> That reminds me.  I was doing a bit of cleanup on the PPS code - teaching it 
> to
> use the new struct timedrift_t and pushing nanosecond precision as close
> to the code for shipping time hints as possible - and I ran across a couple
> of things that looked odd.
> 
> /* actual_ts is when we think the PPS pulse wass */
> /* clock_ts is the local clocke time we saw the pulse */
> /* offset is actual_ts - clock_ts */
> static void chrony_send(struct gps_device_t *session,
>                       struct timespec *actual_ts,
>                       struct timespec *clock_ts UNUSED,  double offset)
> {
>     struct sock_sample sample;
> 
>     /* FIXME!! offset is double of the error from local time */
>     /* chrony expects tv-sec since Jan 1970 */
>     sample.pulse = 0;
>     sample.leap = session->context->leap_notify;
>     sample.magic = SOCK_MAGIC;
>     TSTOTV(&sample.tv, actual_ts);
>     sample.offset = offset; 
> 
>     (void)send(session->chronyfd, &sample, sizeof (sample), 0);
> }
> 
> What seems off about this is that (I think) you've mentioned chronyd
> taking nanosecond-scale corrections before, yet the TSOTV steps precision
> down to microseconds. Is this correct?

FWIW:

ntpd-4.2.6p5's refclock_shm.c only accepts microsecond precision.

chronyd's refclock_shm.c appears to accept nanosecond precision, using
pad[]/dummy[] ints that ntpd-4.2.6p5 and gpsd (git head) don't use.

chronyd's refclock_pps.c appears to use nanoseconds.

chronyd's refclock_sock.c appears to use struct timeval sample.tv
(microsecond precision) along with the double sample.offset which
contributes to the nanosecond precision.  The way chronyd's
sample.offset contributes isn't immediately obvious in the
refclock_sock.c and refclock.c code, but it doesn't look too hard to
work out. 

Regards,
Andy