Artificial performance limitation

[Daniel van Vugt]

Found!

Instrumenting AsioMainLoop [replace run() with a loop around run_once()] 
you see with one client you get one task executing per frame, which 
blocks the whole event loop (idlely not using CPU) for 16.6ms every frame:

Run 0.016630977 sec
Run 0.016647716 sec
Run 0.016633778 sec
...

Additional clients only block the event loop for a fraction of a 
millisecond more. e.g. 3 clients:

Run 0.016463334 sec
Run 0.000024074 sec
Run 0.000048409 sec
Run 0.016543939 sec
Run 0.000022160 sec
Run 0.000048854 sec
Run 0.016558223 sec
Run 0.000021511 sec
Run 0.000047816 sec
Run 0.016546486 sec
Run 0.000022321 sec
Run 0.000048090 sec

However at 9-10 clients (on a Haswell i7), the time spent blocking in 
some AsioMainLoop iterations becomes two frames (hence visible frame 
skipping):

Run 0.033355181 sec
Run 0.000021174 sec
Run 0.000007288 sec
Run 0.000024818 sec
Run 0.000021997 sec
Run 0.000122351 sec
Run 0.000001801 sec
Run 0.000001012 sec
Run 0.000001152 sec
Run 0.000003406 sec
Run 0.032885940 sec
Run 0.000010293 sec
Run 0.000010438 sec
Run 0.000010319 sec
Run 0.000023508 sec
Run 0.000042345 sec
Run 0.000016997 sec
Run 0.000022163 sec
Run 0.000015114 sec
Run 0.000031571 sec

I think any task running in AsioMainLoop that blocks at all (>1ms) is a 
bug... So any experts on AsioMainLoop know where we're submitting 
blocking tasks to the poor overworked AsioMainLoop?

- Daniel


On 03/11/14 08:36, Daniel van Vugt wrote:
> This bug and its sister bug are driving me crazy:
> https://bugs.launchpad.net/mir/+bug/1388490
> https://bugs.launchpad.net/mir/+bug/1377872
>
> I can see in both cases that the frame rate ceiling is arbitrary and
> temporary. It has nothing at all to do with the power of the host. And
> the workaround that fixes the problem in both cases is a bit crazy.
>
> I've so far investigated theories around:
>    * buffer lifetimes
>    * Mesa/intel GL batching bugs
>    * lock contention (locks held too long)
>    * power management modes
>    * Mir socket/protocol bottlenecks
>
> All the theories have some merit but I am not making progress. If you
> are (un)lucky enough to be able to reproduce either bug then please join
> in. More data points are required.
>
> - Daniel
>