Bug 4734 - Xvnc can stall because of full send buffer
Summary: Xvnc can stall because of full send buffer
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.14.0
Assignee: Pierre Ossman
Keywords: prosaic
Depends on: 7785
Blocks: performance
  Show dependency treegraph
Reported: 2013-07-01 11:36 CEST by Pierre Ossman
Modified: 2021-12-15 12:24 CET (History)
1 user (show)

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2013-07-01 11:36:31 CEST
A couple of releases back we changed Xvnc to have an outgoing send buffer to avoid stalling when a client wasn't receiving data fast enough. Unfortunately the buffer size is fixed so it can still happen for large updates (e.g. a full screen refresh).

We should look at increasing the buffer size, probably dynamically as needed.
Comment 1 Pierre Ossman cendio 2021-05-13 09:35:32 CEST
This should be fixed upstream as of this PR:

Comment 2 William Sjöblom cendio 2021-12-13 14:40:26 CET
I have now gone through all the commits in PR mentioned in comment 1.

The changes all in all look fine but explicitly testing all changes made would be pretty time-consuming, we will therefore rely on the regression tests done for bug 7785 (which cover all relevant general cases needed for this bug). Also, note that the beta and subsequent stable release has been out for a while without any issues related to this change reported.

Thus, what remains to be tested is the general scope of this bug.
Comment 3 William Sjöblom cendio 2021-12-15 11:10:13 CET
I have performed some quantitative performance measurements with
`x11perf', comparing the performance of Xvnc over a bandwidth throttled

This was done using server build #2375 and server release 4.13.0 running
on Fedora Server 35, both connected to using client build #2287. Since
we want to quantify X server performance for large updates (as mentioned
in comment 0) the benchmarks were run with a high entropy full-screen
RGB noise (changing 60 times per second) in the background with a
session resolution of 3000x2000 to ensure the following:
• That every update would require the whole screen to be sent
• That every update would be hard for the JPEG algorithm to compress
  effectively, thus making it large in terms of bytes sent

The benchmarks were performed using the following command: `x11perf
-repeat 100 -time 1 -scroll500' with the following aggregate results:
        │ 10 mbit/s      1000 mbit/s  
 #2375  │ 11200 iters/s  8180 iters/s 
 4.13.0 │ 6680 iters/s   6820 iters/s 

The specific benchmark `scroll 500' was chosen rather arbitrarily since
we are looking for complete stalls of the X server and not how
performant it is in a specific area.

I have not performed any proper statistical analysis of the overall
benchmark results, but one thing that stands out is the sheer amount of
outliers in the 10 mbit/s 4.13.0 measurements. If we remove these
outliers (making up approx. 1/10 of the measurements) we get a similar
aggregate result as for the 10 mbit/s #2375 series. My conclusion is
that these outliers (which are not at all present in #2375) are the
result of the stalls mentioned in comment 0.

Worth noting is that these measurements are relatively prone to
confirmation bias since the newer of these have had a lot of its third
party components updated (such as its X server and libjpeg) and not just
TigerVNC. Nonetheless, what we are looking for in practice is a large
enough performance increase to motivate a somewhat generally formulated
release note about increased performance.
Comment 5 William Sjöblom cendio 2021-12-15 12:24:00 CET
After some discussion, we've decided to leave out the release note for this one since this bug is of the more theoretical kind even though we see a decent increase in performance under certain conditions. Marking as closed!

Note You need to log in before you can comment on or make changes to this bug.