That is definitely not expected behavior. I just did a quick & dirty
test using three of my machines: a Linux server, a Linux client, and a
Mac client. I started the TurboVNC 2.1.1 server with default options on
the Linux server. I connected with the TurboVNC 2.1.1 viewer from the
Mac client with a screen size of 1920x1200, maximized the viewer window
to resize the remote desktop, then ran 'vglrun -sp
/opt/VirtualGL/bin/glxspheres64' in the TurboVNC Server session. I
verified that the refresh rate was good (> 40 updates/second.) I then
ran the following on the Linux client to simulate a 10 Mbps/100 ms WAN
connection:
# inbound
sudo modprobe ifb
sudo ip link set dev ifb0 up
sudo tc qdisc add dev enp3s0 ingress
sudo tc filter add dev enp3s0 parent ffff: protocol ip u32 match u32 0
0 flowid 1:1 action mirred egress redirect dev ifb0
sudo tc qdisc add dev ifb0 root handle 1: htb default 1
sudo tc class add dev ifb0 parent 1: classid 1:1 htb rate 10mbit ceil
10mbit
sudo tc qdisc add dev ifb0 parent 1:1 handle 10: netem delay 100ms
# outbound
sudo tc qdisc add dev enp3s0 root handle 1: htb default 1
sudo tc class add dev enp3s0 parent 1: classid 1:1 htb rate 10mbit ceil
10mbit
sudo tc qdisc add dev enp3s0 parent 1:1 handle 10: netem delay 100ms
Connecting from the Linux client (also 1920x1200), I got about 3
updates/sec, but the Mac client was still receiving > 40 updates/sec. I
also tried the same thing with GLXspheres in interactive mode ('vglrun
/opt/VirtualGL/bin/glxspheres64 -i'), and I also tried connecting both
viewers without continuous updates enabled ('-nocu'), to simulate a VNC
viewer without the RFB flow control extensions.
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.
DRC
On 2/28/17 2:07 AM, Rafael Sierra wrote:
> Hi.
>
> I've installed TurboVNC 2.1 under Ubuntu-16.04 and everything seems to
> work fine except for this issue.
>
> 1. When I connect to the server from the same LAN segment, refresh rate
> is good enough.
>
> 2. When I connect from a remote location and the link happens to be a
> slow link, the refresh rate drops and is barely usable. If at the same
> time I launch a second connection from the same LAN, the refresh rate on
> this second connection is also slow. It will remain slow even if I
> disconnect the remote client. The LAN connection remains slow even after
> reconnecting.
>
> Questions:
>
> 1. Is this behavior expected?
>
> 2 Is there anything I can do to ensure I always get the best refresh rate?
>
> Thanks,
>
> Rafael
------------------------------------------------------------------------------
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
