problems with screen updates in turbovnc "3.0 evolving"

[joa...@verona.se]

Hello,

I'm experiencing som problems with screen updates in turbovnc "3.0
evolving", rpm turbovnc-2.2.80-20211011. I'm using fedora 35 on the
client, 34 on the server. The repaint problem happens mostly in emacs,
because thats what i use the most.

If I open a shell buffer and do a "ls" the output seems to happen at
the server, but the repaint isnt propagated to the client. If I wiggle
the mouse cursor a bit, the screen update do happen.

I've tried some different configurations, like changing the update
frequency, encoding quality and so on, and the problem doesnt happen.

Any hints?
Regards
/Joakim/


--
Joakim Verona
joa...@verona.se

[DRC]

I observe a similar issue sometimes when resizing the remote desktop,
and if it's the same issue, then it is due to the updated RFB flow
control algorithms
(https://github.com/TurboVNC/turbovnc/commit/a0f5670ecc42538f95f56ee81a885c6ba32916f1).

If the flow control statistics are reset due to an idle connection, then
a situation can occur in which the connection is marked as congested but
no ETA is provided for when it will become uncongested.  That results in
undelivered framebuffer updates.

Referring to:
https://github.com/TigerVNC/tigervnc/commit/a99d14d1939cb2338b6268d9aebe3850df66daed#r57748408

I have asked the TigerVNC developers for clarification but have not
heard back.  My next step is to instrument the TigerVNC Server code and
attempt to figure out why their server doesn't seem to suffer from the
same symptoms, even though it has the same algorithmic flaw (or at least
what I perceive to be a flaw, but maybe I'm missing something.)

DRC

[DRC]

Stand by.  I see a couple of reasons why the algorithm may be failing in
the TurboVNC Server.  I'll dig into it next week.

DRC

[DRC]

This should be fixed in the latest dev/3.0 evolving pre-release build of
the TurboVNC Server, but please let me know if it isn't.  In addition to
fixing a couple of errors I made in the process of porting the
overhauled congestion control algorithms from TigerVNC 1.10.x into
TurboVNC 3.0, I also revised the algorithms so that they treat an ETA of
<= 0 as uncongested.  TigerVNC can get away with not doing that because
it has a "frame timer" that, by default, wakes up every 1/60 sec and
attempts to send any framebuffer updates that were previously deferred
(due to congestion or otherwise.)  In the case of TurboVNC, however,
reporting congestion without setting the congestion timer results in
updates not being delivered in a timely manner.  (Basically the
undelivered updates languished until mouse input was received, which
triggered a new framebuffer update in order to deliver the updated
cursor position.)

Please also let me know if the performance on high-latency/low-bandwidth
networks doesn't meet your expectations.  I test this stuff by using two
Linux machines, both of which are using the built-in Linux traffic
control mechanism to emulate a 200 ms/100 Mbit WAN connection.  With the
TurboVNC Viewer maximized on a 1920x1200 (2-megapixel) screen and using
the "Tight + Low-Quality JPEG" preset, I execute

  vglrun /opt/VirtualGL/bin/glxspheres64 -fs -i

in the TurboVNC session and

  tcbench -lb -mx 100 -s 200

on the client to both drive continuous mouse input into GLXspheres and
measure the end-to-end frame rate.  With this setup, I measure about 35
frames/sec with TurboVNC 2.2.6, about 50 frames/sec with the tip of the
dev branch, and about 30 frames/sec with TigerVNC 1.10.x.  The reduced
frame rate with TigerVNC may be due to the aforementioned frame timer. 
I also observed random black rectangles in the middle of the spheres
when using TigerVNC, due to their partial framebuffer update delivery
"feature." (Frankly, I do not like that feature, because it effectively
causes 3D applications with VirtualGL to appear as if they are not
double-buffered.)  I would love to have an open dialogue with the
TigerVNC developers regarding these issues, particularly if that
dialogue included best practices for benchmarking the congestion control
algorithms, but given their unwillingness to answer a simple question
regarding the algorithms, I am not hopeful.  I think it best if we just
test things ourselves and thus build confidence in TurboVNC's
implementation.

DRC

On 10/22/21 3:42 PM, DRC wrote:

[joa...@verona.se]

"'DRC' via TurboVNC User Discussion/Support"

<turbovn...@googlegroups.com> writes:

> This should be fixed in the latest dev/3.0 evolving pre-release build
> of the TurboVNC Server, but please let me know if it isn't.  In
> addition to fixing a couple of errors I made in the process of porting
> the overhauled congestion control algorithms from TigerVNC 1.10.x into
> TurboVNC 3.0, I also revised the algorithms so that they treat an ETA
> of <= 0 as uncongested.  TigerVNC can get away with not doing that
> because it has a "frame timer" that, by default, wakes up every 1/60
> sec and attempts to send any framebuffer updates that were previously
> deferred (due to congestion or otherwise.)  In the case of TurboVNC,
> however, reporting congestion without setting the congestion timer
> results in updates not being delivered in a timely manner.  (Basically
> the undelivered updates languished until mouse input was received,
> which triggered a new framebuffer update in order to deliver the
> updated cursor position.)

I'm testing the turbovnc rpm, 29 oct, hash
4023c59bc24a0f75e09c5453ca76ac38.

It seems the screen repaint problem is indeed gone, I don't however have
an objective measure, I just observe that the remote emacs instance I use
all the time doesnt seem to exhibit these issues anymore.

Regarding performance, this server doesnt have a gpu, so performance is
as can be expected whitout gpu. I will try another server with gpu next.

--
Joakim Verona
joa...@verona.se

[DRC]

Please re-test with one of the latest pre-release builds (either 3.0.x or 3.1 evolving) of the TurboVNC Server.  I had to modify the congestion control algorithms yet again to fix https://github.com/turbovnc/turbovnc/issues/359.  In my testing, the update problem you observed is still gone, #359 is fixed, and the congestion control algorithms perform noticeably better on high-latency connections.  However, I need independent confirmation.

DRC

[joa...@verona.se]

"'DRC' via TurboVNC User Discussion/Support"
<turbovn...@googlegroups.com> writes:

> Please re-test with one of the latest pre-release builds (either 3.0.x or 3.1 evolving) of the TurboVNC Server. I had to
> modify the congestion control algorithms yet again to fix https://github.com/turbovnc/turbovnc/issues/359. In my
> testing, the update problem you observed is still gone, #359 is fixed, and the congestion control algorithms perform
> noticeably better on high-latency connections. However, I need independent confirmation.

I havent had this problem for a while, I usually update the turbovnc rpm
fairly often. I can try with the very latest bits and pieces and see if
its still gone.

Regards
/Joakim

--
Joakim Verona
joa...@verona.se

[DRC]

Yes, I need you to test the very latest bits.  The code that might have
caused the issue to regress was pushed just yesterday.

DRC

[joa...@verona.se]

"'DRC' via TurboVNC User Discussion/Support"
<turbovn...@googlegroups.com> writes:

> Yes, I need you to test the very latest bits.  The code that might
> have caused the issue to regress was pushed just yesterday.

I have tried this for a while now, seems to be working, and upgraded
again today, still works.

Thanks!

/Joakim

--
Joakim Verona
joa...@verona.se

[DRC]

Awesome!  Thank you for testing.