10

I've just finished setting up a VPN'ed NAS with my newly acquired un-overclocked Raspberry Pi Model-B and I've run into something I can't find an answer for elsewhere.

The internet bandwidth, as determined using

wget --output-document=/dev/null http://speedtest.wdc01.softlayer.com/downloads/test500.zip

is much slower than what I'd expect to get. I'm getting around 1.34 MBps on my Pi through ethernet when I'm getting close to 7MBps when the ethernet is plugged directly into my laptop.

The problem is with OpenVPN, but I can't figure what exactly it is. Here's how I know this.

I compared the download rates on the Pi with the VPN turned off and on -- it was 5.03 MBPS vs 1.34 MBPS.

Then I tried it on my laptop (wired) -- it was 6.9 MBPS (perfect) vs 6.7 MBPS (near perfect).

So the fault doesn't lie entirely with my VPN service (PrivateInternetAccess) which gives a 3% reduction in bandwidth on my laptop -- but has to do with the way OpenVPN runs on the Pi which gives a 74% reduction in bandwidth.

Any ideas on why OpenVPN on Raspbian is being so terrible?

UPDATE: Most of that reduction from 6.9MBPS on the laptop without VPN to 5.03 MBPS on the Pi without VPN seems to be from the SD card write speed, which I've determined to be around 4.9MBPS. It's that huge reduction from 5.03 MPBS on the Pi without VPN to 1.3MBPS with VPN that needs to be explained.

UPDATE 2: Some more clues from suggestions from the comments: 1) OpenVPN utilizes 70% of the CPU when it is running and wget is in the background 2) On the Pi, I get 1.34 MBPS from a US VPN server and around 500-600 KBPS from ALL European VPN servers, BUT on my laptop,I get 6.7MBPS from the US VPN server and a very similar 6.6MBPS from some European servers like the one in Netherlands. What I'm saying is that distance to the server seems to disproportionately affect the Pi rather than my laptop.

dbrane
  • 211
  • 1
  • 2
  • 5
  • It could be a combination of poor write speed and VPN overhead. I never liked to use VPN's because they were just slow over internet and SSH tunnelling was always the fastest. Are there any options for enabling compression on OpenVPN? Possibly play with that, maybe on the fly encryption causes issues. It is a good question. I am also interested in the answers in relation to the Pi – Piotr Kula Jan 24 '13 at 08:45
  • Look at the CPU load with top while testing, that should say something about the encryption overhead. – Frepa Jan 24 '13 at 09:27
  • @Frepa Excellent suggestion! When the VPN is enabled, OpenVPN utilizes 70% of the CPU. Do you think this is what's causing the huge difference in transfer rates? – dbrane Jan 24 '13 at 18:20
  • @dbrane, it sounds as if CPU is the limiting factor. Where does the remaining 30% CPU-time go? Idle? From update 2 it sounds as if network latency (i.e. not only throughput) is important for the performance. Maybe there is some hand-shaking going on in VPN. – Frepa Jan 24 '13 at 19:00
  • @Frepa Most of the remaining CPU-time is used by wget itself, which is the command I use to test the transfer rate. Everything else in the list uses less than 1% each.

    I'm using a CA certificate with the VPN, if that information helps. Maybe I should try overclocking and see if that helps?

     – dbrane Jan 24 '13 at 20:27
  • @dbrane, OK, so the CPU is constantly busy. Then it is definitely the bottleneck. The dynamic overclocking has a good reputation and should be safe, you just have to find which settings are stable on your particular Pi. – Frepa Jan 24 '13 at 22:00
  • @Frepa Well, overclocking didn't help. Confirmed that it went into Turbo mode at 1GHz when wget was running, but there was no improvement in the speed. – dbrane Jan 24 '13 at 23:02
  • Morever, while actually torrenting, CPU usage for OpenVPN doesn't go above 15% and yet the torrent rate never exceeds 900KBPS. – dbrane Jan 24 '13 at 23:14
  • What's strange there is mostly that you get with torrents so close to your maximum 1.3 MB/s limit without maxing out the CPU. – Blaisorblade Mar 02 '13 at 02:58

1 Answers1

4

On low-powered devices, at least when using SSH, I've had good experience using the RC4 cipher to improve performance since it's computationally faster, so uses less CPU for the bandwidth/allows higher bandwidths for the same CPU usage. This guide explains how to change the cipher to any one supported by OpenSSL - like RC4:

http://openvpn.net/index.php/open-source/documentation/howto.html#security

Note that RC4 is not the most secure algorithm available, but SSL still uses it in secure ways (which exist, as described here: http://en.wikipedia.org/wiki/RC4). Update: this is less true now than in the past. Trust in the security of RC4 is reducing even more, as techniques for breaking it advance, and 2013 has given us various progress in breaking RC4 and speculation about the NSA having managed. Quoting Wikipedia:

As of 2013, there is speculation that some state cryptologic agencies may possess the capability to break RC4 even when used in the TLS protocol.[3] Microsoft recommends disabling RC4 where possible.[4][5]

So, can I still recommend RC4? Not really in general. Of course you need to tradeoff security and performance, and maybe you don't actually need lots of security — any cryptography, even RC4, will still slow down dragnet surveillance efforts like the ones from NSA. But I would be really careful with actually sensitive data, and change algorithm to something else if possible at all (I've started to benchmark my Raspberry to look for fast alternatives).

Update 2: on my (overclocked) Raspberry, AES is not so slow, if you have enough CPU available. The table below shows that RC4 can crypt ~57MB/s, while AES-128-CBC can crypt ~21.4MB/s. Of course, this does not explain why you get such bad performance — but maybe you're using by default a slower cypher, or maybe there's some other inefficiency which could be improved.

$ openssl speed rc4 aes
[...]
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
rc4              45281.36k    54782.67k    57196.80k    57391.48k    57570.77k
aes-128 cbc      17904.15k    20469.38k    21133.95k    21449.62k    21403.72k

Overclocking settings from /boot/config.txt:

arm_freq=950

# for more options see http://elinux.org/RPi_config.txt
core_freq=250
sdram_freq=450
over_voltage=6
Blaisorblade
  • 256
  • 1
  • 9
  • 1
    Any type of encryption (ssh/vpn) will cause additional CPU usage, which is probably your bottleneck. – earthmeLon May 20 '13 at 23:27
  • 1
    My point was that RC4 uses less CPU than other ciphers, so it might be good in this situation. But I'm not sure whether you agree or disagree with my answer. – Blaisorblade May 24 '13 at 13:34
  • @earthmeLon: I updated my answer to state my point explicitly, because it was anyway unclear. Not sure that addresses your comment. – Blaisorblade May 24 '13 at 13:36
  • Absolutely. I was very appreciative to know that RC4 is a good solution with minimal overhead, because of SSH2's implementation of it. Thanks for the information :D. Too bad you couldn't see I gave you an upvote, eh? – earthmeLon May 25 '13 at 03:31
  • Indeed — I only noticed later that your comment coincided in timing with the upvote. Thanks! – Blaisorblade May 25 '13 at 04:52
  • I've set up my VPN using PPTP. Not exactly secure, but it's really easy on the processor. I'm not really going for security with my setup. I'm using it as a VPN gateway to connect to my VPN provider with devices that don't support VPN, such as my Wii. – Kibbee May 25 '13 at 12:17