Daniel van Vugt
daniel.van.vugt at canonical.com
Mon Dec 16 06:30:15 UTC 2013
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...
On 16/12/13 14:27, Andreas Pokorny wrote:
> 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>>
> 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
> 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:
More information about the Mir-devel