I still can't reproduce the problem, but I also don't have the ability to exactly reproduce your compute environment. I configured my best Linux box as a server, then connected Remmina to it from another Linux box with a simulated WAN traffic shaper configuration (100 ms/10 Mbit.) I then connected to the server over an unmodified gigabit link from a Windows box running the TightVNC Viewer, in order to simulate your Android device running Remote Ripple. When playing a video such as Big Buck Bunny, quite a few frames were dropped over the simulated WAN link, but the performance over the LAN link appeared much smoother (even when both were connected simultaneously.) The presence or absence of the "remote" viewer didn't seem to affect the "local" viewer's frame rate, nor did the connection order.
However, I think what you're experiencing is likely due to server CPU exhaustion. For starters, using 16-bit color is rarely useful with modern TightVNC-compatible servers and viewers. Normally, the color depth of the remote desktop would only affect the non-JPEG subrectangles, but when JPEG subencoding is enabled (which it is by default when connecting from Remmina or Remote Ripple), the non-JPEG subrectangles will never contain more than 256 colors. Thus 16-bit does nothing to save bandwidth in your case. It only creates a needless drain on the CPUs, because the remote desktop pixels have to be converted to 24-bit before they can be compressed as JPEG, then they likewise have to be converted back to 16-bit on the client for display. Yuck. Just use 24-bit end-to-end and dial the JPEG quality down to "Medium" in Remmina to save bandwidth/increase performance on the remote link. All X servers, including any variant of Xvnc such as the TurboVNC Server, are single-threaded. That means that all connected VNC viewers have to be serviced in series within the same dispatch loop that processes X11 requests from X applications. As mentioned above, a 16-bit color depth puts an unnecessary strain on both the server and client CPUs. If the server is spending all of its time processing framebuffer updates for the connected viewers, then it won't have time to process very many X operations for each iteration of the dispatch loop, and this can reduce the effective update rate. The other thing is that both of those viewers are slow. Even on a fast connection, Remmina performs about 3.5x slower than the TurboVNC Viewer, and anything in the TightVNC family will be slower still (particularly on a mobile device.) That's relevant because neither of those viewers supports the RFB flow control extensions. Those extensions allow the server to push out updates to the viewer on-demand, as quickly as the viewer and the connection can handle them. Without the RFB flow control extensions, the server reverts to "classic" RFB behavior, whereby it waits to receive a framebuffer update request from the viewer before it sends out a framebuffer update, and "typical" TightVNC-compatible viewers (those other than TigerVNC or TurboVNC) will not send out a new framebuffer update request to the server until they finish receiving, decoding, and drawing the current framebuffer update. It would take too long to explain why exactly that causes the phenomenon you're seeing, but the short answer is that the TurboVNC Server is tuned for high-speed viewers. If you're familiar with the multitasking concept of a "time slice", the TurboVNC Server's default time slice (which, in VNC servers, is called the "deferred update timer") is 1 ms. That provides the maximum responsiveness, and thus the maximum throughput, when using a high-speed viewer such as ours, but with multiple low-speed viewers that don't support the RFB flow control extensions, you can get into situations in which X applications don't have enough time to draw before the next framebuffer update has to be sent out. If this happens, then the rate at which X applications can draw can become locked to the rate of the slowest viewer. I think you might be able to work around the issue by increasing the deferred update timer value in the TurboVNC Server. That essentially causes the server to coalesce updates from X applications over a certain period of time before it responds to framebuffer update requests from the viewers. I would edit /opt/TurboVNC/bin/vncserver, find the line where $deferUpdate is set, and try changing it from 1 to 20 (you have to restart the server for this to take effect.) That will effectively limit the maximum update rate for any viewer to 50 per second, but the viewers you're using aren't going to be able to decode at a faster rate than that anyhow. If that doesn't do anything, try dialing it up to 40, but there is a trade-off. Higher deferred update timer values will give a larger amount of time to X applications, but they will steal this time from the connected VNC viewers, so if you increase the value too much, your LAN connection may slow down, irrespective of whether the remote viewer is connected. If changing the deferred update timer doesn't fix it, then my only other advice would be to use the TurboVNC or TigerVNC Viewer instead of Remmina and switch the color depth to 24-bit. On 2/28/17 9:41 PM, Rafael Sierra wrote: > > On 2017年03月01日 03:04, DRC wrote: >> Are you using the TurboVNC Viewer on all clients? If not, please >> provide more details about which viewers you are using and which >> application you are running in the TurboVNC session. If I can reproduce >> the issue, then perhaps I can give you some advice regarding how to work >> around it. The TurboVNC Server, because it's based on X.org, is >> single-threaded, so it's processing updates for each viewer serially in >> the X server's dispatch loop. That means that the VNC server has to use >> some rather complicated logic to determine when to send out updates, and >> it's certainly possible that you've discovered a hole in that logic. > I forgot to add details about the server configuration; here they are: > > Server: Ubuntu Desktop 16.04.1; TurboVNC 2.1; > > Desktop Manager: LXDE > > xstartup (xstartup.turbovnc): > #!/bin/sh > /usr/bin/lxsession -s LXDE & > > Configuration file /etc/sysconfig/tvncservers: > VNCSERVERS="1:rafael" > VNCSERVERARGS[1]="-geometry 1280x720 -nohttpd -depth 16" > > Applications/actions tested: > - File manager window being dragged. > - Video playback. > * All applications show the same behavior. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
