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
On Wednesday, November 3, 2021 at 4:55:16 AM UTC-5 joakimv wrote:
"'DRC' via TurboVNC User Discussion/Support"
<[email protected]> 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.
>
> 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/
>>>
>>>
>>
--
Joakim Verona
[email protected]
