Related to #619 and ticket:2121#comment:5.
We know when there are more chunks to be written to the socket, so we can use TCP_CORK.
Done in r21517. (note: no support for BSD OS variants - patches welcome)
Results in aggregated TCP packet chunks for large packets (ie: "draw"), including on websockets and SSL. As per example in ticket:2121#comment:5, the PNG pixel data and the xpra packet metadata no longer require an extra TCP frame:
T 127.0.0.1:10000 -> 127.0.0.1:38956 [AP] #12476 82 7e 00 b5 50 00 00 07 00 00 00 7a 89 50 4e 47 .~..P......z.PNG 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 00 00 00 0c ........IHDR.... 00 00 00 0d 08 02 00 00 00 12 4b 18 15 00 00 00 ..........K..... 41 49 44 41 54 78 5e 63 fc ff ff 3f 03 2a 60 64 AIDATx^c...?.*`d 64 44 13 61 42 e3 63 e5 42 15 61 ea 46 56 0d 52 dD.aB.c.B.a.FV.R 84 5f 05 50 01 13 50 05 a6 b3 d0 dd 44 50 05 c8 ._.P..P.....DP.. 24 12 1c 8e 5f 29 f5 4c 42 b7 07 ab 3f 58 a8 e6 $..._).LB...?X.. 3b 00 f7 39 0f 17 4e 12 5b 8c 00 00 00 00 49 45 ;..9..N.[.....IE 4e 44 ae 42 60 82 50 00 00 00 00 00 00 2b 6c 34 ND.B`.P......+l4 3a 64 72 61 77 69 31 65 69 31 37 65 69 31 35 65 :drawi1ei17ei15e 69 31 32 65 69 31 33 65 33 3a 70 6e 67 30 3a 69 i12ei13e3:png0:i 31 34 65 69 30 65 64 65 65 14ei0edee #
@maxmylin: Just like #619, this should result in slightly lower bandwidth / better bandwidth utilization, and lower latency. Most noticeable on low-bandwidth setups.
test of cork on and off
What do you think of this as a baseline for testing with bandwidth constraints.
I think I may need longer tests for these I was only testing with rgb and auto encodings.
I don't see the raw test data, what was the bandwidth constraint used?
Looks like the gtkperf test failed with CORK=0. (no data)
The only surprise so far is how the max-damage-latency is quite a bit higher and the min-quality is lower. It could be that using TCP_CORK
makes the network layer push back more aggressively - which is not a bad thing. (fits with the lower max-batch-delay which is more coarse grained than damage-latency)
We would need to get the round-trip latency figures to verify that.
As per ticket:619#comment:27, it would be useful to combine CORK with NODELAY.
As per ticket:619#comment:29, this is better, even without measuring the effect on end-to-end latency, which should also be improved.
Will follow up in #2381.
The charts are now available here: https://xpra.org/stats/nodelay-cork/.
This option can now be enabled on a per-socket basis: ticket:2424#comment:1.
See also #2975.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2130