[Release] FreshJR Adaptive QOS (Improvements / Custom Rules / and Inner workings)

[ThiagoCururu]

1.176

 

[Vexira]

so whats the highest priorty did you set, also have you set the 90% or 95% bandwidrh rule 90%-95% of your total bandwidth see if it helps if not try 90% download and 80 upload, thr 90-95% i first stated applies to both speed test values try 95% first then 90%.

im on vdsl2 aka fttn and oddly i dont seem to have the same issues i run full bandwith values and i get a value of 30ms with netflix and youtube running no major spikes above 30 ms,highest was about 36 and im running an 88u.

 

[Vexira]

Also i want to rule out congestion, if your an aussie like me late at night you ping can shoot up alot if your area is prone to network congestion, usually in the arvo but during the day its fine, seems to be the case for me atleast. Also make sure adaptive qos is set to game mode, might help.

 

[FreshJR]

Dumb question, but will this help with Discord traffic being flagged as General rather than VOIP? It doesn’t sound as though there’s an easy way to manually flag Discord traffic based on ports: https://www.reddit.com/r/discordapp/comments/4g3179/is_there_a_way_to_make_discord_not_use_random/

No wouldn't help discord. All it does is move unidentified traffic into others category and two custom rules based on port.

According to the Reddit post, discord marks its packets with a special value in the (tos,dscp) ip header. Sniff it's traffic using wireshark or whatever you prefer. If you find what value they are marking packets I can prepare a rule.

@ThiagoCururu you are almost there.

Your QOS limits are set too high. You have to input percentages of your actual max upload/download bandwidth into the the webui until you don't get any bufferbloat no matter the network load. Read a few pages back and I showed an example of a speedtest simultaneously with the routers ping test.

Try limiting to 90% off the bat and see what happens.

As to the game updates/download being recognized as gaming traffic, I feel ur pain. I wish it didn't do that. Last time rmerlin said he pulled some values corresponding to qos from the qos definitions database. I tried opening that database a while back couldn't. If someone does manage to open it, maybe traffic identification can really be finely tweaked.

 

[Arsenal]

According to the Reddit post, discord marks its packets with a special value in the (tos,dscp) ip header. Sniff it's traffic using wireshark or whatever you prefer. If you find what value they are marking packets I can prepare a rule.

Thanks for that. Is this what you are after:

We already send the QoS headers to your router - you shouldn't need to set this up if your router already respects DSCP mark with a value of 0x38 or 802.1p tag with a value of 7 - which is the real time VOIP QoS packet flow priority.

From another reddit post https://www.reddit.com/r/discordapp..._on_router_making_a_rule_for_discord/d942b4r/

 

[FreshJR]

Thanks for that. Is this what you are after:

We already send the QoS headers to your router - you shouldn't need to set this up if your router already respects DSCP mark with a value of 0x38 or 802.1p tag with a value of 7 - which is the real time VOIP QoS packet flow priority.

From another reddit post https://www.reddit.com/r/discordapp..._on_router_making_a_rule_for_discord/d942b4r/

If you are sure that's the only mark they are using then these two rules should work

${tc} filter add dev br0 protocol all prio 1 u32 match u8 0x38 0xFC at 8 flowid ${VOIP}
${tc} filter add dev eth0 protocol all prio 1 u32 match u8 0x38 0xFC at 8 flowid ${VOIP}

0x38 = 001 110 00

The above rule will match 001 110 XX in the dscp field, with the X's being wildcards.



I would packet dump and test if the first three binary bits are always 001 with discord traffic, even thought thats what the reddit post claimed.

The reason for my skepticism is because first three binary bits describe expected qos priority (these are my own words as the technical description uses different terms).
-011 high priority
-010 med priority
-001 low priority
-000 lowest priority


The second three binary bits mean expected drop rate within that qos priority.
-110 low drop
-100 med drop
-010 high drop
-000 highest drop

The last two binary bits are something else and should have a wildcard.

I am skeptical because with 0x38 discord is asking low priority with low drop rate. Why is it asking for low priority for VOIP instead of high?

Using the old (deprecated) TOS naming then instead the first three bits were labeled
-000 routine
-001 priority
So with tos naming it technically is asking for priority. Now a days, classes above 001 are commonly used.

