no, it's all managed by the cpu. you don't even see it at 1.2ghz because it's not reported to the OS. only benchmarks showed that the turbo was working.
1 Like
Force performance governor instead of ondemand for both cpu's 0/1?
PPPoE is a quite significant additional load on the CPU, which is already marginal for plain routing at 1 GBit/s (as you noticed, linux can achieve that, the xBSD drivers can't).
1 Like
Just tried that (on all four cores, not just policy0), no change.
That's what I was afraid of. Maybe I could do something funky with the ISP-provided router and have it handle the PPPoE and then I just use the apu4d4 for the routing/DHCP/etc.
Please read this thread, at least this comment :
- PPPoE: if your internet provider is using PPPoE protocol, and you have purchased a Fiber WAN over Gigabit, the APU2 cannot reach that 1 Gigabit in real life. More realistic is somewhere between 200 and 650 Mbit (the latter is the absolute maximum under real life condtiona). Reason: the PPPoE is single-threaded under *BSD, and the 1 Ghz cores in this SoC cannot handle that amount of traffic. PF and NAT can (and fornsure will!) decrease this value even further. There are no surprises, clock speed wins over core count in single threaded code. So this should set your expectations when your ISP is using PPPoE over that gigabit fiber connection!
1 Like
You really want to terminate the PPPoE Session on your OpenWrt router, mostly for these reasons:
- having the WAN IP and the NAT on your OpenWrt router, avoiding double NAT
- ease of use (not having to configure port-forwardings etc. twice)
- security
I was thinking that maybe the ISP router would have a bridging mode I can put it into. I've had DSL ISPs in the past which provide that option, and that avoids the double-NAT/double-forwarding issue.
... and you can get a used, gigabit capable device, on ebay for $50-100, if you're willing to spend the time and $.
Read the thread I posted earlier.
1 Like
Already tried 22.03rc3 or even 19.07.x just for the quick speed test different linux version can have huge impact on performance?
I guess you are running x86 64bit, may even try 32bit?
1 Like
I'd seen a few threads like that (although not that specific one), which is what led me to try OpenWRT instead of pfSense. OpenWRT is absolutely performing better than pfSense (about 3x as fast) but obviously it can only do so much.
I think I'm okay with this situation for now, and in the future I'll just look into a faster device to upgrade to (or maybe CenturyLink will wise up and switch to DHCP).
Those all sound like good things to try, I'll experiment with that later. Thanks!
Put a managed switch between the isp router and the apu for vlan tagging, disable other ethX interfaces except WAN & LAN?
keep an eye on this topic, this device for the price has some very interesting features... the SOC is a quad core ARM at 2.2Ghz 
2 Likes
It looks like I can set the ISP router to become a transparent bridge (according to this Reddit thread). That's probably what I'll mess with next. But in the meantime I need to get back to work. 
Okay, this is interesting... after all of the fiddling in this thread I ended up rebooting my router again and suddenly I'm getting a full gigabit down! Still only 650-700 up (which is where I really want to get gigabit speeds), but dang.
Now if only I knew which specific thing I did changed it.
1 Like
Last things that come to mind, try offloading more processes on NIC, disable spectre/meltdown mitigations, from linux 5.4 init_on_alloc=1 is default maybe try init_on_alloc=0 ?
ethtool -k ethX
#grub boot kernel arguments?
mitigations=off
1 Like
Offloading?
While that device is a promising one, I would not recommend ipq807x for 1000/1000 MBit/s at this point, the switch driver[0] depends on NSS offloading to get beyond ~600 MBit/s, but NSS offloading is quite far away from being merged into OpenWrt proper.
x86_64 is one of the easiest ways to go for this use case, just the APU2/3/4/6 with its dated AMD Jaguar cores can't really provide the necessary steam to keep everything busy (especially with PPPoE or other advanced features like VPN or SQM). The RPi4 could be another option, although more recent x86_64 will have more margins.
--
[0] while performance gains should be possible with a 'proper' DSA based switch driver (even without NSS, although that will still be necessary beyond >>1 GBit/s), this would require quite extensive development akin to the ipq40xx/ DSA migration - it's possible, but way in the future at best, and there aren't even any takers for that task, yet.
1 Like
Not on the WAN interface, no. The PPPoE header is part of the ethernet payload as seem from the PPPoE endpoints (like your router) so they need to live within the MTU, reducing the WAN MTU to 1492 will result in a usable MTU towards the internet of 1492-8 = 1484 so makes the problem worse.
It should not. What OpenWrt defaults to is using MSS clamping, which for TCP connection should fix the issue (UDP connections are expected to use path MTU discovery).
Do you use > 1 Gbps ethernet? Because the TCP/IPv4 goodput over ethernet is limited to around 950-940 Mbps, 980 is clearly outside the possible....
In all likelihood they started to use PPPoE to allow time and/or volume based accounting for DSL (similar to how analog modem access often was charged by time), and then just stuck to it because their internal process was/is already designed for PPPoE. So even if they would jettison all DSL lines tomorrow it is well possible that they would stick to PPPoE.