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

[FreshJR]

@Tekneek A pastebin.com is ideal.

If you can’t get it to work. Just email it over to my paypal email.

 

[Vexira]

If quantum’s are not modified cpu usuage will remain the same.

(Quantum is how big of a shovel is used when processing the flow of traffic. Same shovel username = same amount of work )

I’ll have to check the currently set quantums,bursts, and cbursts at the following speeds

1
2.5
5
10
25
50
100
250
500

and if the Asus quantums are too high for desired halved or minimized bursts, then quantums would also have to be lowered (more cpu usuage). This can be the case at higher speed connections if requiring lowered bursts.

Haven’t had time to mess with it yet.

That's interesting would be awesome if there was a entry on the Merlin wiki with all this explanation would be handy also, I can feel that QoS is going to become a lot better soon.

 

[Tekneek]

@Tekneek A pastebin.com is ideal.

If you can’t get it to work. Just email it over to my paypal email.

File was too large for my free pastebin account. You've got a URL for PayPal now, not sure what email address that is linked to (did not find it or have it cached).

For what it is worth, the router seems to have maintained Undf FlowID: 1:13 through the night this time.

 

[L&LD]

File was too large for my free pastebin account. You've got a URL for PayPal now, not sure what email address that is linked to (did not find it or have it cached).

For what it is worth, the router seems to have maintained Undf FlowID: 1:13 through the night this time.

I had the same issue with pastebin.com.

Paste it here in multiple responses (1, 2, 3) but use the insert 'code' method from the edit menu icons as requested by FreshJR.

Example:

Test Code

 

[GxlactusDa]

Can somebody show me exactly how to prioritize a games ports in traditional QoS.

 

[Alamei]

I'm not quite able to tell from the past few pages: Is FreshJR_QOS 8.8 safe to use on Merlin 384.10, or should I hold off on enabling it? I always disable any custom scripts when updating firmware, and I haven't re-enabled it yet, since it sounds like there may be a few lingering incompatibility issues between the script and the firmware due to changes on Merlin's side.

Side-note: I'd forgotten how bad the stock QoS implementation was, and having your custom QoS disabled for just a few days has been a disheartening reminder. ASUS should really be working to either integrate or at least mimic the core functionality your improved QoS implementation, because the existing one is a bit of a joke.

 

[L&LD]

I'm not quite able to tell from the past few pages: Is FreshJR_QOS 8.8 safe to use on Merlin 384.10, or should I hold off on enabling it? I always disable any custom scripts when updating firmware, and I haven't re-enabled it yet, since it sounds like there may be a few lingering incompatibility issues between the script and the firmware due to changes on Merlin's side.

Side-note: I'd forgotten how bad the stock QoS implementation was, and having your custom QoS disabled for just a few days has been a disheartening reminder. ASUS should really be working to either integrate or at least mimic the core functionality your improved QoS implementation, because the existing one is a bit of a joke.

No problem updating the firmware on RT-AC68's, RT-AC3100's, RT-AC86's so far.

Without disabling any of the scripts either.

 

[FreshJR]

Still compatible with 384.10

Looks like the 5 minute wait needs to be increased to 10 minutes for some routers.

 

[Alamei]

Still compatible with 384.10

Looks like the 5 minute wait needs to be increased to 10 minutes for some routers.

Excellent; thank you for the clarity. Is the AC68 one of the routers that I should bump the wait time on, or is that only for more recently produced routers?

 

[FreshJR]

Excellent; thank you for the clarity. Is the AC68 one of the routers that I should bump the wait time on, or is that only for more recently produced routers?

Nope. The ac68u works fine on my end with a 5 minute wait.

 

[Sinner]

Still compatible with 384.10

Looks like the 5 minute wait needs to be increased to 10 minutes for some routers.

What is the extended wait for on some devices if u don't mind me asking. Ive had no issues with 30secs on my 3100.

 

[Alamei]

One more quick follow-up question: I noticed that in the installation instructions on this thread, you're having the user pull down the modified QoS_Stats file with curl as part of the install commands, while the installation instructions on Github exclude that particular command in the install chain. I see that you automatically pull a new copy of the QoS_Stats file when the update routine is run in the core script, but don't see anything that would pull it initially during an installation if it isn't present. Is that additional curl command to download the QoS_Stats file still necessary/preferred for new installations?

 

