Xpra: Ticket #2037: Choose optimal starting parameters for local/mmap connections

Version: 2.4.1-r20894-1

Local/mmap'd connections seem to "speed up" after a few minutes of use - though they are pretty fast to begin with. It seems some starting parameters to the various algorithms are set "pessimistically" which while sensible for "real" network connections probably doesn't make sense for mmap/local. There doesn't seem to be anyway of overriding these choices as the various relevant options are disabled/grayed out for local connections..

< tc424> incidentally, I'm running some more "real world" tests with xpra using a local/mmap connection .. it seems like the latency improves after the session's been open a while (not that it's bad before)
< tc424> almost like some starting parameters are bit pessimistic, and get adjusted upwards?
<@totaam> tc424: that's right
<@totaam> that was done to be able to support ~5Mbps DSL connections
< tc424> ah, OK
< tc424> anyway to override that? Most of the normal controls are disabled for local/mmap...
<@totaam> tc424: yeah, it should be disabled for mmap / local
<@totaam> feel free to create a ticket
<@totaam> so I don't forget to fix that


Thu, 15 Nov 2018 02:43:29 GMT - Antoine Martin: priority, status, component changed

Links:

When mmap is enabled, we should start with a low batch delay, maximum quality and maximum speed. The latency values could also be causing problems: if min-latency is very low, any small jitter could make us increase the batch delay.


Fri, 23 Nov 2018 08:16:40 GMT - Antoine Martin: owner, status changed

Please try the latest beta builds and post xpra info for a session showing the symptoms of this "slow startup".


Tue, 27 Nov 2018 12:22:29 GMT - Antoine Martin:

Updates:

@tc424: is that better?


Sat, 19 Jan 2019 17:19:55 GMT - Antoine Martin: status changed; resolution set


Sat, 23 Jan 2021 05:40:28 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2037