Input latency

[Daniel van Vugt]

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.

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