Hi all, Was reading about how to increase SSH performance and I came across this. Would this help in speeding up X2GO in anyway are just a waste of time? Also in there is a link to tuning network performance too just wanted to see if it would be of any help.
Tks in advance Eric
Hi,
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. Would this help in speeding up X2GO in anyway are just a waste of time?
I don't think SSH is the bottleneck for normal X2Go use. Usually the network link between server and client has little bandwidth (think DSL or cable modem) and can be easily saturated by standard openssh without any tuning. Thus the client side would not profit significantly from the changes in HPN-SSH.
On the server side you start several SSH processes, thus getting the multi thread functionality without a patch. There is no need to adjust the internal SSH buffers either, because of the low bandwidth links to the clients.
What might help on a heavy loaded server or on slow clients (e.g. VIA or ARM based thin clients without hardware AES encryption) would be the use of the blowfish cipher. [Disclaimer: I did not check which cipher is selected by X2Go.]
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.
Br, Erik
Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/ auerswald@fg-networking.de Tel: +49-631-4149988-0 Fax: +49-631-4149988-9
Gesellschaft für Fundamental Generic Networking mbH Geschäftsführung: Volker Bauer, Jörg Mayer Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630
Hi,
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. Would this help in speeding up X2GO in anyway are just a waste of time?
I don't think SSH is the bottleneck for normal X2Go use. Usually the network link between server and client has little bandwidth (think DSL or cable modem) and can be easily saturated by standard openssh without any tuning. Thus the client side would not profit significantly from the changes in HPN-SSH.
On the server side you start several SSH processes, thus getting the multi thread functionality without a patch. There is no need to adjust the internal SSH buffers either, because of the low bandwidth links to the clients.
What might help on a heavy loaded server or on slow clients (e.g. VIA or ARM based thin clients without hardware AES encryption) would be the use of the blowfish cipher. [Disclaimer: I did not check which cipher is selected by X2Go.]
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.
Br, Erik I have been wondering if it will help with resilience. We are having
On Mon, 2010-06-28 at 09:30 +0200, Erik Auerswald wrote: 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. We have tried playing with ClientAliveInterval and ClientAliveCountMax but that has not helped. Has anyone else been able to make X2Go session more robust across poor quality connections? Thanks - John
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.
Thanks, Erik
Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/ auerswald@fg-networking.de Tel: +49-631-4149988-0 Fax: +49-631-4149988-9
Gesellschaft für Fundamental Generic Networking mbH Geschäftsführung: Volker Bauer, Jörg Mayer Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630
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
Hi John,
On Mo 28 Jun 2010 13:47:47 CEST "John A. Sullivan III" wrote:
This is the standard network performance tuning found everywhere. This is interesting for a saturated server, but will not solve any fundamental speed issues.
Br, Erik
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. We have tried playing with ClientAliveInterval and ClientAliveCountMax but that has not helped. Has anyone else been able to make X2Go session more robust across poor quality connections? Thanks - John
If TCP/IP packets get dropped on the way between source and target
host you should primarily get to the bottom of that packet dropping.
Example: Some internet providers have started oversecuring their
network routers (e.g. 1und1 in Germany). The ISPs block ICMP requests
totally. This blockage then als includes ICMP Type 3 Code 4 packets
(destination unreachable, don't fragment). If these kinds of packets
are blocked by some routers on the way the Path MTU Discovery
technique will fail which results in packet loss... (and endless
timeouts...).
PMTU discovery -> RFC 1191...
Being a bit off-topic on the list...
Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
eMail-LeseSchreibStunde: wochentags 8h-10h mail: m.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Mon, 2010-06-28 at 20:46 +0200, Mike Gabriel wrote:
Hi John,
On Mo 28 Jun 2010 13:47:47 CEST "John A. Sullivan III" wrote:
This is the standard network performance tuning found everywhere. This is interesting for a saturated server, but will not solve any fundamental speed issues.
Br, Erik
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. We have tried playing with ClientAliveInterval and ClientAliveCountMax but that has not helped. Has anyone else been able to make X2Go session more robust across poor quality connections? Thanks - John
If TCP/IP packets get dropped on the way between source and target
host you should primarily get to the bottom of that packet dropping.Example: Some internet providers have started oversecuring their
network routers (e.g. 1und1 in Germany). The ISPs block ICMP requests
totally. This blockage then als includes ICMP Type 3 Code 4 packets
(destination unreachable, don't fragment). If these kinds of packets
are blocked by some routers on the way the Path MTU Discovery
technique will fail which results in packet loss... (and endless
timeouts...).PMTU discovery -> RFC 1191...
Being a bit off-topic on the list...
Indeed but sometimes it is beyond our control and we can only complain to the ISP and back it up with our monitoring data. Thus, we need to build as resilient an infrastructure as we can. Thanks - John
-
cougarmaster -
Erik Auerswald -
John A. Sullivan III -
Mike Gabriel