Xpra: Ticket #181: to yield or not to yield
r1365 introduced the
XPRA_YIELD environment variable to toggle thread yielding in both network threads (protocol.py) and encoding thread (server_source.py).
Which means we now have graphs comparing with/without yield (also split between each type of yield) here:
- each page has two sets of graphs: there is no download limit in the top half and (128-KB/s-down, 32-KB/s-up, 100ms-latency) in the bottom half
- gtkperf is problematic throughout.. (beware when looking at specific graphs: in some cases it performed very badly, which means other measures like latency will actually look good!)
- deluxe and polytopes benefit a lot from yielding with download limits
- the client latency has some conflicting results, 'eruption' is much worse with yielding but most other tests are either unchanged or much improved ('polytopes', 'rss-glx*')
- the number of packets sent is the same or higher when yielding
- we manage to send more pixels/s, although it seems that in a number of cases only one type of yielding is beneficial and having both negates the gains (and in a few cases, actually perform worse!)
- apart from 'polytopes' and 'eruption', when it comes to regions/s, the yielding in the network code is the big winner
And so, the conclusion is... to leave it as it is for now and run more tests once a few other performance/latency issues are resolved.
Thu, 27 Sep 2012 15:25:41 GMT - Antoine Martin: status, milestone changed
changed from new to accepted
changed from 0.6 to 0.8
Review with 0.7 release:
- we have more threads on the client with the new decoding thread, maybe we need to yield more?
- latency is now much better - maybe this will have more/less of an impact?
Mon, 11 Feb 2013 16:36:23 GMT - Antoine Martin: status changed; resolution set
changed from accepted to closed
set to worksforme
We may revisit things later, but this seems to work ok for now.
Sat, 23 Jan 2021 04:47:44 GMT - migration script:
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/181