Messages in this thread | | | Date | Thu, 25 Oct 2018 13:49:44 +0200 | From | Miroslav Lichvar <> | Subject | Re: TSC to Mono-raw Drift |
| |
On Wed, Oct 24, 2018 at 01:32:48PM -0400, Christopher Hall wrote: > On Wed, Oct 24, 2018 at 04:51:13PM +0200, Miroslav Lichvar wrote: > > The error is too large to be corrected by stepping on clock updates. > > For a typical TSC frequency we have multiplier in the range of few > > millions, so that's a frequency error of up to few hundred ppb. In the > > For this example, a i5-6600 CPU @ 3.30GHz I measured 90 ppb. That is the > largest I've seen since measuring this on a few platforms. 20-40 PPB seems > more typical.
It looks like there is rounding in the calculation of the multiplier, so for frequencies in the range of 3-5GHz the error will be up to about 149 ppb. Without rounding it would be twice as much, but always fast or slow.
> > A better fix might be to modify the calculation of time to use a > > second multiplier, effectively increasing its resolution. However, > > I'm not sure, I'm understanding. Like cascading transforms? While this > would increase the precision, I think it would still drift over days. We > could probably fix up every second though.
I was thinking about using a wider multiplier, but avoiding a full 64x64 bit multiplication.
For example, in your case with the 3312MHz clock
nsec = (cycles * 5065585) >> 24
could be replaced with
nsec = (cycles * 5065584) >> 24 + (cycles * 4538763) >> 47
This would take few hours to drift by one nanosecond. If something like this was implemented for the raw clock, it would probably make sense to switch the other clocks too.
> > that would slow down all users of the clock. > > Couldn't some clocksources specify an additional multiplier/precision and > others use lower precision?
I guess it could, but I'm not sure if people here would be happy with the extra complexity.
-- Miroslav Lichvar
| |