Reading the linked issues: it seems like the problem is that monotonic time on Windows is broken, QueryPerformanceCounter should return monotonic values, but it doesn't (when running on a hypervisor?)
The Time to Live in the IP header is specified in seconds, but also that every system that processes the packet must decrement the field, it is effectively a hop count (even if the system can “process the packet in less than a second,” it was a different time).
This is semi-OT but thought I would drop it here since it burned me: don't use CLOCK_MONOTONIC_RAW on Linux to try to get better perf than CLOCK_MONOTONIC. The latter has a vDSO fastpath and the former does not.
A kernel bug for this on x86_64 has been open since 2018:
I think this only works if you assume that getting the current time can only be done once per nanosecond. I think this is probably true in most cases, but might not be true if rdtsc is used as the clock source.
tobin_baker | 19 hours ago
I already use this rule with hybrid logical clocks: every read advances the time.
Nezteb | 18 hours ago
I like the Elixir/Erlang method of strictly monotonic time tagging.
tldr: You store monotonic time alongside a monotonic unique integer (and optionally an offset). Example Livebook code: https://gist.github.com/Nezteb/aff615f423fbd3e2fb219414e2172829
edwintorok | 11 hours ago
Reading the linked issues: it seems like the problem is that monotonic time on Windows is broken, QueryPerformanceCounter should return monotonic values, but it doesn't (when running on a hypervisor?)
lorddimwit | 6 hours ago
The Time to Live in the IP header is specified in seconds, but also that every system that processes the packet must decrement the field, it is effectively a hop count (even if the system can “process the packet in less than a second,” it was a different time).
tobin_baker | 3 hours ago
This is semi-OT but thought I would drop it here since it burned me: don't use CLOCK_MONOTONIC_RAW on Linux to try to get better perf than CLOCK_MONOTONIC. The latter has a vDSO fastpath and the former does not.
A kernel bug for this on x86_64 has been open since 2018:
https://bugzilla.kernel.org/show_bug.cgi?id=198961.
However, it appears to be fixed on ARM (but I haven't verified):
https://lore.kernel.org/linux-arm-kernel/20190621095252.32307-1-vincenzo.frascino@arm.com/.
algesten | 5 hours ago
Can Windows handle 1ns time resolution these days?
maxm | 5 hours ago
nice, i’ve used this trick to make sure observably information is correctly ordered
YogurtGuy | 5 hours ago
I think this only works if you assume that getting the current time can only be done once per nanosecond. I think this is probably true in most cases, but might not be true if
rdtscis used as the clock source.