"'DRC' via TurboVNC User Discussion/Support" <[email protected]> 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 > > DRC > > On 2/9/23 2:26 AM, [email protected] wrote: >> "'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/871qmg6t7t.fsf%40tanaka.verona.se.