[FreshJR]

GitHub install command is outdated.

Next release it will fall back to single curl command for download, and the GitHub line will work.

Use the one in the first post.

 

[Datalink]

If you have a file thats too large for pastebin, or any other drop box type of service, try send.firefox.com Drag and drop the file that you want to send, then set a download and time limit, and the service will generate a link that you can send via email to the intended recipient.

 

[FreshJR]

What is the extended wait for on some devices if u don't mind me asking. Ive had no issues with 30secs on my 3100.

Not quite sure as the qos logger built into fakeTC only logs raw commands WITHOUT timestamps.

I was mainly checking the raw commands to see if QoS was stuck endless restarting.
Upon review, I saw that Tekneeks QoS had 4 restarts when initially activated and then 1 additional restart significantly later into the process.
We'd have to redo the test with timestamps to actually see how much later, but I feel like a change from 5 -> 10 min will be sufficient (as a guess).

It also could of been a QoS definitions check or some other INFREQUET action that does occur in the background and wipes the QoS structure. These things do occur from time to time and that is why the daily scheduled check is in place. The check would have re-applied the modifications at 3:30am at night.

 

[Jack Yaz]

Not quite sure as the qos logger built into fakeTC only logs raw commands WITHOUT timestamps.

I was mainly checking the raw commands to see if QoS was stuck endless restarting.
Upon review, I saw that Tekneeks QoS had 4 restarts when initially activated and then 1 additional restart significantly later into the process.
We'd have to redo the test with timestamps to actually see how much later, but I feel like a change from 5 -> 10 min will be sufficient just as a guess.

It also could of been a QoS definitions check or some other INFREQUET action in the background that wiped the QoS structure. These things does occur from time to time and that is why the daily scheduled check is in place. The scheduled check would have re-applied the modifcations next time it ran (3:30am at night).

Do you know if any services are restarted that wipe the structure?

 

[FreshJR]

Do you know if any services are restarted that wipe the structure?

Changing anything to do with TrendMicro can wipe the structure WITHOUT triggering firewall-start (AiProtect, Definitions Check, etc).

It is possible to reprogram the script trigger to listen for "restart_qos" instead of "firewall_start" but the current approach allows the script to remain backwards compatible with older versions of RMerlin firmware (before the service trigger was introduced). The daily scheduled check approach is sufficient for the infrequent amount of times it happens.

The router always finishes firewall-start and THEN launches qos after. An alternate theory is that Tekneek may have many other entires in firewall-start so it could be:

-My script starts
-A long running script starts (or even one that never exits and hits the firewall-start timeout)
-Finally when QoS is started, the scripts timer is already half way through or almost expiring.

 

[RMerlin]

Not quite sure as the qos logger built into fakeTC only logs raw commands WITHOUT timestamps.

I was mainly checking the raw commands to see if QoS was stuck endless restarting.
Upon review, I saw that Tekneeks QoS had 4 restarts when initially activated and then 1 additional restart significantly later into the process.
We'd have to redo the test with timestamps to actually see how much later, but I feel like a change from 5 -> 10 min will be sufficient (as a guess).

It also could of been a QoS definitions check or some other INFREQUET action that does occur in the background and wipes the QoS structure. These things do occur from time to time and that is why the daily scheduled check is in place. The check would have re-applied the modifications at 3:30am at night.

Have you investigated to see if maybe you could use a services-event script to intercept some of these events, such as signature updates or QoS restarts?

 

[FreshJR]

Have you investigated to see if maybe you could use a services-event script to intercept some of these events, such as signature updates or QoS restarts?

I can.

But there are some users on older firmwares before the services trigger was introduced. I didn’t want to break compatibility.

 

[RMerlin]

I can.

But there are some users on older firmwares before the services trigger was introduced. I didn’t want to break compatibility.

Could be an additional option to improve robustness for people using up-to-date firmware. Check the changelog to see which version added that script, and look at the buildno nvram to determine whether or not tu use it.