Either way, It would be nice for ASUS to further filter all unidentified traffic by its dscp mark. That way even traffic that bypassed deep packet inspection would still get sorted by priority with the rest of the unidentified traffic. Many improvements remain.. they could really make the ultimate router with more polish.

 

[ThiagoCururu]

Also i want to rule out congestion, if your an aussie like me late at night you ping can shoot up alot if your area is prone to network congestion, usually in the arvo but during the day its fine, seems to be the case for me atleast. Also make sure adaptive qos is set to game mode, might help.

I don't have latency spikes any time of the day, unless there's YouTube or Netflix traffic.
The last config before that script was Gaming > VOIP > Others > Web Surfing > Streaming > Files

@ThiagoCururu you are almost there.

Your QOS limits are set too high. You have to input percentages of your actual max upload/download bandwidth into the the webui until you don't get any bufferbloat no matter the network load. Read a few pages back and I showed an example of a speedtest simultaneously with the routers ping test.

Try limiting to 90% off the bat and see what happens.

As to the game updates/download being recognized as gaming traffic, I feel ur pain. I wish it didn't do that. Last time rmerlin said he pulled some values corresponding to qos from the qos definitions database. I tried opening that database a while back couldn't. If someone does manage to open it, maybe traffic identification can really be finely tweaked.

As I mentioned on my first message, I already did that limit on manual bandwidth. I pay for a 50/25 connection, but on dslreports it showed 51.23 and 26.1 speeds. I already limit it to 43/20 (85% and 80%).

Tomorrow I'll do a factory reset to rule out any other mistake I might have done. I'll leave all options on default and test, then script and test.

Thanks for helping so far.

 

[FreshJR]

I don't have latency spikes any time of the day, unless there's YouTube or Netflix traffic.
The last config before that script was Gaming > VOIP > Others > Web Surfing > Streaming > Files



As I mentioned on my first message, I already did that limit on manual bandwidth. I pay for a 50/25 connection, but on dslreports it showed 51.23 and 26.1 speeds. I already limit it to 43/20 (85% and 80%).

Tomorrow I'll do a factory reset to rule out any other mistake I might have done. I'll leave all options on default and test, then script and test.

Thanks for helping so far.

I wouldn't bother with a factory reset. Everything was in working order in the screenshot.

There's one other issue it could be. In the screenshot QOS was only filtering/accounting for ~9mbits of traffic.

With 9/50mbits used, there should of have been no bufferbloat on your connection. The only remaining issue I can think of is that your connect was actually being saturated ~50mbit, but qos has only been picking up 9mbps of that network traffic.

As a few users have pointed out, some https traffic bypasses QOS entirely. Add these two rules, and retest.

${tc} filter add dev br0 protocol all prio 22 u32 match mark 0x80130000 0x803f0000 flowid ${Web}
${tc} filter add dev eth0 protocol all prio 22 u32 match mark 0x40130000 0x403f0000 flowid ${Web}

When some traffic bypasses QOS, it ignores QOS limits and can saturate the connection. This means our whole concept of throttling by different traffic types is moot since the bypassed traffic is able to clog up our prioritized traffic, leading QOS having no effect.

Hope this made sense. We need to catch all traffic.

 

[Jack Yaz]

Looking to deploy this script, but unsure on what percentages to use to replicate this setup. Can someone help?

 

[FreshJR]

Looking to deploy this script, but unsure on what percentages to use to replicate this setup. Can someone help?

View attachment 10148

Percents in the script are guaranteed minimum bandwidths for each catagory. But remember that each category will NOT be using all of its guaranteed bandwidth continuously.

This now excess bandwidth, from the unused but guaranteed rates, will get offered from TOP to BOTTOM again in the order you have setup in your image. If that individual class needs some of that guaranteed bandwidth, there will be less bandwidth to offer from TOP to BOTTOM in your image.

With this setup the class percentages DO NOT correlate class priority. The class priority, in your image, will still be very much in effect. Go through the examples on the first page I have written out. The process should become very clear since its not a complicated process.

