[chrony-dev] Re: [Gpsd-dev] linux pps support / NTPSHM update?

[<f96hajo@xxxxxxxxxxx>]

The attached small program is for monitoring the 'activity' on an NTPSHM 
segment, perhaps useful for some debugging.

> > I've filed a request in ntp bugzilla to extend the SHM protocol for
> > nanoseconds, but so far it was ignored.
>
> I have noticed the same limitation.  If you give me the bug number I
> will 'me too' it.  From the data I see I can expect short term stability
> better than 1uSec with that addition.  As ckeuthe mentioned early, that
> is way past that needed for any practical application, but fun.

Regarding updating the NTPSHM structure, I thought about this quite some 
while ago, but got stuck at the issue of how to make it backwards 
compatible in the light of mixed 32/64-bit installations discussed a while 
ago on the gpsd list.  Issue there is that an int can be both 32 and 64 
bits, thus even spoiling identifications by the 'mode' member.

Ideas:

- The entire structure should be defined with fixed widths from stdint.h
  to avoid further 32/64 bit issues.  I.e. mostly uint32_t.

- Thus, time fields not as time_t.  Full 64 bits for the seconds.  Should
  one perhaps use the NTP fractional second format instead of e.g.
  specifying the use of explicit nanoseconds?  64 bits here as well to
  prevent any further discussion?  Then also using the NTP epoch instead
  of the UNIX epoch?

- The members count and valid are needed for the protocol locking.

- precision and nsamples are not really useful/used.  Should one
  discontinue those?

- A bitmask to tell which fields (and to which width) have been filled,
  thus making the structure extensible.

- Making the structure sort of 'bi-directional', with the chronyd/ntpd
  process giving the current stratum and root delay and dispersion,
  reference time and ID.  For external program wanting to do time sync
  over a medium not supported natively by chronyd/ntpd.  Filling
  requested by a mask extension bit.  For this case also provide the
  chrony parameters describing a not yet completed clock-adjustment.

- Some sort of fall-back (how??) if the receiving end does not support
  the updated protocol?  Simply use a new NTPSHM_BASE ?  (also solves
  the combined 32-64 bit issue.)

Best regards,
HÃ¥kan

Attachment: mon_ntpshm.tar.gz
Description: Binary data