OpenWrt 23.05.0 - First stable release

23.05.0 has considerably lower system load and also lower processor usage on all my systems (EAP615-wall v1, APU3D4). Cool

3 Likes

Thank you - this is indeed what I am seeing, and the 'fix': setting the ageing time for the bridge seems to work.

Any idea why? In adblock-lean, faster processing of blocklists was also reported with 23.05.

1 Like

No idea. Could it be related to changes in the kernel between 5.10 and 5.15? The extra thing I'm running on all devices is chrony (just for fun). Electricity usage remains pretty unchanged. Here's the processor chart:

1 Like

Netgear WNDAP360 is listed as 23.05 supported, but there are two issues that go back to 22.03 which block or hinder installation.
Specifically:

  • Serial Baud rate switches from 9600 to 115200 during kernel image boot.
  • Lan port is unable to communicate when autonegotiated 1Gbps, but still shows traffic statistics. This is due to an incorrect PLL setting in DTS

I do not believe this device should be shown as supported with publically available images in its current state.

  1. are there any issues or PRs which describe the issues?
  2. if you understand the problem, you're half way to fixing it if 1) above don't exist.
1 Like

As a relatively new forum member and not wishing to tread on toes, I did broach the subject in the Developer Forum thread on the WNDAP360 where these issues were discussed, and I initially thought they were included in a PR. Further research shows that this is not the case, and I will most likely be raising issues and PRs of my own. I simply wanted to point out that images for this device haven't been working since 22.03 and will catch out the unwary. I haven't managed to track down when it got broken from the original support effort. I have summarised the issues at the end of that thread.

2 Likes

Didn't see those. Keeping the noise here to a minimum: fixing bugs is (generally) not stepping on toes. Fire away...

1 Like

23.05.1 was tagged, and then shortly after 23.05.2 was tagged on git.

23.05.1 is presumably being skipped then.

3 Likes

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 :wink:

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