shallow thoughts on SHM

[James Browning]

The length of the SHM construct appears to date back to 1997 at that
time according to Wikipedia only four processor architectures had
64-bit address spaces. I have no information on the prevalence of
64-bit processors. However, I think it is reasonable to assume that
the integers of that time defaulted to 32 bits, as did time_t.
resulting in an SHM struct that used 40 bytes of data and had another
40 unused, revised to a 48/32 split when nanoseconds were added.

I would like to propose a new SHM implementation that uses 12-byte
timestamps, a uint32_t for each of NTP epoch, seconds into epoch and
gammaseconds. Furthermore, I would like to suggest a trio of timestamp
pairs. resulting in 72 bits of horological mediocrity and 4 bytes as
a new header, 8 bytes as an optional pointer to another SHM segment
and 12 bytes for a text field that could be returned for ntpq like
queries to the receiving implementation.

given that SHM seems to throw around 4KiB pages. an implementation
where 32 128-byte subpackets should be possible. That would allow a
four-byte field for refid, a greatly expanded text field, or possibly
64-bit second fragments.

   [00] uint_8 mode
   [01] uint_8 leap
   [02] uint_8 board validity
   [03] uint_8 precision
[04-11] u64_p next_shim_segment
[12-23] l_fp2 a_refclockstamp
[24-35] l_fp2 a_sysclockstamp
[36-47] l_fp2 b_refclockstamp
[48-59] l_fp2 b_sysclockstamp
[60-71] l_fp2 c_refclockstamp
[72-83] l_fp2 c_sysclockstamp
[84-95] char[12] freee text

-- or --

    [000] uint_8 mode
    [001] uint_8 leap
    [002] uint_8 valid board
    [003] uint_8 precision
[004-015] l_fp2 a_refclockstamp
[016-027] l_fp2 a_sysclockstamp
[028-039] l_fp2 b_refclockstamp
[040-051] l_fp2 b_sysclockstamp
[052-063] l_fp2 c_refclockstamp
[064-075] l_fp2 c_sysclockstamp
[076-124] char[48] free text
[124-127] char[4] refid

board valid values (all other values reserved)
0x00 board SHM uninitialized
0x01 board a valid (writing board b)
0x01 board b valid (writing board c)
0x01 board c valid (writing board a)
0x81 board a valid (going to write board b)
0x82 board b valid (going to write board c)
0x83 board c valid (going to write board a)

leap and precision values as per ntpv4
mode (0 and 1 as per current implementation,
      2 = Garys read-only mode,
      3 = whatever this becomes,
      4+ reserved for future expansion)

The first process to access SHM should allocate and if necessary zero
it out. refclocks should the first open segment write all the header
fields except valid, then plant timestamps in board A, finally, it
should write the octet 0x81 in the valid field.

Subsequent writes might involve, unsetting the high bit, writing the
new timestamps to the next board in rotation and finally, writing the
new octet to the valid field.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20191026/1ab6eea5/attachment.htm>