... 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.