On Tue, Nov 3, 2015 at 11:18 AM, Stanton, Kevin B <kevin.b.stan...@intel.com> wrote: > On Wed, 21 Oct 2015, Thomas Gleixner wrote: >> On Tue, 20 Oct 2015, John Stultz wrote: >>> Being able to have various hardware sharing a time base is quite >>> useful, and methods for correlating timestamps together are useful. >>> But I don't yet really understand why its important that we can >>> translate a hardware timestamp from some time in the past to the >>> correct system time in the past without error. > >>If your device can only provide timestamps from the past, then >>having access to the history is important if you want to have >>precise correlation. > > I hope this can be solved in timekeeping. But first, a quick > recap... > > The timestamp pair (including the ART snapshot, as described > previously) is captured simultaneously by the hardware > resulting, effectively, in a (PTP,TSC) pair, or > (AudioPosition,TSC) pair. The in-the-past-TSC value needs to be > converted to system time so that it can be used by applications, > without exposing the underlying ART or TSC. > > Note: ART is architectural, defined as part of Invariant > Timekeeping in the current SDM, so this isn't a one-off > capability. > > To convert a past TSC timestamp to system time 'correctly' (in a > mathematical sense), a history of monotonic rate adjustments > since that time in the past must be maintained.
But again, my main problem is that I'm not totally understanding the rational. Here you're providing the *what*, not really the *why*. As I mentioned earlier, there are possibly simpler (at least for the kernel) ways to generate similar data using CLOCK_MONOTONIC_RAW, which has potentially a 500ppm error. *Why* is it important to add more complexity to the timekeeping core in order to avoid that error? > Regarding the amount of history, as Chris mentioned (and > in the context of new Intel hardware) LAN timestamp pairs are > a few microseconds in the past (no history would be required), > but for timestamps captured by the audio DSP, unfortunately, > they can be a small number of *milliseconds* in the past by the > time they're available to the audio driver (some history > required to convert accurately). I'm told that 4ms of adjustment > history accommodates known hardware. For a timestamp recorded 4ms ago, 500ppm of error is 2us. Why is 2us problematic for audio? That seems quite below the human threshold to notice. > Getting this 'correct' in one place (timekeeping) seems a lot > better than unnecessarily introducing inaccuracy via software > sampling (and extrapolation) or leaving it to each driver to do > it themselves, and to do it differently (and/or do it wrongly). Having a common infrastructure for extrapolating the data isn't something I'm objecting to. Its just that the shadow-timekeeper has been problematic enough in recent times bug wise, so I'm just hesitant to expand the complexity there. That said, I'm open to ideas, but would really like a better understanding of why other solutions would be insufficient, and why this one is the best solution. thanks -john -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
