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:
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
On 10/22/21 2:42 PM, [email protected] wrote:
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/
--
You received this message because you are subscribed to the Google Groups "TurboVNC
User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/0e9f9e32-4b1c-436f-6267-a7fd9f56ed78%40virtualgl.org.
