On Thu, Sep 3, 2015 at 4:20 PM, Hall, Christopher S <christopher.s.h...@intel.com> wrote: > For example, supply the ART value as an argument and, in the case of the > realtime > clock, keep a short history of clock changes. It would fail in cases where > there > are a lot of calls to adjtimex(), but it will would work most of the time.
So, I really don't think something like this would be reasonable. For one, keeping track of the adjtimex adjustments would be difficult enough to do sanely, but the real issue is that the clock has its own long-term error correction adjustments that it does in order to keep long term frequency accuracy with coarsely adjusted clocksources. Trying to track those small oscillation intervals would be even more complicated. I still think that being able to calculate the CLOCK_MONOTONIC_RAW value for a given ART counter value is reasonable, and then one can use the getnstime_raw_and_real() to get a current raw/real sync point, which you can then calculate the raw delta, and subtract that from the sycned real timestamp. You're error there would be bound by the maxium clocksource adjustment rate * the raw-delta interval length. To clarify on the need to understand if this error would be reasonable, can you provide a sense of what the delay from an ART read to trying to calculate a REALTIME value might be? thanks -john -- 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/
