RPi4 routing performance numbers

Installing and Using OpenWrt Network and Wireless Configuration
21 
Jan 30 09:11:48 pirouter kernel: [    1.153175] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.20
Jan 30 09:11:48 pirouter kernel: [    1.153214] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Jan 30 09:11:48 pirouter kernel: [    1.153241] usb 1-1: Product: USB2.0 Hub
Jan 30 09:11:48 pirouter kernel: [    1.154810] hub 1-1:1.0: USB hub found
Jan 30 09:11:48 pirouter kernel: [    1.155073] hub 1-1:1.0: 4 ports detected
Jan 30 09:11:48 pirouter kernel: [    1.301834] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Jan 30 09:11:48 pirouter kernel: [    1.332646] usb 2-2: New USB device found, idVendor=2357, idProduct=0601, bcdDevice=30.00
Jan 30 09:11:48 pirouter kernel: [    1.332685] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=6
Jan 30 09:11:48 pirouter kernel: [    1.332712] usb 2-2: Product: USB 10/100/1000 LAN
Jan 30 09:11:48 pirouter kernel: [    1.332736] usb 2-2: Manufacturer: TP-LINK
Jan 30 09:11:48 pirouter kernel: [    1.332758] usb 2-2: SerialNumber: 000001000000
Jan 30 09:11:48 pirouter kernel: [    1.482276] usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Jan 30 09:11:48 pirouter kernel: [    1.571274] NET: Registered protocol family 10
Jan 30 09:11:48 pirouter kernel: [    1.572916] r8152 2-2:1.0 eth1: v1.09.9
Jan 30 09:11:48 pirouter kernel: [    1.573192] Segment Routing with IPv6

So looks like r8152 ethernet chip.

3 Likes
22

Smells like G.fast?

23

Never heard of that. No, it's KPN. But it's been a while since I last tested. Maybe I should rerun that test sometime.

24

G.fast a successor in the ADSL->VDSL line of link technologies that allows fast rates on short copper wires and is sometimes used for FTTB, so fiber to the basement and then in-house distribution via the old telephony copper wires. G.fast uses time domain multiplexing and has a mode in which it dynamically (within limits) distributes "bandwidth" between up- and downstream, effectively behaving like is is not using full duplex. But probably not what your ISP uses, as I tried to indicate a wild guess.

25

Ah, no, I am using a fibre connection. The fibre itself terminates inside my apartment.

26

I'm using a USB 3.0 to Gigabit Ethernet adapter as well, the RTL8153 Realtek USB 3.0 to Gigabit Ethernet.. they get hot so need adequate cooling or might restart. Haven't tried the ASIX. Thanks for sharing.

27

Cool stuff... dlakelan, you may prevent me from buying a CI329 in the future, and maybe get me to retire my CI327! :wink:

Was wondering how the performance is with the assumably heavier load of Cake for the SQM?

Looking forward for the nftables tagging getting nailed down to combine with a rpi4... :+1:

28

I don't think Cake will be dramatically more cpu hungry than HFSC. They both do a fair amount of computation. Even if cake doubles the cycles, you're still looking at like 20% of one core and 10% of another :astonished:

I actually think Raspbian has cake, so I could do the test at some point. probably not before monday.

1 Like
29

Ah, possibly so, think the later Raspbian kernel might be ahead of when Cake was added.

30

Also interesting in cake test results

31

I know you probably don't but if you get some spare time and your bored you could also think of slipping some OpenWrt testing in at some stage :wink:

32

I doubt it would be dramatically different.

from raspbian: Linux version 4.19.75-v7l+

doing a search doesn't show sch_cake.so module, so I can't test cake without doing OpenWrt install or updating the kernel.

I've got to start using this Pi for a project where I'm trying to get NetLogo running in a desktop environment so I can't really do much more testing, though I am now very tempted to buy more Pi4s, one for routing and one for fileserving.

1 Like
33

NP, and thxs for all the info shared.

34

Well, it seemed like the best available solution for all those poor guys who are in the sad state where they just bought gigabit fiber to their home and now they want to know why their Archer C7 isn't routing it properly :sweat_smile: :nerd_face: :abacus: so I figured if I'm going to recommend it I should test it, and putting up hard tested numbers is more useful than theory. Glad to be helpful, and if anyone chooses to get a Pi4 and can test it under OpenWrt and post some OpenWrt numbers here I'm sure the community would be happy to see those!

