> On 01/20/2023 2:11 AM PST Hal Murray <halmur...@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. _______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
