On Sat, Nov 9, 2024 at 9:07 AM Sergey Prokhorenko <sergeyprokhore...@yahoo.com.au> wrote: > > On Saturday 9 November 2024 at 01:00:15 am GMT+3, Masahiko Sawada > <sawada.m...@gmail.com> wrote: > > > the microsecond part is working also as a counter in a sense. IT seems fine > > to me but I'm slightly concerned that there is no guidance of such > > implementation in RFC 9562. > > In fact, there is guidance of similar implementation in RFC 9562: > https://datatracker.ietf.org/doc/html/rfc9562#name-monotonicity-and-counters > "Counter Rollover Handling:" > "Alternatively, implementations MAY increment the timestamp ahead of the > actual time and reinitialize the counter." >
Indeed, thank you. > But in the near future, this may not be enough for the highest-performance > systems. Yeah, I'm concerned about this. That time might gradually come. That being said, as long as rand_a part works also as a counter, it's fine. Also, 12 bits does not differ much as Andrey Borodin mentioned. I think in the first version it's better to start with a simple implementation rather than over-engineering it. Regarding the implementation, the v30 patch uses only microseconds precision time even on platforms where nanoseconds precision is available such as Linux. I think it's better to store the value of (sub-milliseconds * 4096) into 12-bits of rand_a space instead of directly storing microseconds into 10 bits space. That way, we can use nanoseconds precision timestamps where available. On some platforms such as macOS, the sub-milliseconds precision timestamp is restricted to microseconds, we can consider it as a kind of special case. If 12-bits of rand_a space is not enough to guarantee monotonically in the future, it is also possible to improve it by putting a (random) counter into rand_b. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
