"'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] -- 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/87ee7x4l8g.fsf%40tanaka.verona.se.
