[384.9_Alpha - builds] Testing all variants.

[RMerlin]

I guess it was just that I was trying to use traditional QoS. I got similar results with the stock firmware, so I enabled adaptive QoS in Merlin, and it's going at full speed. For traditional mode, you would need two full cores at 100% to max out a gigabit connection.

Traditional = zero HW acceleration
Adaptive QoS = first level of HW acceleration
No QoS = both levels of HW acceleration

There are less cpu intensive queuing algorithms for QoS available, intended more for high speed connections like gigabit, which simply ensure every device gets a fair share of bandwidth.

No reason for deep packet analysis, different classes, etc at those speeds.

The problem is that any iptables-based classification (like what Traditional QoS does) requires disabling hardware acceleration on the Broadcom platform (no idea if that's also the case for other manufacturers's implementations).

The reason why Adaptive QoS (with its DPI engine) works with hardware acceleration is that the DPI engine runs as a kernel module, and sits outside of Netfilter. So, hardware acceleration is still able to bypass the FORWARD chain, as packet marking is done by another kernel module.

So in a sense, DPI-based gives you better performance in Asuswrt because it can work alongside HW acceleration.

 

[RMerlin]

I keep getting /usr/sbin/acsd running at 50% (one whole core).

Closed-source daemon from Broadcom that handles automatic channel selection. Outside of my control, just use a fixed channel instead of leaving it on Auto.

 

[BlueFrog]

Merlin, thanks! However, I can't select the channels with the Tri-Band Smart Connect enabled, I can't set the channels manually. They are all forced to Auto. Would you recommend disabling the Tri-Band Smart Connect or maybe writing a cron that would check for this process to be over 10% of CPU and restart it? Is this the latest acsd binary blob?

 

[FreshJR]

Traditional QoS does .. requires disabling hardware acceleration

Adaptive QoS ... works with hardware acceleration. ... hardware acceleration is still able to bypass the FORWARD chain, as packet marking is done by another kernel module.

I understand that traditionalQOS has been disabling HW accel when enabled but I never really understood why that was a requirement.

Is the reason for disabling HW accel ONLY simply to be able mark packets at the forward chain as you stated??

1) It seems that the postrouting chain can STILL exhibit mark functionality while hw acceleartion IS enabled. If hw acceleration is being disabled to access marks within the forward chain what would be wrong with using postrouting in lieu of forward ?

2) QOS intended for high speed connections doesn't need any mark functionality for fine grained sorting since prioritzation is (mostly) pointless at those speeds vs fair bandwidth allocation.

Spoiler: Example setup of QoS without requiring mark functionality

Create 1 htb root CLASS to achieve rate limiting.
Create 1 FILTER rule to subject all client traffic into that htb class
Create 1 sfq QUEUE for traffic exiting htb class


What SFQ queue does is that it takes all traffic passing through it and puts into a large number of individual queues via a dynamically changing hash function. These individual traffic queues are de-queued round robin.

With a FIFO (first-in first-out) queue the packets from the most active connection would choke everything else out. Yet with sfq, packets from each individual connection are de-queued fairly since they were mixed up amongst the smaller individual traffic queues in a random (stoichastic) manor via the hash function which will then be de-queued round robin. The end result is that traffic allocation is FAIR per opened connection.

Now heres the magic trick for many devices sharing a high speed connection:
Create a FILTER to change the hash function of the sfq QUEUE that was created previously.

Within TC you are able to change parameters of the sfq hash function so that it is NOT based on (source IP + source port + destination IP + destination port) but rather based only on (source IP).

This change will make it so SFQ is not be fair per each individual connection opened but rather will make SFQ be fair per local device.

In the end you will have equal bandwidth across the local devices and the sum of all traffic will be subject to the cieling defined in htb. No marks or significant CPU overhead required.

I just don't understand why we cant mimic the structure of adpativeQOS SANS the DPI overhead.

(I am just thinking outloud in laymans terms. What you are doing RMerlin is over my head and these thoughts are not directed at you to implement/change somthing!!)

Traditional QoS does) requires disabling hardware acceleration on the Broadcom platform (no idea if that's also the case for other manufacturers's implementations).

Mikrotik (not here to push products BTW) can handle QoS upto gigabit speeds, so definitely has HW accell.
This queue is similar to what I described above and can handle gigabit. https://wiki.mikrotik.com/wiki/Manual:Queues_-_PCQ

 

[BlueFrog]

Ok, so I did this in /jffs/scripts/CPUkiller.sh to get the highest CPU process, check to see if it is on the troublemakers list (in this case only /usr/sbin/acsd) and if so, kill it....

