Tell me more ×
Raspberry Pi Stack Exchange is a question and answer site for users and developers of hardware and software for Raspberry Pi. It's 100% free, no registration required.
up vote 5 down vote favorite

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.

share|improve this question
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 – ppumkin Jan 24 at 8:45
Look at the CPU load with top while testing, that should say something about the encryption overhead. – Frepa Jan 24 at 9: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 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 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 at 20:27
show 4 more comments

1 Answer

up vote 1 down vote

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).

share|improve this answer
Any type of encryption (ssh/vpn) will cause additional CPU usage, which is probably your bottleneck. – earthmeLon May 20 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 yesterday
@earthmeLon: I updated my answer to state my point explicitly, because it was anyway unclear. Not sure that addresses your comment. – Blaisorblade yesterday
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 12 hours ago
Indeed — I only noticed later that your comment coincided in timing with the upvote. Thanks! – Blaisorblade 11 hours ago
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.