The Things You Should Check First.

So nothing seems to help. Tried a faster endpoint on the Amazon side; tried a faster endpoint on this side. Nothing made a difference. So if a faster CPU doesn’t help on either side, that only leaves the network, right?

The truth is that 25Mbit/s of VPN traffic translates to a minimum of 50Mbit/s of ethernet traffic on the Pi. This is hairpin setup, meaning that the traffic comes in on one interface, gets (un-)VPNed, and then goes back out on that same interface. Plus we have to add whatever overhead IPSec introduces (which may be none, or may be significant; I’ve not looked).

I think the Raspberry Pi’s USB-connected ethernet port just can’t handle anything more than this.

A quick test from a local host direct to the local VPN endpoint Pi reveals the truth:

Re-running the usual test also shows us that the CPU is not even remotely loaded down by IPSec. The CPU never drops below about 92% idle. And this is on the original Pi 2, which I’ve swapped back in at this point. After all, why burn a Pi 3 when it makes no difference to performance?

Result & Conclusions

So essentially we’ve hit the limits of a Pi’s networking ability on a single interface. I’m vaguely curious to know if it would get better results with multiple interfaces (USB 2.0 can handle nearly half a gigabit in theory), but I’m not holding my breath. It’s just not worth the effort; if I need extra bandwidth to Amazon for some reason, I can always fire the endpoint up in VMware again.

And really, 25Mbit/s is pretty damn good for a $40 computer. Price a professional VPN endpoint some time; anything half decent is a bit more expensive than that…

So I’m right back where I started from.

It also tells me that replacing my git server is a useless exercise; I already get more than 6MB/s from it, so it’s not likely that I’ll do much better — especially when you consider that the repositories are mounted to the server via NFS to begin with.

And so my weekend is entirely wasted.

Oh well.



Leave a comment: