On Mon, Dec 16, 2013 at 7:52 AM, Daniel van Vugt <daniel.van.v...@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.v...@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.v...@canonical.com <mailto:daniel.van.v...@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@lists.ubuntu.com <mailto:Mir-devel@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@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/mir-devel -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
