<HTML><HEAD>
<META content="text/html; charset=utf-8" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19154"></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Hi John,</DIV>
<DIV> </DIV>
<DIV>thanks for your answer.</DIV>
<DIV> </DIV>
<DIV>Could you please provide some sources for</DIV>
<DIV> </DIV>
<DIV>"and any tweaks one can make to the IP stack or the SSH protocol. "</DIV>
<DIV> </DIV>
<DIV>?</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV> </DIV>
<DIV>Stefan<BR><BR>>>> "John A. Sullivan III" <jsullivan@opensourcedevel.com> 12.11.2011 03:28 >>><BR><BR>On Fri, 2011-11-11 at 14:21 +0100, Stefan.Klingner@brodos.de wrote:<BR>> Hi,<BR>>  <BR>> we are trying to use X2Go to provide a devolpment environment for our<BR>> employees in India. The problem is that the connection to India is<BR>> really bad (latency ~200ms) and so working with X2Go is currently not<BR>> possible.<BR>>  <BR>> Is there a way to improve the performance on the X2Go client/server<BR>> configuration? Does anybody have experience with such a szenario?<BR>>  <BR>> Please help.<BR><snip><BR>The first thought is the usual WAN improvements such as WAN accelerators<BR>and any tweaks one can make to the IP stack or the SSH protocol.  Also<BR>try to use hard wired connections on the client side rather than<BR>wireless.  We have seen a tangible difference on the same Internet<BR>connection between the two.<BR><BR>However, I am beginning to wonder if something important has changed.<BR>Our experience with the older 3.0.1 series clients was that they were<BR>adequate with 200ms latency and packet loss up to 4-5%.  We are still<BR>running the older server but have started using the newer client.  I'm<BR>currently using the version in the heuler repository.  I've noticed<BR>different and troubling behavior which I am guessing is a result of the<BR>switch to libssh.<BR><BR>My Internet connection has been a little less stable than usual lately<BR>and I've started to notice really problematic behavior.  I do not know<BR>why but, if we start experiencing moderate packet loss or latency, the<BR>behavior is almost as if nagle is enabled.  We'll type a series of key<BR>strokes and they will all type but the last one.  Two seconds later, the<BR>last key appears - makes editing documents a dangerous nightmare as the<BR>cursor is usually one character off from where one thinks it is.  We<BR>also see major screen painting delays - clicking on some action and we<BR>know the server has responded instantly but the old screen just sits<BR>there for two or three seconds and then suddenly changes.<BR><BR>We've not had the time to track it down and I'm guessing it will be a<BR>bear to find but something has definitely changed in the newer client<BR>code and not for the better - John<BR><BR><BR></DIV></BODY></HTML>