On Thu, Oct 13, 2022 at 7:23 PM John Stultz <jstultz@xxxxxxxxxx> wrote: > > On Thu, Oct 13, 2022 at 7:15 PM John Stultz <jstultz@xxxxxxxxxx> wrote: > > > > On Thu, Oct 13, 2022 at 6:29 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > > > > On Thu, Oct 13, 2022 at 5:03 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > > > > > > On Wed, Oct 12, 2022 at 8:07 PM John Stultz <jstultz@xxxxxxxxxx> wrote: > > > > > > > > > > On Wed, Oct 12, 2022 at 8:02 PM John Stultz <jstultz@xxxxxxxxxx> wrote: > > > > > > On Mon, Sep 26, 2022 at 2:18 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > > > > So I think it reasonable to say its bounded by approximately 2 * > > > > > > NSEC_PER_SEC/HZ +/- 11%. > > > > > > > > > > Sorry, this should be 2*NSEC_PER_SEC/HZ * 0.11 > > > > > > > > Thanks so much for the detailed response :) > > > > > > > > IIUC this error bound is in ns. So on a 2 GHz cpu the bound is 0.11 ns > > > > (essentially 0)? I feel like I miscalculated, this error bound is too > > > > good to be true. > > > > > > Never mind, I thought HZ is the cpu speed for some reason. It's the > > > number of jiffies per second, right? > > > > Correct. > > > > > So if HZ is 1000, the error bound is actually ~2 ms, which is very > > > large considering that the unit is ns. > > > > Uh, for HZ=1000, I think it's closer to 220us, but yes, for HZ=100 2.2ms. > > And again, it has been awhile since I've been deep in this code, so > I'd not be surprised if I'm missing something and the worst case may > be larger (things like SMIs or virtualization stalling the timekeeping > update for longer than a tick). So no promises, but this feels pretty > close to the expected bound. If you can't handle time inconsistencies, > you need to use the normal locked accessors. > Thanks a lot for the clarification. The inconsistencies may be too large, depending on what we are trying to measure, so it is something that we need to keep in mind. > thanks > -john
