Hi all,
thanks Steve for your contribution. Very good.
On Sa 23 Nov 2013 20:11:25 CET, Steve Bergman wrote:
I am using X2Go Client and we are facing Latency issues when developers use it from different country and they use graphics
functionalities.
I'm new to x2go, but have a good bit of experience administering
FreeNX for business desktops served over WANs. In Session
Preferences -> Connection, experiment with the slider settings. In
particular, MODEM, ISDN, and ADSL. I find that ADSL works best over
my 3 - 10 mbit/s WANs. But if yours are slower, MODEM or ISDN might
work better. On a fast WAN, MODEM and ISDN make the updates clunkier
by limiting the update rate, and possibly other things. It's hard to
predict all interactions. But you might even try 'WAN' for a
relatively high bandwidth, high latency connection. The higher
slider levels are good for latency. But note that 'LAN' provides no
compression at all. It's likely to perform quite badly.Also, on that same page, you can reduce the image quality, which
defaults to 9 (highest quality) but supports a range from 0 to 9.
I'm not familiar enough with the "Method" options to make a
recommendation. I suspect the default is probably pretty good.To give you an idea what you should be able to expect, NX technology
over a 3mbit full duplex link with a ~150 - 200ms latency between
sites provides very usable business desktops (Mail, browsing,
Libreoffice) for my ~100 desktop users. About 50 of those are over
the WAN, and the rest are on the local LAN. I know of nothing that
even remotely compares to FreeNX/x2go for performance over a WAN.Please experiment and report back. I'm interested in your results.
And please tell us more about your problematic workload. The ping
times to the clients, the nominal bandwidth, etc.
With connection speed X2Go (i.e. NX) is very good, even on very low
speed lines.
However, with latency issues things become different. As latency is
defined as the amount of time the data needs to traverse from client
to server / server to client, we should make sure that on high latency
connections, data is as processed as fast as possible.
So my basic idea about this is, that what you actually need to reduce
is the time that is required for processing/caching/compressing images
etc. On high latency lines it helps to have good bandwidth available,
because you (in theory) can use the high bandwidth to compensate for
high latency. E.g. by choosing a faster but less effective algorithm
for compression (or not compressing images at all).
My personal problem here: I cannot test this theory, because I do not
have high latency connections here to test this with. I know that you
can simulate high latency / low bandwidth in a lab setup, but I
neither have time nor resources for doing that.
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...