Friday, August 19, 2011

SSH cipher speed

When setting up backups over SSH (e.g. rsnapshot with rsync over SSH), it's important to know that the default SSH cipher isn't necessarily the fastest one. In this case, the CPU-based encryption is the performance bottleneck, and making it faster means getting faster backups.
A test (copying a 440 MB file between a fast Xeon CPU (fast=no bottleneck there) and an Atom based NAS) shows that the arcfour family of ciphers are clearly the fastest in this setup:
cipherreal timeuser timebandwidth
arcfour0m9.639s0m7.423s45.7 MB/s
arcfour1280m9.751s0m7.483s45.1 MB/s
arcfour2560m9.856s0m7.764s44.7 MB/s
blowfish-cbc0m13.093s0m10.909s33.6 MB/s
aes128-cbc0m22.565s0m20.129s19.5 MB/s
aes128-ctr0m25.400s0m22.951s17.3 MB/s
aes192-ctr0m28.047s0m25.771s15.7 MB/s
3des-cbc0m51.067s0m48.018s8.6 MB/s

The default configuration of openssh uses aes128-ctr, so changing the cipher to arcfour gets me a 2.5-fold increase in bandwidth here ! Use the "Ciphers" keyword in .ssh/config or the "-c" command line parameter to change the order of preference of the available ciphers. YMMV.

As a reference (cfr. deinoscloud's comment), I ran "nc -l -p 3333" on the Atom side, and ran "cat file | nc atom 3333" on the Xeon:
cipherreal timeuser timebandwidth
cleartext0m4.135s0m0.311s106.5 MB/s
. This shows that in the cleartext case, the CPU (user) time is not the bottleneck, and we're very close to using the full 1Gbps bandwidth.








Monday, August 15, 2011

Dell's R210-II as vSphere home lab server

My VI3 and vSphere4 home lab consisted of whitebox PCs. For VI3 I used MSI based nonames, for vSphere4 I used Shuttle SX58j3. For the new vSphere5 generation, I wanted some real server hardware. Because of shallow depth requirements, the choice of rackmount servers was limited. I picked the Dell Poweredge R210II instead of the sx58j3 because
- on the vSphere HCL (the sx58j3's won't boot vSphere5 RC !)
- Sandy Bridge low TDP CPUs available (I got the E3-1270)
- onboard dual BCM5716 nics support iSCSI offload (aka "dependent HW iSCSI")
- IPMI built-in (not tested yet)
- dense: 1U (the sx58j3 is about 4 units, but can fit 2 in 19")
- one free PCIe slot (The sx58j3 has 2 slots, but needs a VGA card)
- not incredibly expensive (up to 16GB RAM)
Downsides:
- only one free PCIe slot (max GbE nics needs expensive quadport card)
- incredibly expensive (with 32GB RAM it's 3x the price of a 16GB config)
- can't buy without at least one disk. I'll be running from USB sticks.

Saturday, August 6, 2011

HTTPS SSL stops working because of old libraries

At a customer, a Linux workstation suddenly refused to open HTTPS sites. Verified recent package versions of both browser (konqueror) and libraries (kde, openssl), everything looked good, but it didn't work. This blogpost serves as documentation for the fact that checking new software isn't enough, because in this case removing old openssl compatibility libraries solved the problem. The kio_http helper is not linked with openssl directly, and for some reason it must have tried to open one of the old openssl versions that were also installed. After erasing all versions between 0.9.5a and 0.9.6b, keeping the current 0.9.8e, konqueror had no problems opening https sites anymore.