Artificial performance limitation

[Daniel van Vugt]

Bugger. Come to think of it, that only proves the bug exists. Not what 
the cause is. Because blocking for a full frame is correct if the event 
loop is idle. And blocking for two frames only demonstrates the bug 
exists and we're not meeting the frame deadline...


On 11/11/14 17:45, Daniel van Vugt wrote:
> 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
>>