On Fri, Oct 19, 2018 at 11:37 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > On Fri, 19 Oct 2018, Thomas Gleixner wrote: >> On Mon, 15 Oct 2018, Christopher Hall wrote: >> > TSC kHz used to calculate mult/shift value: 3312000 >> >> Now the most interesting information here would be the resulting mult/shift >> value which the kernel uses. Can you please provide that? > > But aside of the actual values it's pretty obvious why this happens. It's a > simple rounding error. Minimal, but still. To avoid rounding errors you'd > have to find mult and shift values which exactly result in: > > (freq * mult) >> shift = 1e9 > > which is impossible for freq = 3312 * 1e6. Right. > A possible fix for this is, because the error is in the low PPB range, to > adjust the error once per second or in some other sensible regular > interval. Ehh.. I mean, this is basically what all the complicated ntp_error logic does for the long-term accuracy compensation. Part of the allure of the raw clock is that there is no changes made over time. Its a very simple constant calculation. We could try to do something like pre-seed the ntpinterval value so the default ntp_tick value corrects for this, but that's only going to effect the monotonic/realtime clock until ntpd or anyone else sets a different interval rate. So I'm not particularly eager in trying to do the type of small frequency oscillation we do for monotonic/realtime for long-term accuracy to the raw clock as that feels a bit antithetical to the point of the raw clock. I guess I'd want to understand more of the use here and the need to tie the raw clock back to the hardware counter it abstracts. thanks -john
