> When you check the elapsed time, you subtract the old time from the new time. But if the new time is less than the old time, you get an overflow. Because we save time as an unsigned integer, you get a very large number that will for sure be larger than any timeout value you set, including our default 3 minutes.

If they were using unsigned arithmetic then they would've gotten the expected value. For example, 0 - 0xffffffffffffffff is 1 when using 64-bit types, just as one might expect. Unsigned (modulo) arithmetic works exactly how you'd want in a situation like this; it works until the interval exceeds the range of the type. So either they're describing things wrong, or their code wasn't doing what they thought.

Of course, in any event this wouldn't be the root of their problem--time stamp counter drift across cores. The Linux kernel has alot of code to decide whether to use the RDTSC-optimized clock_gettime vDSO implementation or fallback to a syscall. And when it does use the RDTSC method, IIRC it has code to train the time stamps to minimize any cross-core drift, and mask out any potential difference (reducing granularity). The moral of the story is to just use clock_gettime+CLOCK_MONOTONIC; at least on Linux it'll use RDTSC in most cases where that's practical.