Hi all,
thanks Steve for your contribution. Very good.With connection speed X2Go (i.e. NX) is very good, even on very low speed lines.
On Sa 23 Nov 2013 20:11:25 CET, Steve Bergman wrote:
I am using X2Go Client and we are facing Latency issues whendevelopers 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.
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.xfb
_______________________________________________
X2Go-User mailing list
X2Go-User@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/x2go-user