I think I'd poke around: - compression => latency: perhaps you want to try without compression (the -C switch on the ssh command-line) ?
- cipher => latency+cpu load: Otherwise, you could try to change the cipher used by ssh (but that is a bit tricky, clients and server have to be compiled with the same ciphers, and you probably want to check the config files as well.) Sometimes I succeeded connecting with "-c NONE" to specify the null cipher. Blowfish is usually a fast cipher for software based encryption, and it is better than "NONE" obviously. Or you could experiment with rsh tunneling, but this is getting seriously outdated. - udp over tcp, tcp over tcp => packet losses: this is getting seriously tricky. If the tunnel experiences tcp retries, it will transport spurious udp or tcp packets to the client and server. Or the tcp packet size of the data inside the tunnel is too large for the tcp packet size of the tunnel and you get fragmentation... For me there is a lot of magic here. But I know that pinging or udp-pinging inside the tunnel with various payloads help diagnose the problem. -- epoch1970 ------------------------------------------------------------------------ epoch1970's Profile: http://forums.slimdevices.com/member.php?userid=16711 View this thread: http://forums.slimdevices.com/showthread.php?t=64593 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/discuss
