Slow PPPoE Performance vs DHCP-Client

I am using an R7800, and I am very new to OpenWrt. I was previously using it in a double router situation, whilst I learned to set up the PPPoE on OpenWrt itself. When in DHCP-Client mode, I was able to fully saturate the 1000/110mbps link.

Upon switching to PPPoE I am stuck around the 280mbps mark. Experimenting with Software and Hardware offloading (within the Firewall section) allowed this to rise to 320 or so. Upload remains stable at approx 110 throughout all this. I am now using the WAN port whereas before I was using a regular network port, however the WAN port was happy with 500mbps on my previous internet connection so shouldn't be to blame.

I believe I likely overlooked some settings, I ain't looking for any fancy network sniffing or firewall rules, but would appreciate having that top end speed back. Any suggestions?

Further Points: A speedtest creates a load of approx 0.6 to 0.4, so the router isn't being overally stressed to deliver this.

Hardware flow-offloading isn't implemented for ipq806x/ qca8337, so that setting doesn't do anything, at best.

PPP(oE) is quite significantly taxing the router's CPU (especially if it can't be offloaded to hardware), it's not at all unexpected to see a significant reduction in throughput if the router has to do PPPoE - it's also roughly within expectations of this hardware (1000/110 is way above its weight limit, which is somewhere between 500-650 MBit/s)

I found my solution, the R7800 is plenty capable of gigabit, however by default OpenWrt doesn't support its NSS cores that on stock firmware are what allow it to reach such high speeds.

The above post, and awesome community member has compiled versions optimised for our hardware with the required patches, and right now I am back to 900 - 1100 on speedtests :slight_smile:

1 Like

Let's be realistic for a moment, apart from NSS offloading (which isn't part of official OpenWrt).

The r7800 only has 1000BASE-T ethernet ports (same for its two CPU ports), the maximum theoretical throughput for 1000BASE would be ~930 MBit/s (and PPPoE with its smaller MTU reduces the maximum achievable throughput even further), any figures beyond that are simply bogus, as they aren't even theoretically achievable (without jumping to 2.5GBASE-T ports or higher, which this hardware physically isn't equipped for). If you are seeing figures exceeding that, your measurement tool is broken.

The theoretical upper limit for gigabit ethernet/PPPoE/IPv4/TCP goodput (with MTU 1500 sized packets) is:

gross rate * ((MTU - PPPoE header - IPv4 header - TCP header) / (MTU + ethernet header))
1000 * ((1500 - 8 - 20 - 20) / (1500 + 38)) = 944.08 Mbps

assuming no IP and TCP options are used. On-line speedtests tend to use an additional (lean) http header for a tiny bit less goodput.

However this theretical limit is not necessarily achievable in speedtests...

1 Like

Understood, from a conventional sense I was seeing the “previous” behaviour which was spiking to 1.1gbp and settling at 880-940mbps, I'm aware a gigabit port can only carry “less”

Most speedtests "fudge" it at least during the display at run-time, so if you only measure e.g. the "sending rate" of the application (so packets being dumped into the OS networking stack) you can see bursts of unsustainable rates like your 1.1 Gbps, best to ignore these...

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.