As for your question as to the value for the minimum percentages you should define, just choose what you feel is an important amount of bandwidth to guarantee to each category. Really, the percentages don't matter too much since the classes not using their minimums will offer their unused bandwidth from TOP to BOTTOM. The percentages just matter for you to guarantee which class will have how much bandwidth accessible, at a minimum, at all times. This allows you to guarantee being able to view stream at 10mbps at all times, or whatever you decide. The order in your image, pertains to EXCESS bandwidth from unused minimums. There will be EXCESS bandwidth offered 99.999% of the time.

 

[Jack Yaz]

Percents in the script are guaranteed minimum bandwidths for each catagory. But remember that each category will NOT be using all of its guaranteed bandwidth continuously.

This now excess bandwidth, from the unused but guaranteed rates, will get offered from TOP to BOTTOM again in the order you have setup in your image. If that individual class needs some of that guaranteed bandwidth, there will be less bandwidth to offer from TOP to BOTTOM in your image.

With this setup the class percentages DO NOT correlate class priority. The class priority, in your image, will still be very much in effect. Go through the examples on the first page I have written out. The process should become very clear since its not a complicated process.

As for your question as to the value for the minimum percentages you should define, just choose what you feel is an important amount of bandwidth to guarantee to each category. Really, the percentages don't matter too much since the classes not using their minimums will offer their unused bandwidth from TOP to BOTTOM. The percentages just matter for you to guarantee which class will have how much bandwidth accessible, at a minimum, at all times. This allows you to guarantee being able to view stream at 10mbps at all times, or whatever you decide. The order in your image, pertains to EXCESS bandwidth from unused minimums. There will be EXCESS bandwidth offered 99.999% of the time.

Thanks, that explains it nicely! I will start with percentages for categories I know what minimums I want to guarantee, and go from there!

 

[beboptrumpet]

It didn't work great for me either, but after a little troubleshooting, it is working great. On dsl reports speed test,
-I'm getting an A+ every catagory, My upload blufferboat averages under 5ms, My download blufferboat averages download 8-10ms., I'm getting 135mbps download and 20 Mbps upload

I'm using fq_codel on an Rt-AC87. I have Comcast Xfinity.
-I pay for a 150/20 connection.
-Rate tests without qos are 170/25, sometimes slightly better.
***try resetting the router & giving it a few minutes for qos to start working before testing***

-my best results come at 136/19 -if I raise either number, I get throttling about midway through the test. If I go down, don't see much difference with downlink, but my blufferboat multiplies on uplink. I was surprised that my uplink number was so close to my advertised connection
-I used default wan packet overhead for my connection--since I have a cable (docsis), it is set at the default 18 without ATM. I tried other values--that's what worked best for me.
-just to make sure you installed it right, go to the system log. Make sure you see an entry like this: Adaptive QOS: Modification Script Started, If you don't see it, make sure you followed the instructions. Another way is to look at the qos-qos statistics. If you are still seeing traffic in the default catagory, you might have forgot someing
-set manual rate limits. Note in the GUI, it asks for upload on the top box and download on the bottom. Getting them backwards makes your internet worse than before, if you don't set limits, it is set to 1800mb
-I was shocked at how much better fq_codel does with just the right rate limit--try numbers one by one...for me, a difference of 1 on my rate limit--especially on the uplink side--makes blufferboat multiply
-if you see your dowload speed tail off at the end of a speed test, turn it down until you get a consistent--flat line...especially on the second half of the test.
-I had better luck testing at off peak network times. When, first off, I was the only one in my house using my connection. Also, high cable, my neighbors useage could have played role with peak hour latency, not going to get into why here. My results are within +/-2ms throughout the day. Much better than the 200+ms blufferboat I used to get without it being on,

And finally,
-I set a custom order instead of selecting gaming/voip/web surfing, under the custom tab I set my order as follows:
Gaming/Other/Voip/Web surfing/Video and audio streaming/File transfer
-FQ_Codel along with this patch is definitely helping my gaming experience, especially when others are streaming video. It took my blufferboat on dsl reports from a C rating to an A+
-Thanks JRFresh and others who helped. This has brought new life to my router, Looking forward to 2.0--more gaming priority, and getting those r2q errors fixed.

 

[FreshJR]

Thanks, that explains it nicely! I will start with percentages for categories I know what minimums I want to guarantee, and go from there!

Remember for no issues:

