package: bandwidthd
Bandwidthd works with OpenWrt-23.03.0,
I don't think a version compatible with OpenWrt-23.05.0 has been released yet.
WR1043ND v3 running fine on 23.05.0 for a while now.
The only issue is that PPPoE is still very slow even with software flow offloading enabled, as described in https://github.com/openwrt/openwrt/issues/13847 and https://github.com/openwrt/openwrt/issues/10224
I can barely get 200 Mbps download with a PPPoE connection to my ISP, whereas with DHCP it gets closer to 1Gbps without problem.
That is not a bug, but expected behaviour - PPPoE is CPU heavy. Software flow-offloading has only limited means to rectify that, this is simply way beyond what the single mips 74Kc core can do at 720 MHz.
2 Likes
@slh Thanks for your input, but I guess I'll have to disagree. PPPoE was working at much higher speeds in OpenWrt 21.x and before. The slowness occurs in 22.x and 23.x as far as I understand from https://github.com/openwrt/openwrt/issues/10224
There are actual fixes available there, so I suggest trying some of them or at least reading about what the problem is.
PPPoE is currently capped around 150 Mbps without software flow offload and 200 Mbps with it enabled, so not much of an improvement. The slowness is caused by the switch to firewall4 since 22.x - it is worth reading more about that, for example recently here: https://github.com/openwrt/openwrt/issues/10224#issuecomment-1789662199
2 Likes
OpenWrt will stay on firewall4 nftables, at least for 23.05.
QCA9558 is a design from 2013 - now 10 years old. The TP-Link TL-WR1043ND v3 is an 8/64 device.
This device will be end of life some time in the coming years but for now it still can run the newest stable release 23.05. You will need to find people invest a lot of time on performance optimization for this 720 MHz MIPS32 single core with b/g/n WiFi device with limited resources.
For me even the popular successor QCA9558 models with ath10k 11ac WiFi with 16 MB flash and 128 MB memory like TP-Link Archer C7 v2 are now either a low end router choice or powerful access points. I would look for a newer device in 2023 than spending hours trying to optimize firewall4 PPPoE performance for old 8/64 QCA9558 b/g/n devices.
3 Likes
Thanks for the heads up, I'm aware of the things you've mentioned. However, it's not only this particular WR1043ND router that is slow with PPPoE since the switch to firewall4 nftables in 2022, but basically all devices that don't have hardware flow offload support (such as some Mediatek SOC).
What about all those that only have software flow offloading support? Should we consider them old as well (even if bought new, 1-2 years ago), should we be ready to throw them away and buy some Mediatek that has hardware optimizations that provide a bit more performant PPPoE?
I would really like to know why has PPPoE performance dropped like a rock since OpenWrt 22.x? Could we really not do anything about it? https://github.com/openwrt/openwrt/issues/10224 says otherwise. There are some devs working on this issue, AFAICT, perhaps I'm mistaken?
And I still fuckin' love it. She still has tricks up her sleeve.
But as we've learned recently, disabling frame check-summing (in software) can achieve gigabit wire-speed.
Oh look! People!
Try one of the builds at the above PR for the 1043, and see whether that helps for PPPoE. You might be pleasantly surprised 
Since starting with OpenWrt it was more important to me to enjoy SQM than hardware flow offload. Devices with enough power for line speed SQM, software flow processing and OpenWrt support for a good price are usually available.
I donât think that hardware flow offload is a must have for everyone. Others may have a strong need in their use case for hw flow offload without SQM.
You are free to work on optimizing the firewall4 nftables PPPoE performance for TL-WR1043ND as much as you can. A lot of users will appreciate it if you could improve the performance for these targets.
I just think the limited development resources are better spent on newer hardware targets with a more promising future.
I think itâs a good idea to always have frame checksum processing. Donât spend resources on processing frames with invalid checksums.
23.05.2 has been released.
4 Likes