EDIT: I also think it provides an interesting perspective on the future of OpenWrt... I personally think that OpenWrt should become more focused on helping people get flexibility and freedom in network design, and less focused on running on low-end hardware with WiFi embedded. If for $90 you can get 4GB of RAM, 32G SD card, Pi4 board, case and power supply, the relevance of fitting into 16MB of flash on an embedded board is far less, but the power of networking freedom for the masses, with security, VPN, DNS over TLS, SQM, keepalived, squid proxy, BATMAN, etc is still just as relevant...

5 Likes
35

Maybe a Raspberry Pi model will be the future favorite OpenWrt device. But for now what I see is that a Raspberry Pi is not built for and also not optimized for usage as 24/7 low power and easy to use wireless network router or access point.

USB wireless adapters are not the favorite wireless master mode devices from what I can read to date.

Also there are a lot of other options just for wired routing and computing stuff. I see OpenWrt as a wireless router project, often running on cheap mainstream consumer hardware.

1 Like
36

Yeah the Pi isn't ideal, but the point is that it's possible to get gigabytes of RAM and storage and gigahertz of multicore for under $100. in the future that will be even more so. right now OpenWrt is optimized for something like 16/128 Megabytes of RAM/Storage, using BusyBox and lots of multicall binaries and things. That's not a great assumption going forward.

As it is right now, the top 10 downloads are ALL x86 or RPi
https://downloads.openwrt.org/stats/

37

You are refering to https://downloads.openwrt.org/stats/#downloads

The full list shows a different picture (don't ask me why though)
https://downloads.openwrt.org/stats/awstats.downloads.openwrt.org.allextra1.html

Related:

38

that is particularly odd since this shows yet another picture more similar to the first...

https://downloads.openwrt.org/stats/awstats.downloads.openwrt.org.downloads.html

In any case I think there's some evidence that x86 and rpi targets are popular, even if it's mixed. Certainly as costs decline we expect the more powerful things to be more popular as new purchases.

39

Ok, all, some final numbers I guess... In the end I decided to run the RPi as my main router, in hopes of eventually retiring the j1900 based device I've been using and saving some power consumption and extending the life of my UPS. Also, having my router and my nfs fileserver be one-and-the-same box was causing problems (whenever I needed to do something to the internet... I'd also lose LAN connectivity as my machines would freeze waiting for NFS to come online).

So, my situation is a bit complicated, as I run a squid proxy on the router and use that to do some access controls and identify streams at layer 7 for QoS... meaning the Pi doesn't just have to route a gigabit, but actually proxy a gigabit through squid...

and it does. It's hard to measure a gigabit really because the speed test servers themselves tend not to be able to handle that much speed... but I was able to get upwards of 850Mbps from internet speed tests going through the squid proxy.

Idle percentages were about 1% on one core, and 25% on the 3 other cores. I could probably improve that by telling squid to use only 3 cores... it might not quite handle these speeds under 3 worker conditions... but I honestly don't care. If I get 700+ Mbps and low latency with high QoS that's great, so the fact I can get upwards of 850Mbps with squid is fabulous.

dslreports doesn't work for me anymore because of some certificate issue (the speedtest is ok, but bufferbloat borks)... However I ran mtr to google.com during that speed test and it was rock solid with less than 1 ms of bufferbloat on pings throughout the whole test (note, my pings go through a higher priority queue, I use QoS specifically so I get this kind of result for my high priority stuff, so without DSCP marks etc you wouldn't necessarily get the same result).

nevertheless, the Pi is capable of routing and proxying a gigabit with HFSC shaping all while still having CPU headroom to spare.

EDIT: another advantage to the Pi over an x86 box that does multi-functions is that I can have a micro-SD card ready-to-go with a known working config, and if I screw things up I can easily swap cards and be back to a known good config within minutes... for the x86 setup I have, I'd have to get a screwdriver and open the case :rofl:

7 Likes
40

@dlakelan, you didn’t use OpenWRT, do you?

I still can’t figure out a way to get the usb Ethernet dongle working.