Bug 5720 - laggy session with well compressed updates and slow client
Summary: laggy session with well compressed updates and slow client
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: pre-1.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: LowPrio
Assignee: Pierre Ossman
Depends on:
Reported: 2015-11-18 16:34 CET by Pierre Ossman
Modified: 2021-10-05 12:40 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2015-11-18 16:34:41 CET
On bug 5618 we fixed a bug where we would overwrite the data on the shared framebuffer before the X server had time to finish reading it. Unfortunately that bug papered over a different bug.

With the new code you can get a scenario where you have a noticeable latency between your actions and the screen updating. Frame rate is however high so there is some queue building up.

You can reproduce it as such:

 - Use a simple window manager without any fancy compositing
 - Have a solid colour background
 - Drag a window around

Using the profile chooser is a quick way to test this.

If the client is slow then you will get the noticeable lag between the mouse cursor and the window position.

The theory is that in this case the update will basically only be CopyRect and fills, which is extremely bandwidth efficient. So the server can cram a whole lot of updates in to the calculated congestion window. The client however requires quite a bit of time to render this update, so the TCP queue starts growing.

We need to look over the congestion algorithm and somehow detect and compensate for when the client has sufficient bandwidth, but is failing to keep up for other reasons.
Comment 2 Pierre Ossman cendio 2015-11-18 16:36:05 CET
A workaround is restoring DeferUpdate to something better (see bug 5719). Setting it to the previous value of 10 ms seems to get rid of most of the issue for me.

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