No spaces before or after the equals.
No decimals in the desired percents
Read the part in the first post about requiring Notepad++, with a Linux EOL setting, to properly save the script in a router readable format.

 

[Jack Yaz]

Remember for no issues:

No spaces before or after the equals.
No decimals in the desired percents
Read the part in the first post about requiring Notepad++, with a Linux EOL setting, to properly save the script in a router readable format.

Well versed in Linux scripting so you won't be getting complaints from me about things not working, for those reasons anyway!

 

[FreshJR]

@beboptrumpet

User @ThiagoCururu had the script properly working.
You can see that defaults has no traffic within it. He also said in a post that he did input bandwidth values as a percent of his max.

In his supplied picture, summing the rate from the QOS statistic page, you can see it only adds up to 9mbps. With 9/50bmps used, he should be no buffer bloat.

So @ThiagoCururu refer to my last post as to next steps to get it properly working instead. It does seem that some https traffic is bypassing QOS. Apply the changes and we will debug from there.

 

[Jack Yaz]

Remember for no issues:

No spaces before or after the equals.
No decimals in the desired percents
Read the part in the first post about requiring Notepad++, with a Linux EOL setting, to properly save the script in a router readable format.

All running, seems good! Are these anything to be concerned with? Or just warnings that can be safely ignored?

Aug 18 22:10:01 kernel: HTB: quantum of class 10011 is big. Consider r2q change.
Aug 18 22:10:01 kernel: HTB: quantum of class 10012 is big. Consider r2q change.
Aug 18 22:10:01 kernel: HTB: quantum of class 10013 is big. Consider r2q change.
Aug 18 22:10:01 kernel: HTB: quantum of class 10015 is big. Consider r2q change.
Aug 18 22:10:01 kernel: HTB: quantum of class 10016 is big. Consider r2q change.

 

[Jack Yaz]

Am I right in thinking if I want to force port 563 traffic to Downloads (NZB) I would use:

${tc} filter add dev br0 protocol all prio 1 u32 match ip dport 563 0xffff flowid ${Downloads}

 

[FreshJR]

The quantum is just a warning. Your internet speed is so fast that the calculated quantum is so large that it freaks out and gives you a false warning.

Correct on your rule functionality.

For r2q explanation read this post from 2 pages back. In short, its not an error!

https://www.snbforums.com/threads/r...-and-inner-workings.36836/page-12#post-341122

But rather your internet faster than it expects.

Try following this analogy:

Think of quantum as the size of food bites you are eating. Think of your internet speed as to how fast you can eat. To not be scooping little food pebbles one at a time super fast with your spoon, you simply can change quantum and eat bigger chunks of food.

TC automatically calculates quantum based on rate. The resulting quantom was food expected to be measured in the size from pebbles to rocks. Now a days, some peoples internet is so fast that the calculated value amounts to them eating boundlers with a backhoe.

Just a warning letting you know that you are eating boulders.

What this means is that the granularity of qos bandwidth allocation is course (boulder size). In reality, the bandwidth rates are fast that the coarseness of the food size is not an issue.
It is not a problem for you to start eating pebbles again and just shovel your spoon at a significantly faster rate. This would reintroduce more granularity.

This r2q variable to compute quantum based on rate is defined within the TC application. You would have to recompile your own version if you want to change the auto calculated quantum values.

Merlin has a TC interposer to modify commands sent to ASUS's TC and forward them to his version of TC. This would allow you to change quantoms without recompiling TC. If you modify his interposer functionality you can manually define quantum for each class instead of using the calculated values based on r2q.

The interposer is located in /usr/sbin/faketc

I am not going to be changing variables at this level. Feel free to experiment

 

[Vexira]

All running, seems good! Are these anything to be concerned with? Or just warnings that can be safely ignored?

Aug 18 22:10:01 kernel: HTB: quantum of class 10011 is big. Consider r2q change.
Aug 18 22:10:01 kernel: HTB: quantum of class 10012 is big. Consider r2q change.
Aug 18 22:10:01 kernel: HTB: quantum of class 10013 is big. Consider r2q change.
Aug 18 22:10:01 kernel: HTB: quantum of class 10015 is big. Consider r2q change.
Aug 18 22:10:01 kernel: HTB: quantum of class 10016 is big. Consider r2q change.

