Smart Queue Management

Hey Guys,

I recently moved from PFsense to OpenWrt. I own apu1d4 that is running OpenWrt from a USB ( I was not able to flash the OpenWrt onto the onboard SSD).

The main reason I moved was to use the SQM QoS.
Before installing any package I ran a speed test

After Applying SQM my speed test is

I would like to know are these Speed Values normal considering the SQM function.
Below are the setting for SQM

CAKE is known to be a bit CPU heavy, especially on a fast line like yours. Try using fq-codel and see if the performance drop is as severe. It might also be good to compare the 1m load average before and after the speed test.

I see your running SQM on your IPv6 WAN connection, you might also need to setup a seperate SQM instance for your IPv4 WAN connection if applicable.

Since IPv6 is designed to not require NAT, I'm not sure if the ingress/egress options actually do anything. Unless you're doing something like NPTv6. I'd wait to hear from someone with more experience with SQM regarding that.

Can you also show the settings on the last tab (Link Layer Adaptation)? To get the most out of SQM, you'll need to set a proper overhead value.

Last setting screen

I have disabled IPv6 on my WAN connection as I have no use for it at the moment

Would getting better hardware result in better speeds?
or would it be unnecessary?

I would expect the APU to do better than that. It should be good for around a gigabit i would think (j1900 can shape a gigabit and it's a similar era of cpu)

Log into the router and run top -d 1 then run your speed test and watch the cpu idle, how low does it go?

I Just ran the http://www.dslreports.com/speedtest , My cpu idle hovered around 50% to 60 %

remind me, does the device have 2 cores? that would indicate potentially one core saturated. though you can monitor individual cores with an appropriate full version of top and find out... not sure if one is available on OpenWrt.

See https://forum.openwrt.org/t/comparative-throughput-testing-including-nat-sqm-wireguard-and-openvpn/44724 the second x86 (AMD GX-412TC) is an APU IIRC, so in theory an APU might be able to traffic shape at your bandwidth...

I concur with @dlakelan, this might indicate one CPU running at maximum. (Potentially caused by packet steering).

it is either a dual or more likely a quad code SoC.

I believe htop is available and will report/display load per core (opkg update; opkg install htop).

Here is the test with htop

Yeah, it looks like it's saturating the 2nd core during the download at least briefly at different points during the test. I'd maybe suggest setting your download bandwidth to 300Mbps and running another test. You can leave your upload alone.

If you feel that this is not acceptable level of performance for you, I can heartily recommend switching to RPi4: RPi4 routing performance numbers

Do you think irqbalance would help him much?

Would be worth a try!

I just installed irqbalance through the software tab, I enabled irqbalace through rc.d and rebooted OpenWRT.
Below are the results

It seems to help abit, However the speeds are not acceptable level of performance.

Regarding your RPi4 Recommendation. I am willing to try it, but I would like to know is it capable to shape Gigabit speeds?

This question is based of trying to future proof when ISP will make it available

Yes the data from that link shows it handles gigabit easily

Could you recommend a USB to Ethernet adapter

Check the thread

Thank you providing that Guide.

Mmmh, maybe this is an additional case where packet steering does not work as it should?
You could temporarily disable this by deleting /etc/hotplug.d/net/20-smp-packet-steering and rebooting the router (there should be a copy left in /rom/etc/hotplug.d/net/20-smp-packet-steering if you find you need it). I have a hunch that the redhat recommended settings for packet steering really do not work well on low-core-count non-x86 routers.... especially with traffic shaping adding a considerable load.
irq-balance might work better if packet steering is not enabled (not sure whether it was in your test).

i just tried deleting the mentioned "packet steering"


It does not exist in my OpenWRT

Sorry, look for /etc/hotplug.d/net/20-smp-tune this was renamed recently, and I copied it from my router running master...

I have deleted the /etc/hotplug.d/net/20-smp-tune and rebooted OpenWRT

The connection peaked a little higher, but taxed the CPU more.