Le vendredi 30 ao�t 2002 09:46 -0400, Adam C Powell IV �crivait: > Rewinding to the original post, I have a fundamental question: [...] > Is my basic understanding sound, or does ssh send the session info, X > stuff, etc. in the clear? Or does this not add significant computation > time, e.g. on the order of what the kernel uses to get the packets out > through the NIC? Has anyone seen/done relevant benchmarks which would > test the magnitude of this effect?
SSH encrypts the whole connection. And it's very CPU intensive. Here are a few results I obtained when I did some tests : Configuration : file transfer from an AlphaServer ES40 with 4 EV67 to an SGI Origin 2000 with 4 MIPS CPU through a HiPPI network. The pseudo-benchmarks were done on a busy machine, so they're not really "scientific". Transfer of a 1 GB file in chunks of 512 KB : dd if=/dev/zero bs=524288 count=2048 | R_COMMAND origin2000 "cat > /dev/null" The results are the following : With R_COMMAND == rsh : ~ 50-60 MB/s With R_COMMAND == ssh -c 3des : ~ 1-2 MB/s !!! With R_COMMAND == ssh -c blowfish : ~ 4-6 MB/s !!! Clearly, SSH is a real hog on performance. While doing the tests, I also noticed that a full CPU was busy on the slowest machine (SGI) while doing the transfer. The other one was 35% busy... The bottleneck is now the CPU and not the network. Even with a faster algorithm (blowfish instead of 3des), ssh is 10 times slower than rsh and uses a lot of CPU time. Maybe the processors on the SGI are old and not up to the task (I think they are 250 MHz CPUs). Maybe you can still saturate a 100Mb Ethernet with a Pentium IV machine with SSH, but the CPU price seems high. Those "benchmarks" were done with file transfers, but it seems that with a parallel program with a lot of communications, it is a bad idea to use SSH to do the communication. -- Alexandre Vitrac CS-SI OpenPGP key ID : C03A7DFE
