Re: New SHM layout from gpsd

[James Browning]

> On 01/20/2023 2:11 AM PST Hal Murray <halmurray@sonic.net> wrote:
> 
> 
> The 31 bit idea seems strange/ugly to me. How did you decide to do it that
> way?

It is either Richard's fault or, more likely, mine. I proposed
replacing the current SHM, and I need to communicate better. My
alternate had a shared half-era counter instead of the upper 32
bits for each time stamp. It is the sort of EEish
micro-optimization that some people would fawn over. It was also
going to use POSIX shared memory which is out.

> Why is it better than 32 unsigned bits? Is there some case that works with 31
> bits that breaks with 32?

No benefit you would consider worth the downsides.

> I think there is a case that works for 32 unsigned that doesn't work for 31.
> Consider code that gets updated to use 64 bit time_t but they forget to update
> the SHM interface. That will pick up the 32nd bit and do the right think for
> another 68 years.

NTP-associated time beginnings... (skip this probably)
1968-01-20T03:14:08 - second half of NTP era 0
1970-01-01T00:00:00 - POSIX era 0
1980-01-01T00:00:00 - GPS week 0
1999-08-17T00:00:00 - GPS week 1024
2019-04-08T00:00:00 - GPS week 2048
2036-02-07T06:28:16 - first half of NTP era 1
2038-01-19T03:14:08 - second half of POSIX era 0
2038-11-16T00:00:00 - GPS week 3072
2058-07-02T00:00:00 - GPS week 4096
2078-02-15T00:00:00 - GPS week 5120
2097-10-01T00:00:00 - GPS week 6144
2104-02-26T09:42:24 - second half of NTP era 1
2106-02-07T06:28:16 - first half of POSIX era 1
2117-50-18T00:00:00 - GPS week 7168
2137-01-01T00:00:00 - GPS week 8192

> An alternative would be to make the new high-bit slots into 64 bits and make
> the rule use-them, ignore the old slot. That would eat 2 more dummy words.

I would prefer we kill it and put something a little better
specified in its' place. Not the thing I originally specced
because sockets are the new awesome.