Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Nov 3, 2015 at 11:18 AM, Stanton, Kevin B 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

RE: [PATCH v4 1/4] Produce system time from correlated clocksource

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 >>

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, 20 Oct 2015, John Stultz wrote: > On Tue, Oct 20, 2015 at 12:11 PM, Thomas Gleixner wrote: > > On Tue, 20 Oct 2015, Richard Cochran wrote: > >> On Tue, Oct 20, 2015 at 01:51:13PM +0200, Richard Cochran wrote: > >> > You can, in fact, achieve "proper" correlation by

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Mon, Oct 19, 2015 at 05:36:56PM -0700, John Stultz wrote: > If we're only tracking 4ms of history, how does this solution > measurably improve the error over using the timestamps to generate > MONOTONIC_RAW clock deltas (which doesn't require keeping any history) > and using

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, 20 Oct 2015, Richard Cochran wrote: > On Mon, Oct 19, 2015 at 05:36:56PM -0700, John Stultz wrote: > > If we're only tracking 4ms of history, how does this solution > > measurably improve the error over using the timestamps to generate > > MONOTONIC_RAW clock deltas (which doesn't require

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 20, 2015 at 12:48:03PM +0200, Thomas Gleixner wrote: > On Tue, 20 Oct 2015, Richard Cochran wrote: > > > On Mon, Oct 19, 2015 at 05:36:56PM -0700, John Stultz wrote: > > > If we're only tracking 4ms of history, how does this solution > > > measurably improve the error over using the

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, 20 Oct 2015, Richard Cochran wrote: > On Tue, Oct 20, 2015 at 01:51:13PM +0200, Richard Cochran wrote: > > You can, in fact, achieve "proper" correlation by sampling. As John > > said, the question is whether the method in the patch set "measurably > > improves the error" over using

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 20, 2015 at 09:11:21PM +0200, Thomas Gleixner wrote: > Darn, we don't want to have that kind of sampling in every driver > which has this kind of problem even if it looks like the simpler > choice for this particular use case. This is going to be something > which next generation chips

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 20, 2015 at 12:11 PM, Thomas Gleixner wrote: > On Tue, 20 Oct 2015, Richard Cochran wrote: >> On Tue, Oct 20, 2015 at 01:51:13PM +0200, Richard Cochran wrote: >> > You can, in fact, achieve "proper" correlation by sampling. As John >> > said, the question is

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 20, 2015 at 01:51:13PM +0200, Richard Cochran wrote: > You can, in fact, achieve "proper" correlation by sampling. As John > said, the question is whether the method in the patch set "measurably > improves the error" over using another, simpler method. Here is a short example to put

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

Thomas, On Thu, 15 Oct 2015 01:15:57 -0700, Thomas Gleixner wrote: > > > +#define SHADOW_HISTORY_DEPTH 7 > > And that number is 7 because? Due to power of 2 it will be 8 instead. As above the useful history is 8-2*1 ms (1 ms is the minimum jiffy length). Array size 4

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Mon, Oct 19, 2015 at 5:18 PM, Christopher Hall wrote: > On Thu, 15 Oct 2015 01:15:57 -0700, Thomas Gleixner > wrote: >>> >>> > >>> > > +#define SHADOW_HISTORY_DEPTH 7 >>> > >>> > And that number is 7 because? >>> >>> Due to power of 2 it will

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Wed, 14 Oct 2015, Christopher Hall wrote: > On Tue, 13 Oct 2015 12:42:52 -0700, Thomas Gleixner > wrote: > > On Mon, 12 Oct 2015, Christopher S. Hall wrote: > > > audio. > > > > This wants to be a seperate patch, really. > > OK. This makes sense, I'll do this the next

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Thu, 15 Oct 2015, Richard Cochran wrote: > Thomas seems to say that there are *other* applications that will want > to transform device time into system time, but why does your audio > application use the system time, when the audio-to-ptp time is > directly available, without any man in the

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Wed, Oct 14, 2015 at 04:22:03PM +0200, Thomas Gleixner wrote: > It's not only the DSP. There is a bunch of usre space software > involved as well. Care to think about the full picture and not just > about some randomly chosen single problem out of the full problem > space. I would surely like

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Wed, 14 Oct 2015, Richard Cochran wrote: > On Wed, Oct 14, 2015 at 09:21:42AM +0200, Thomas Gleixner wrote: > > The firmware gives you an ART/audio timestamp pair. The firmware does > > neither know about system time nor about PTP time. > > > > So we have to do correlation in software. > >

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, 13 Oct 2015, Richard Cochran wrote: > On Tue, Oct 13, 2015 at 09:15:51PM +0200, Thomas Gleixner wrote: > > That's not working. The firmware is not going to change, no matter > > what. > > Can we at least have a explanation of how the firmware operates? How > are (ART,sys) pairs are

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Wed, Oct 14, 2015 at 09:21:42AM +0200, Thomas Gleixner wrote: > The firmware gives you an ART/audio timestamp pair. The firmware does > neither know about system time nor about PTP time. > > So we have to do correlation in software. Ok, so give me the ART/audio and two recent ART/ptp times*

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