read a few posts back on what wicked shrapnel wrote, but here it is for convenice:
Short answer, here is how you fix it. They fixed it in Redhat. https://www.redhat.com/archives/libvir-list/2016-February/msg00125.html <- way above my pay grade.

Long answer below

What quantum it is.

"It might be good time to touch concept of quantums now. In fact when more classes want to borrow bandwidth they are each given some number of bytes before serving other competing class. This number is called quantum. You should see that if several classes are competing for parent's bandwidth then they get it in proportion of their quantums. It is important to know that for precise operation quantums need to be as small as possible and larger than MTU.
Normaly you don't need to specify quantums manualy as HTB chooses precomputed values. It computes classe's quantum (when you add or change it) as its rate divided by r2q global parameter. Its default value is 10 and because typical MTU is 1500 the default is good for rates from 15 kBps (120 kbit). For smaller minimal rates specify r2q 1 when creating qdisc - it is good from 12 kbit which should be enough. If you will need you can specify quantum manualy when adding or changing the class. You can avoid warnings in log if precomputed value would be bad. When you specify quantum on command line the r2q is ignored for that class."

Source: http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm

Basically I think the issue is this algorithm was written at a time when bandwidth speeds in the hundreds of megabytes or gigabit wasn't feasible and letting r2q calculate the quantum value freaks it out when that number is so high.

If rate is less than 80 the quantum is small warning is provided.
If rate is greater than 16000 quantum is big warning is provided

Quantum is calculated as rate (in bytes) / r2q.
r2q is by default 10

For example, my download rate is set at 300Mb you take that (in bytes) divided by the default r2q of 10 and that equals 3,750,000 bytes for the quantum. The hard coded limit of quantum is 60,000 so it throws a warning.

So in order to prevent these warnings for my 300Mb connection, my r2q needs to be 20,000. That will keep the quantum under 16,000 where it cries but I think it would need to be even a bigger number to get my quantum closer to my MTU of 1500. Changing the r2q value would be the easiest option I think since there are a lot of classes and that would suck to change all of them manually.

There are a lot of classes, you can see them by running the following command
Code:
tc class show dev eth0
The class in the log " HTB: quantum of class 10011 is big. Consider r2q change." will be shown in the command output truncated like "class htb 1:11" they substitute a : in place of the zeros.

 

[Vexira]

The quantum is just a warning. Your internet speed is so fast that the calculated quantum is so large that it freaks out and gives you a false warning.

Correct on your rule functionality.

For r2q explanation read this post from 2 pages back. In short, its not an error!

https://www.snbforums.com/threads/r...-and-inner-workings.36836/page-12#post-341122

But rather your internet faster than it expects.

Try following this analogy:

Think of quantum as the size of food bites you are eating. Think of your internet speed as to how fast you can eat. To not be scooping little food pebbles one at a time super fast with your spoon, you simply can change quantum and eat bigger chunks of food.

TC automatically calculates quantum based on rate. The resulting quantom was food expected to be measured in the size from pebbles to rocks. Now a days, some peoples internet is so fast that the calculated value amounts to them eating boundlers with a backhoe.

Just a warning letting you know that you are eating boulders.

What this means is that the granularity of qos bandwidth allocation is course (boulder size). In reality, the bandwidth rates are fast that the coarseness of the food size is not an issue.
It is not a problem for you to start eating pebbles again and just shovel your spoon at a significantly faster rate. This would reintroduce more granularity.

This r2q variable to compute quantum based on rate is defined within the TC application. You would have to recompile your own version if you want to change the auto calculated quantum values.

Merlin has a TC interposer to modify commands sent to ASUS's TC and forward them to his version of TC. This would allow you to change quantoms without recompiling TC. If you modify his interposer functionality you can manually define quantum for each class instead of using the calculated values based on r2q.

The interposer is located in /usr/sbin/faketc

I am not going to be changing variables at this level. Feel free to experiment

isn't that how he got FQ_Codel and Codel working, leaving it up to someone to work out how to patch in hfsc and possibly cake if a compatible version exists, I did read the cake guys were trying to make it work with as many kernel versions as possible, if I can find a way to contact them ill ask them if they could possibly create a compatible version at worst they will just say no.