On Mon, 2010-06-28 at 14:28 +0200, Erik Auerswald wrote: > Hello John, > > On Mon, Jun 28, 2010 at 07:47:47AM -0400, John A. Sullivan III wrote: > > On Mon, 2010-06-28 at 09:30 +0200, Erik Auerswald wrote: > > > On Mon, Jun 28, 2010 at 06:55:56AM +0000, cougarmaster wrote: > > > > Was reading about how to increase SSH performance and I came across > > > > this. > > > > [...] > > > > Also in there is a link to tuning network performance too just wanted > > > > to see if it would be of any help. > > > > > > This is the standard network performance tuning found everywhere. This is > > > interesting for a saturated server, but will not solve any fundamental > > > speed issues. > > > > > I have been wondering if it will help with resilience. We are having > > problems where, if the Internet connection starts dropping packets, > > recovery of the X2Go client is much slower than recovery of other > > applications such as web browsing. > > Web browsing will start new TCP connections (not for every fetched URL > as back in the day, but still), while SSH uses just one connection. Thus > you might have the combination of TCP slow start with several competing > TCP connections (web browsing, file sharing, ...). As long as data > is available to send (e.g. a screen update of X2Go), TCP will try to > increase the send window, which might result in packet loss and slow > the stream down again. > > You could try with a different congestion control algorithm for the ssh > session or with quality of service settings (end-to-end or at least at the > choke point, which might be the client side internet router). > > > We have tried playing with > > ClientAliveInterval and ClientAliveCountMax but that has not helped. > > This would only help to keep the session alive, but not to speed up > recovery. <snip> Thanks, Erik. Yes, I assume we are falling into the TCP backoff algorithm for resending the packets and I don't know of a way to reinitiate the connection. I was hoping ClientAlive would do that but it apparently doesn't. We could time it out faster using the ssh timeout parameter but that won't help recovery - just drop the session faster - John
_______________________________________________ X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
