Limitations to using a Raspberry Pi as your Super Fast Broadband router

I’ve seen a few recommendations about using a Raspberry Pi as an Internet Router. Last night I did some experimentation and found that unfortunately it’s not quite up to the task on my super-fast link (50Mbit/s, “soon” to be upgraded to 100Mbit/s).

I’m going to experiment with some other options and see if I can find a configuration that works – if I do, I’ll post an update. At this stage, though, I’m pretty doubtful it’ll work for me.

Testing Environment

  • Raspberry Pi revision 2 board.
  • Standard current Raspian release (2013-02-09-wheezy). I kept the device in standard configuration (no adjustments to ethernet ‘Turbo’ mode, or to memory allocation).
  • Edimax EU-4207 USB ethernet adapter.
  • Iperf – the default version on all boxes.
  • Two very capable boxes – able of sustaining full gig-ethernet iperf performance between them with a crossover. Both ran Ubuntu – one Quantal, and one Raring.
  • Direct CAT 5E ethernet links from the capable boxes into the two ethernets on the Raspberry Pi. All links (both directions) showed 100Mbit/s full duplex connections on both sets of interfaces.
  • Static IP addresses all round, with the two interfaces on the Raspberry Pi acting as a gateway.
  • IP forwarding on the Raspberry Pi enabled, but with no firewalls or NAT configured, for maximum performance.

Machine A to Raspberry Pi

This test comprised running iperf from machine A to the Raspberry Pi using the Pi’s built-in ethernet port. Iperf performance seemed fine – topping out at about 94Mbit/s. Unfortunately there was pretty much 0% cpu time available, with almost everything being in system time. The CPU was mostly keeping up, but there was very little wiggle room. I was pretty impressed with that, overall.

Machine B to Raspberry Pi

This used the EU-4207 ethernet adapter. Performance was marginally up from the native port. Iperf performance seemed fine again, topping out at about 96Mbit/s. Again, cpu was pretty much 100% by system time, servicing the packets coming in.

Machine A to Machine B

This is the real test, and unfortunately the Pi fails pretty badly here for my usage. Performance varied from about 35Mbit/s to peaks at around 55Mbit/s, and was quite variable.

The vmstat output is more telling – what’s interesting here is that although the test ran for 10 seconds, ‘vmstat 1’ only shows 4 lines of output (there should be 10). The cpu is so badly lagged that vmstat goes on the back burner.

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 259932 18004 132188 0 0 35 21 1068 99 3 8 89 1
7 0 0 258716 18004 132188 0 0 0 0 5348 29 0 33 67 0 -- performance test starts here
7 0 0 256892 18004 132188 0 0 0 0 24359 17 0 100 0 0
7 0 0 255548 18004 132188 0 0 0 0 17461 8 0 100 0 0
3 0 0 256412 18004 132188 0 0 0 0 88444 77 0 100 0 0 -- note that vmstat outputs are missing
0 0 0 259420 18004 132188 0 0 0 0 1346 46 0 4 96 0
0 0 0 259420 18004 132188 0 0 0 0 348 60 0 0 100 0
0 0 0 259420 18004 132188 0 0 0 0 348 65 0 0 100 0
1 0 0 259420 18004 132188 0 0 0 0 348 61 0 1 99 0
0 0 0 259420 18004 132188 0 0 0 0 355 70 0 3 97 0
0 0 0 259420 18004 132188 0 0 0 0 350 65 0 0 100 0
0 0 0 259420 18004 132188 0 0 0 0 346 65 0 0 100 0

Many links are indeed slower than this speed, and the Pi is probably fine for those purposes (just don’t any run other apps on the Pi, otherwise you’ll end up with random slowdowns). The problem is that as soon as you start adding the overhead of NAT, PPOE, and stateful packet filtering into the mix, performance is definitely only going to get worse. And that’ll lead to packet loss and reduced browsing speed.

Remember also that this is a unidirectional iperf test. So if you’re uploading and downloading at the same time (hint, you are!) things will get even worse.

I’d say that if your link is up to 20Mbit/s and you have simple home-type network with limited NAT requirements you’re probably fine with the Pi as a router. Above that, I’d start to be wary.

Optimising things

There’s always some room for optimising Linux’s networking, and I’ll have a look around to see if there’s some set of magic sysctls that’ll help here. I’ll post an update if I find anything. If you have any suggestions you’d like me to test, tweet me at @oskarpearson