I’m running into a weird problem with tigerVNC server on Rocky 9. Entering text in an Xterm or mateTerminal is stuttery. The last character I enter will not show up for like half a minute. Likewise, text output from commands (like ls) is slow to the point that I have to wait several seconds for the output to finish. Even just hitting Enter requires about ten seconds before I get a command prompt back. System behavior at the console or from an ssh session is normal. No delays echoing input or displaying output. File transfers appear to be normal so I’m pretty sure this isn’t a network issue. The hardware is dual Xeon CPUs and 128GB RAM so definitely not resource constrained.
The kicker on this is I also have two Rocky 9 VMs running on different hardware (old SunFire 1U) and neither VM exhibits this behavior. Entering text and command output is what I would expect after years of using VNC for connecting to remote systems. Checking the connections options from the F8 menu shows the same settings (default). I’m accessing each system from the same CentOS 7 desktop tigerVNC client.
About the only difference I can find is the user environments (printenv and set) are significantly different between the VMs and the real hardware. The system exhibiting the problem was a clean install from the Rocky 9.2 ISO but I think I converted the VMs from CentOS 9 to Rocky 9 using the conversion process so the systems are not identical. All three systems are running a Mate desktop and I used the same systemd setup on the real hardware as the VM for the VNC server.
Any thoughts on what would cause the weird text behavior or where to check would be appreciated.
Update 14 October 2023: I created a new VM with a Rocky 9.2 install (same as the real hardware that has the stutter problem) and it behaves the same as the other VMs. Hit a key and the character appears with no delay. Seems to be some sort of hardware component to the problem.
Update 16 October 2023: Installed iperf on both the system experiencing the weird VNC behavior and the desktop that I usually use (that VNC client stutters on). Got the following:
[root@abuse ~]# iperf -c 192.168.0.2 -p 5001
Client connecting to 192.168.0.2, TCP port 5001
TCP window size: 85.0 KByte (default)
[ 1] local 192.168.0.4 port 52966 connected with 192.168.0.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-10.02 sec 1.10 GBytes 941 Mbits/sec
and going the other direction:
[root@bend ~]# iperf -c 192.168.0.4 -p 5001
Client connecting to 192.168.0.4, TCP port 5001
TCP window size: 510 KByte (default)
[ 3] local 192.168.0.2 port 48582 connected with 192.168.0.4 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.10 GBytes 943 Mbits/sec
Looks like network throughput isn’t the problem.
Yet another update 16 October 2023: One other way to see if its VNC or something else is to allow ssh forwarding on my favorite desktop and then set the DISPLAY environment variable of an ssh session on the hardware having trouble with display rendering of a VNC sessions. Fired up an xterm and a mateTerminal which both popped up on my desktop as expected… and entering text was absolutely normal. No rendering lag.
Final update (I promise) 17 October 2023: I realized that, if I could pop an xterm or a mateTerminal back to my usual desktop with ssh x forwarding then I could do the same with a VNC client that connects to localhost on the real hardware box. Set that up in vncserver-config-defaults file, restarted the server and then started the vnc client from the command line of the ssh forwarded session. Works like a champ with no lag when entering text. If anything, seems to be snappier than using the VNC client to connect from the remote box. This would seem to further rule out that there was some sort of network glitch causing the problem.
Conclusion: There is something wonky with the combination of VNCclient from CentOS 7 connecting to VNCserver from Rocky 9 with the server on real hardware (not a VM). Using ssh X forwarding and starting the VNC client from the forwarded session is a reasonable work-around. This also means that I’m connecting to the R9 VNCserver with an R9 VNCclient. YMMV