on 20/06/2009 19:29 Thomas Backman said the following: > It appears the DTrace "timestamp" variable is wrapping around way, way > too quickly - it only goes to somewhere slightly above 2^33 (in > practice, at least), and since it's in nanoseconds, that's not a lot. > (2^33 ns is less than 10 seconds, actually. 2^64 is 584.55 years, however!) [snip] > uint64_t > dtrace_gethrtime() > { > return ((rdtsc() + tsc_skew[curcpu]) * (int64_t) 1000000000 / tsc_freq); It appears that (rdtsc() + X) * 10^9 overflows 64-bit value for sufficiently small values of rdtsc. BTW, I think it would have been better/clearer to use uint64_t in the cast. I think that to minimize overflow and sufficiently accurate result a formula like the following could be used: x = rdtsc() + tsc_skew[curcpu]; sec = x / tsc_freq; r = x % tsc_freq; res = sec * 10^9 + (r * 10^9 / tsc_freq); I have not tested the formula. I have suspicions about its accuracy in the edge cases, esp. if tsc_freq > (2^64 - 1) / 10^9 (not sure if have that in reality). -- Andriy GaponReceived on Mon Jun 22 2009 - 09:07:49 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:50 UTC