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 together are useful.
>>> But I d
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
>> tr
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 sampling. As John
> >>
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 whether the method in the
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
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 anothe
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 s
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 ti
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
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 getnstime_raw_and_re
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 be 8 instead. As above the useful history is
>>> 8-
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 would not be enough
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 time.
>
> > > +/* This
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 mid
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
> h
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 t
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 to get
into the DSP?
I'l
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 to be useful */
Wh
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 t
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.
>
>
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* sp
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 genera
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?
Tha
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 usef
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
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
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 o
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
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 = &tk_core.timekeeper;
> + unsigned long seq;
> + cycles_t cycles, cycle
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
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 from the device
clock
31 matches
Mail list logo
