On Thu, 2024-06-20 at 17:19 +0100, David Woodhouse wrote: > > > > > > + > > > + /* Counter frequency, and error margin. Units of (second >> 64) */ > > > + uint64_t counter_period_frac_sec; > > > > AFAIU this might limit the precision in case of high counter frequencies. > > Could the unit be aligned to the expected frequency band of counters? > > This field indicates the period of a single tick, in units of 1>>64 of > a second. That's about 5.4e-20 seconds, or 54 zeptoseconds? > > Can you walk me through a calculation where you believe that level of > precision is insufficient? > > I guess the precision matters if the structure isn't updated for a long > period of time, and the delta between the current counter and the > snapshot is high? That's a *lot* of 54 zeptosecondses? But you really > would need a *lot* of them before you care? And if nobody's been > calibrating your counter for that long, surely you have bigger worries? > > Am I missing something there? Hm, that was a bit rushed at the end of the day; let's take a better look... Let's take a hypothetical example of a 100GHz counter. That's two orders of magnitude more than today's Arm arch counter. The period of such a counter would be 10 picoseconds. (Let's ignore the question of how far light actually travels in that time and how *realistic* that example is, for the moment.) It turns out that at that rate, there *are* a lot of 54 zeptosecondses of precision loss in the day. It could be half a millisecond a day, or 20µs an hour. That particular example of 10 picoseconds is 184467440.7370955 (seconds>>64) which could be truncated to 184467440 — losing about 4PPB (a third of a millisecond a day; 14µs an hour). So yeah, I suppose a 'shift' field could make sense. It's easy enough to consume on the guest side as it doesn't really perturb the 128-bit multiplication very much; especially if we don't let it be negative. And implementations *can* just set it to zero. It hurts nobody. Or were you thinking of just using a fixed shift like (seconds>>80) instead?
<<attachment: smime.p7s>>
