Input latency

[Thomas Voß]

On Mon, Dec 16, 2013 at 7:52 AM, Daniel van Vugt
<daniel.van.vugt at canonical.com> wrote:
> Existing reports, output as logs, collated across the multiple processes
> using awk.
>
> The procedure of collating the data isn't relevant to the accuracy of the
> results. The accuracy hinges on the timestamps in the log reports, which
> seem pretty accurate (I've compared with other timing APIs). Perhaps some
> time in future we could convince LTTNG to correlate the data like my script
> does, but I'm not sure how to make LTTNG gather and match data across
> multiple processes.
>

Babeltrace (see http://lttng.org/babeltrace) is your friend here, it
allows for iterating and analyzing the traces.
Btw.: Multi-process tracing isn't a problem for LTTNG, you can easily
"tag" entries with the PID they originate from.

HTH,

  Thomas

> P.S. I wanted to attend your LTTNG talk in London but was trapped in a
> meeting at the time :)
>
>
>
> On 16/12/13 14:44, Thomas Voß wrote:
>>
>> On Mon, Dec 16, 2013 at 7:30 AM, Daniel van Vugt
>> <daniel.van.vugt at canonical.com> wrote:
>>>
>>> Yes indeed. I did think about that, but if you look at the merge proposal
>>> it's all about using the existing reports unmodified right now. And my
>>> primary task was to assess the feasibility of nesting vs non-nested.
>>>
>>> I wasn't going to spend any more time on input latency measurements this
>>> week but perhaps there is sufficient interest to get more details...
>>>
>>>
>>
>> Out of curiosity: When you say leveraging existing reports, does that
>> mean this evaluation is using the lttng traces?
>>
>> Thanks,
>>
>>    Thomas
>>
>>>
>>> On 16/12/13 14:27, Andreas Pokorny wrote:
>>>>
>>>>
>>>> Hi,
>>>> Can we split the times up? .. decoding from evdev until a EV_SYN ..
>>>> internal processing in the shell.. transfer to client?
>>>>
>>>>
>>>>
>>>> On Mon, Dec 16, 2013 at 6:52 AM, Daniel van Vugt
>>>> <daniel.van.vugt at canonical.com <mailto:daniel.van.vugt at canonical.com>>
>>>>
>>>> wrote:
>>>>
>>>>      If I had a theory, I could test if it correlates with the spikes.
>>>> At
>>>>      the moment I don't even have a theory.
>>>>
>>>>      The other weird thing I didn't mention was that the "lowlatency"
>>>>      kernel has higher latency :). But it was worth a try. As are
>>>>      different kernel schedulers, I haven't tried playing with them yet.
>>>>
>>>>
>>>>
>>>>      On 13/12/13 18:27, Christopher James Halse Rogers wrote:
>>>>
>>>>          On Fri, 2013-12-13 at 17:31 +0800, Daniel van Vugt wrote:
>>>>
>>>>              Here are some fun numbers I've collected about the latency
>>>>              between input
>>>>              events sent from the top-level Mir server to a client. All
>>>> in
>>>>              milliseconds...
>>>>
>>>>              Desktop (3.12.0-7-generic)
>>>>              Direct 0.8ms
>>>>              Nested 1.3ms
>>>>
>>>>              Desktop (3.11.0-11-lowlatency)
>>>>              Direct 1.0ms
>>>>              Nested 1.7ms
>>>>
>>>>              Nexus4 (3.4.0-3-mako)
>>>>              Direct 0.9ms
>>>>              Nested 1.5ms with high variance; frequent spikes to 73ms.
>>>>              Sometimes 700ms.
>>>>
>>>>
>>>>          Do we have any way to get insight into the spikes? Something
>>>>          strange is
>>>>          obviously happening when the variance is ~3 orders of
>>>> magnitude.
>>>>
>>>>
>>>>
>>>>
>>>>      --
>>>>      Mir-devel mailing list
>>>>      Mir-devel at lists.ubuntu.com <mailto:Mir-devel at lists.ubuntu.com>
>>>>
>>>>      Modify settings or unsubscribe at:
>>>>      https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>>>>      <https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>>>>
>>>>
>>>
>>> --
>>> Mir-devel mailing list
>>> Mir-devel at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/mir-devel