Thomas, On Tue, 13 Oct 2015 12:42:52 -0700, Thomas Gleixner wrote: On Mon, 12 Oct 2015, Christopher S. Hall wrote: audio. This wants to be a seperate patch, really. OK. This makes sense, I'll do this the next time. +/* This needs to be 3 or greater for backtracking

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

Richard, On Tue, 13 Oct 2015 14:12:24 -0700, Richard Cochran wrote: On Tue, Oct 13, 2015 at 09:15:51PM +0200, Thomas Gleixner wrote: Can we at least have a explanation of how the firmware operates? How are (ART,sys) pairs are generated, and how they are supposed

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Wed, Oct 14, 2015 at 07:34:03PM -0700, Christopher Hall wrote: > I hope this is helpful. Thanks. So the DSP does not produce or consume system time stamps. Fine. Still I fail to understand why you need the system time. Thomas seems to say that there are *other* applications that will want to

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Wed, Oct 14, 2015 at 06:57:33PM -0700, Christopher Hall wrote: > >>+#define SHADOW_HISTORY_DEPTH 7 > > > >And that number is 7 because? > > Due to power of 2 it will be 8 instead. As above the useful history is 8-2*1 > ms (1 ms is the minimum jiffy length). Array size 4 would not be enough >

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 13, 2015 at 09:51:02AM +0200, Thomas Gleixner wrote: > > You are restricting the problem space to this particular use > case. There are other use cases where PTP is not available or not the > relevant reference, but you still want to correlate time domains to > ART. They may well be

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, 13 Oct 2015, Richard Cochran wrote: > On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote: > > The transforms such an application would > > perform are: > > > > System Clock <-> Audio clock > > System Clock <-> Network Device Clock [<-> PTP Master Clock] > > This is extra

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

Now that I am starting to understand what this code is trying to achieve... On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote: > The modification to the original patch accomodates these > slow devices by adding the option of providing an ART value outside > of the retry loop and

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, 13 Oct 2015, Richard Cochran wrote: > On Tue, Oct 13, 2015 at 09:51:02AM +0200, Thomas Gleixner wrote: > > > > You are restricting the problem space to this particular use > > case. There are other use cases where PTP is not available or not the > > relevant reference, but you still want

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Mon, 12 Oct 2015, Christopher S. Hall wrote: > Another representative use case of time sync and the correlated > clocksource (in addition to PTP noted above) is PTP synchronized > audio. This wants to be a seperate patch, really. > +/* This needs to be 3 or greater for backtracking to be

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 13, 2015 at 09:15:51PM +0200, Thomas Gleixner wrote: > That's not working. The firmware is not going to change, no matter > what. Can we at least have a explanation of how the firmware operates? How are (ART,sys) pairs are generated, and how they are supposed to get into the DSP?

[PATCH v4 1/4] Produce system time from correlated clocksource

From: Thomas Gleixner Modern Intel hardware provides the so called Always Running Timer (ART). The TSC which is usually used for timekeeping is derived from ART and runs with a fixed frequency ratio to it. ART is routed to devices and allows to take atomic timestamp samples

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote: > Another representative use case of time sync and the correlated > clocksource (in addition to PTP noted above) is PTP synchronized > audio. The added explanations of the audio use case do help. However, you did not address my

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote: > +int get_correlated_timestamp(struct correlated_ts *crt, > + struct correlated_cs *crs) > +{ > + struct timekeeper *tk = _core.timekeeper; > + unsigned long seq; > + cycles_t cycles,