#!/bin/sh
# tries to kill process with highest CPU load
# (if it is part of a specified list of troublemakers)
TROUBLEMAKERS="/usr/sbin/acsd"
sleep 1 # wait a few seconds (just as a precaution)
TOPPROCESS=$(top -b -n 1 | sed 1,6d | sed -n 2p)
TOPPID=$(echo "$TOPPROCESS" | awk '{print $1}')
TOPNAME=$(echo "$TOPPROCESS" | awk '{print $9}')
if [[ "$TROUBLEMAKERS" == *"$TOPNAME"* ]]
then
echo "Cause of high CPU load: "$TOPNAME" ("$TOPPID")"
echo "In troublemaker list. Killing..."
kill -9 $TOPPID
else
echo "Cause of high CPU load: "$TOPNAME" ("$TOPPID")"
echo "Not in troublemaker list. Exiting..."
exit 1
fi
exit 0

Then set this into crontab so it checks every 15 minutes:
5,20,35,50 * * * * /jffs/scripts/CPUkiller.sh 2 2>/dev/null >/dev/null

This should keep a runaway acsd under control. acsd just restarts itself and runs fine for a while.
Should there be any issue with this?

 

[hifiwifi]

RT-AC1900P on Alpha 3---Upon boot all clients (16) show up, but quickly all disappear form the Network Map except for the manually assigned ones. Connectivity is fine. They just don't show up (they are available under "offline client list" on the DHCP tab.)

 

[RMerlin]

Merlin, thanks! However, I can't select the channels with the Tri-Band Smart Connect enabled, I can't set the channels manually. They are all forced to Auto. Would you recommend disabling the Tri-Band Smart Connect or maybe writing a cron that would check for this process to be over 10% of CPU and restart it? Is this the latest acsd binary blob?

You can't indeed change channel while in Smart Connect mode.

The included acsd blob is whatever was in the GPL that I merged for that specific model.

 

[RMerlin]

Is the reason for disabling HW accel ONLY simply to be able mark packets at the forward chain as you stated??

You would have to ask Broadcom, because only they know the answer to this. Also, note that by design, any marked packet will currently bypass CTF. This is how port forwarding is able to work with CTF enabled - by marking any forwarded traffic.

I just don't understand why we cant mimic the structure of adpativeQOS SANS the DPI overhead.

The DPI engine works outside of the Netfilter chain, which is probably one of its big advantage there.

Mikrotik (not here to push products BTW) can handle QoS upto gigabit speeds, so definitely has HW accell.

Everyone's implementation is different. They could very well have it implemented in a kernel module. Or their hardware acceleration might be able to deal with packet marking done at the Netfilter level.

To be honest, I simply don't care about Traditional QoS at all. It's broken, and without IMQ/IFB and a modern scheduler it's also half-useless. People should either use Adaptive QoS, or look to a more modern solution like OpenWRT.

 

[Magnus33]

Hmmmm that not reading change log virus is sure catching

 

[Gar]

do i see right an rt 3200 is included , anybody give it a try ??

whoose fw is this Merlin Asus or new by someone unknown ?

Hope it's not the last of the 3200 updates, but I have a feeling.

 

[ShelaMonster]

You can't indeed change channel while in Smart Connect mode.

The included acsd blob is whatever was in the GPL that I merged for that specific model.

Oddly you can in stock AX88U firmware it seems.

 

[Grisu]

Why are there ch. 120-128 (should be on all models) and most curious 144 open which has been closed some years ago for all newer firmwares?
Now reopened 144???

 

[Lutek]

Is it possible to adjust the power of wifi in AC86U ?

 

[Grisu]

Is it possible to adjust the power of wifi in AC86U ?

simply no

 

[jerry6]

all working well with Alpha3 on 3200 , thanks again for this great FW
sorry about the lame post yesterday , brain still ain't working 100% still a bit of a fog

 

[Gitsum]

Merlin, I like the classification page that you added, thank you. How far away are you from adding a search box so that you can isolate just one ip address on the output?

 

[Treadler]

all working well with Alpha3 on 3200 , thanks again for this great FW
sorry about the lame post yesterday , brain still ain't working 100% still a bit of a fog

I hear you, stay strong.......

 

[RMerlin]

Oddly you can in stock AX88U firmware it seems.

Then that would be either a bug, or a change specific to the SDK version used by the RT-AX88U.

Why are there ch. 120-128 (should be on all models) and most curious 144 open which has been closed some years ago for all newer firmwares?
Now reopened 144???

Model-specific. US DFS channels are being added only on the newer models since those have passed required FCC certification to allow them. Devices validated in the past were never authorized for DFS channels, and since re-validation is an expensive process, I suspect it's highly unlikely to happen to those older models.

Merlin, I like the classification page that you added, thank you. How far away are you from adding a search box so that you can isolate just one ip address on the output?

Unlikely because it would be complicated - the table rendering is all handled by a Javascript object developed by Asus, and it limits my ability to interact with its content. You can easily sort the list by IP addresses, and most browser make it easy to do a search in page anyway.

 

[octopus]

Close this, beta build is out.
https://www.snbforums.com/threads/beta-asuswrt-merlin-384-9-beta-is-now-available.54731/