On Thu, Sep 10, 2015 at 11:14:25AM -0700, John Stultz wrote: > On Thu, Sep 10, 2015 at 10:42 AM, John Stultz <john.stu...@linaro.org> wrote: > > On Thu, Sep 10, 2015 at 5:02 AM, Miroslav Lichvar <mlich...@redhat.com> > > wrote: > >> The precision of the clock is better than microsecond, so that > >> wouldn't explain a 12 ppm error over the 15 second interval. I guess > >> it's due to a larger xtime_remainder, which basically is a hidden > >> frequency offset added (and not multiplied) to the NTP frequency > >> offset. Would that explain it? > > > > I think its due to the ntp_error being large enough prior (or during > > the freq transition) that we're still applying a single unit freq > > adjustment for that error. But I'm guessing on the acpi_pm clocksource > > the shift is low enough that a single unit adjustment is coarse enough > > to affect the ppm, since I see the same consistently measured ppm > > result if I both increase the settling time measurement sleep times. > > If I left it for a long long time, the single unit correction would > > likely null the error out and we'd get the desired result, but I don't > > think the test has time for that.
I ran few tests and it doesn't seem to be a problem with large ntp_error or an extremely slow adjustment of the multiplier for the new frequency. I think it really is the xtime_remainder correction. It is a fixed offset added to the ntp error on each tick to compensate for the cycle_interval rounding error. With the acpi_pm clocksource and 1000Hz update rate xtime_remainder is -127 ns, which effectively speeds up the clock by 127 ppm. When NTP slows the clock down by 10%, the correction is not decreased by 10% and we can observe the clock is running faster by 12.7 ppm than expected. Is there a cheap way to calculate this? xtime_remainder * (ntp_tick >> ntp_error_shift) / NTP_INTERVAL_LENGTH > So bumping the fail level to > 100ppm avoids false positives due to > long-term error correction with coarse clocksources, but still is > tight enough to catch the dampened approximation issue caused by the > abs(s64) problem. > > Any objection to moving to that? It is still a 0.01% error bound. No objection from me as long as we understand where that error is coming from. -- Miroslav Lichvar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
