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

[Tekneek]

with adaptive nos bandwidth values should i use 37.87 or 37.9 or 38, im just not sure how it handles the decimal point value.

Is that 100% of your bandwidth? You should only use 90-95% of that (that's what I often see recommended). I use 95% and always test well on bufferbloat (A+ at speedtest). I recommend rounding down when you calculate that 95% number as well.

 

[Vexira]

Is that 100% of your bandwidth? You should only use 90-95% of that (that's what I often see recommended). I use 95% and always test well on bufferbloat. I recommend rounding down when you calculate that 95% number as well.

I already have a rule in the script that changes it to 95% I'm just trying to work out the correct way to enter it into the gui for the rule to process.

 

[skeal]

with adaptive nos bandwidth values should i use 37.87 or 37.9 or 38, im just not sure how it handles the decimal point value.

Decimals have to be supported. This is proved by the people that use this script with low upload bandwidth connections like DSL.

 

[FreshJR]

Decimals are supported in WebUI.

WebUI takes the mbps input, multiplies it by 1024, and truncates the resulting decimal portion, and is left with a whole number kbps which is then input into TC.

I doubt you need double digit precision. It’s simply not that accurate. Just input whatever works. The 85-95% is a rule of thumb, not an exact science.

 

[FreshJR]

While investigating rules not working on a forum members configuration, I found some very interesting results.

In this case, it was found that any rules related to IPs or Ports on the AC86U were not working even though it had a typical “automatically dhcp assigned // eth0” connection. (MARK only rules did work as expected)

It might be worth your time to create a temporary TC (traffic control) rule to push all traffic for a specific local device, by IP, into a lightly used catagory, like VOIP. You should then see if the temporary rule, filtering by the local device’s LAN IP, is correctly placing traffic into the VOIP category as expected during a speedtest. This is test procedure is recommended no matter your router model.

If the temporary rule above is not working as expected, I would recommended switching to the alternative version of the script linked in the third post as that implementation was found to work correctly on all setups.

I didn’t dig deeper as to what setting could potentially be causing this conflict.

I believe the users AC86U was cascaded behind another router, so it might be possible that his packets had VLAN TAGGING enabled and that shifted the packet a few bytes invalidating the packet hard coded offset locations that TC uses when filtering by IP address or port. As I said, I didn’t look deeper into it, since a working solution was readily available.

Other users have reported no issues with the AC86U. So this is just an issue to keep in mind if debugging or just to check for peace of mind.

 

[Kingp1n]

@FreshJR it we have an eth0 connection, can we use the alternative version if something is not working correctly? Is there a fast alternative version? Sorry for the noob questions?

 

[FreshJR]

@FreshJR it we have an eth0 connection, can we use the alternative version?

Yes, the alternate version works for all connection types, eth0 included.

I believe the TC implementation **might** use less CPU power, so it might be worthwhile to see if the TC implemention is working as expected, via the instructions in the previous post, before unnecessarily switching over.

If switching, do keep in mind that your existing script has to be fully uninstalled first via the command line!!
This is mentioned in the instructions of the alternative version, but here the message again to reinforce the requirement.

The TC implementation has worked for many users to date but I cannot test everything as I only have one connection && one router. The additional information/alternative varient develops as I receive individual bug reports and check out cases, one by one, via teamviewer.

Currently the ALTERNATIVE version is present for the fringe cases where the normal script versions are not working as expected.

 

[skeal]

@FreshJR it we have an eth0 connection, can we use the alternative version if something is not working correctly? Is there a fast alternative version? Sorry for the noob questions?

@FreshJR said above:

It might be worth your time to create a temporary TC (traffic control) rule to push all traffic for a specific local device, by IP, into a lightly used catagory, like VOIP. You should then see if the temporary rule, filtering by the local device’s LAN IP, is placing traffic into the VOIP category as expected during a speedtest. This is test procedure is recommended no matter your router model.

If the temporary rule above is not working as expected, I would recommended switching to the alternative version of the script linked in the third post as that implementation was found to work correctly on all setups

 

[shelleyevans]

@shelleyevans Post a pastebin link to your script as currently setup

The output of /jffs/scripts/FreshJR_QOS -debug may also be useful.

Thank you (all of you!) for your reply re: Crashplan! For some reason I didn't get notified in my email. I will happily post a pastebin link if you could clarify about what it is.... (Sorry, as I said, some of this is over my head) And also, how do I do the debug? Just ssh in and then run it in terminal?

 

[FreshJR]

It’s a website to share text documents easily. Just paste your script into there.

Debug is a ssh command. Correct

 

[johnathonm]

Stupid question, we normally have to reduce our total upload and download available bandwidth by 10% to 15%, do we need to do that here?

Thanks,
J

 

[FadgewackeR]

Stupid question, we normally have to reduce our total upload and download available bandwidth by 10% to 15%, do we need to do that here?

Thanks,
J

Yes, in the WebGUI. Fill those values with your reduced bandwidth figures and the script sets raes and ciels from that information.

 

[Vexira]

Stupid question, we normally have to reduce our total upload and download available bandwidth by 10% to 15%, do we need to do that here?

Thanks,
J

Or you can use a bandwith reduction command that Freshjr gave me which use, it goes Into the script it self, allowing you to pitfull band with into the gui and preforming the reduction at the script level.

 

[Sinner]

Or you can use a bandwith reduction command that Freshjr gave me which use, it goes Into the script it self, allowing you to pitfull band with into the gui and preforming the reduction at the script level.

When you say full bandwidth what are you referring to? The advertised speeds your paying for should never be used at all ever. Some people get higher than that and most lower. And that not even factoring in load during peak hours. You must go by your avg achievable speed test results and adjust from there. Personally id find it much easier to adjust from the gui when/if needed rather than having to mod the script constantly and reflash it.. just my opinion

 

[Sinner]

Its critical the ul/dl numbers set in the gui are any amount lower than the actual speed your capable of at any givin moment. The very second your conn dips even 10kbps below that number qos wont work at all to reduce bloat. It may still attemp to priorize traffic a bit but ultimatly the buffering has started on the isp end and its out of the routers control.

 

[Sinner]

I personally have mine set in the gui to just above the lowest speed test results ive been getting recently. The reason is due to im guessing schools out and my speeds have been quite volitile and dipping much lower than normal very regularly. To ensure qos can function at least 90% of the time perfectly ive had to set it that way if that makes any sense. Even set that low its very noticable during those brief moments when it dips below but is so brief i can tolerate it.

 

[Vexira]

When you say full bandwidth what are you referring to? The advertised speeds your paying for should never be used at all ever. Some people get higher than that and most lower. And that not even factoring in load during peak hours. You must go by your avg achievable speed test results and adjust from there. Personally id find it much easier to adjust from the gui when/if needed rather than having to mod the script constantly and reflash it.. just my opinion

*sigh* the speedtest.net values and aslong as you set the wan per packet overhead value it adds another level of reduction, of we had a full set of qos features you would actually set only the speed test values then set your overhead values which deduct an amount of bandwidth from the set values to account for connection overheads therefore optimising it for your connection

 

[Vexira]

I personally have mine set in the gui to just above the lowest speed test results ive been getting recently. The reason is due to im guessing schools out and my speeds have been quite volitile and dipping much lower than normal very regularly. To ensure qos can function at least 90% of the time perfectly ive had to set it that way if that makes any sense. Even set that low its very noticable during those brief moments when it dips below but is so brief i can tolerate it.

According to lede if using fq-codel it's 95% of speed test values and 80% of advertised values plus you set the over head value.

The % thing was there before they worked out the overhead values for connections.

 

[Sinner]

According to lede if using fq-codel it's 95% of speed test values and 80% of advertised values plus you set the over head value.

The % thing was there before they worked out the overhead values for connections.

Wel those are suggested amounts. Have you watched your speed tests? Are you getting perfectly solid 95% start to finish? If yes thats awesome and go with the automated script. If no then you need to adjust to your needs. Example. 10mb connection. You run a test, during that test it dips to 5mb 7 times and jumps to 20mb for a few secs once... the speed test may come back saying you achieved avg of 10mb. But realistically it was much lower for most of the test. If you set qos to 10mb it cant work during those periods where its lower. Thus you need to set it to something that makes more sense most of the time. In this scenario 6 or 7 mb would prolly be realistic or 5ish if you have very ping sensitive things runnning you cannot have lag ever.

 

[Vexira]

Wel those are suggested amounts. Have you watched your speed tests? Are you getting perfectly solid 95% start to finish? If yes thats awesome and go with the automated script. If no then you need to adjust to your needs. Example. 10mb connection. You run a test, during that test it dips to 5mb 7 times and jumps to 20mb for a few secs once... the speed test may come back saying you achieved avg of 10mb. But realistically it was much lower for most of the test. If you set qos to 10mb it cant work during those periods where its lower. Thus you need to set it to something that makes more sense most of the time. In this scenario 6 or 7 mb would prolly be realistic or 5ish if you have very ping sensitive things runnning you cannot have lag ever.

Question have you actually read the article, and secondly have you set your per packet overhead value?
I'm just qurious that's all.