"'DRC' via TurboVNC User Discussion/Support" <[email protected]> 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 > > 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] -- 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/877cwrz1lp.fsf%40tanaka.verona.se.
