[X2Go-User] Latency Issues

[Mike Gabriel]

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 at das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.x2go.org/pipermail/x2go-user/attachments/20131123/cfaf7a91/attachment.pgp>