Default QoS Rules Contest **Complete**

Report issues relating to bandwith monitoring, bandwidth quotas or QoS in this forum.

Moderator: Moderators

Volaris
Posts: 177
Joined: Thu May 01, 2014 1:02 pm

Re: Default QoS Rules Contest

Post by Volaris »

pbix wrote:Some interesting ideas but nothing for the upload rules?

The small packet ideas seem to me to be most appropriately handled on the upload side since that is where these are. My sense is that people who are having problems with "bufferbloat" metrics or slow web page loads under heavy load show concentrate on upload rules.

Do you apply this same rule on the upload side?
For my rules, I apply the same on the upload side. Upload is the most important in QoS (especially making sure the bandwidth set isn't more than your connection can handle).

A way I test to make sure my upload bandwidth isn't too high, is I set a certain upload bandwidth, then using a laptop I maximize upload by uploading a big file to Google Drive or One Drive. On my phone I run a speed test. If the ping went up or if the internet feels sluggish, upload is set too high and needs to be lowered.
QoS Tip: Don't complicate your QoS settings. Gargoyle evenly splits available bandwidth between active devices as needed. Just delete all your classification rules and leave only one normal service class and you're done. No more arguing over bandwidth.

encro
Posts: 76
Joined: Fri Mar 13, 2015 10:52 am
Location: au.victoria

Re: Default QoS Rules Contest

Post by encro »

I think the Bufferbloat (<128 Priority/>128 Normal) 2 class style gives the best default choice for the average user. It keeps the Gargoyle UI responsive and makes Web pages super responsive.

I found myself in the unique position of getting upgraded to VDSL (NBN FTTN) which meant about a 5x speed increase in both directions on the exact same day this thread was created.

I stripped all my rules back which were heavily geared toward prioritising the PS4 and gaming and added just the one Simple Ruleset (100% Normal) which I trialled for the first few days. This was adequate for even distribution but as ratios for bandwidth were shifted around between devices under saturation stalling and pageload delays started to occur frequently.

The Bufferbloat QoS ruleset ensures it always remains responsive regardless of load (Streaming/Torrents/Large Downloads etc) and better able to manage adjustments because priority packets are no longer in the same queue, DNS resolves more efficiently also.

I've used the Bufferbloat ruleset for both Uploads and Downloads but am still trying to determine the right percentage to allocate to the Fast Priority Rule. Right now I am targeting 1000 kbps for the percentile to average from but feel I may be able to dedicate more to the Normal Class instead.

VDSL: 28000/6400
Netgear WNDR3700v4 (N600) - Gargoyle 1.14.x
D-Link DIR-835 - Gargoyle 1.7.1 (Deceased)
Manual set up for PIA's OpenVPN in (Private Internet Access): https://www.gargoyle-router.com/phpbb/viewtopic.php?f=11&t=9129&p=45410#p45410

Daeron
Posts: 28
Joined: Mon Oct 31, 2016 5:30 am

Re: Default QoS Rules Contest

Post by Daeron »

pbix wrote:Some interesting ideas but nothing for the upload rules?
I've also been mirroring my download and upload rules so far. It would probably make sense to have upload classes under tighter conditions but I haven't settled on a specific value yet.

As far as gaming goes, I would hesitate to go down to 128/128 as the default setting on packet length. For example, here's a game with just ~9 players that already seems to be consistently above 128 but would still be reasonably captured by 512. Then there's a server with 50-60 players which is probably a lost battle altogether using the packet length method only.

The takeaway I guess is that at least the upload traffic didn't change much. I would expect most games to fall into the <512 category while keeping everything else you wouldn't want in that class to a minimum, but I'll need more research on that. For now I'll probably try 512/128 for download/upload and see how it goes.

For my personal use I just created a Gaming class with actual port numbers for the few recurring games to make sure they are always captured. The rest is at the mercy of packet length, which seemed to work well enough so far minus edge case scenarios like the 64 player server mentioned above.
encro wrote:I've used the Bufferbloat ruleset for both Uploads and Downloads but am still trying to determine the right percentage to allocate to the Fast Priority Rule. Right now I am targeting 1000 kbps for the percentile to average from but feel I may be able to dedicate more to the Normal Class instead.
As far as I understood, it basically doesn't matter. All unused bandwidth from the class is recycled and given to all the other classes. You could give it 99% bandwidth and it would be fine as long as you can't actually fill out that much. With how small those packets are, the assumption is that you'll never be able unless your total bandwidth available is really low. To be on the safe side though I'd probably just do 50-50% and see if under load your class can get anywhere near that number. If you can't, it really doesn't matter if your prioritized class has 50 or 99%.
massive wrote:I would like to try this setup, because I just can't do anything with torrents, which are very important for me.
If it's your other devices not getting bandwidth it sounds to me you simply didn't have QoS enabled at all or it was set too high. Try Volaris' barebones setup with just a single class and see if your family complains still.

Still, if you are looking to specifically throttle Torrents, the only way is to simply set your Default Service Class to the throttled one, then give the select few applications priority over it.

Since you have supervision of the Torrent client itself, you could also try setting it up such that it uses a single port or a range of ports and use that as an additional rule to make sure that traffic stays in the throttled class and not picked up by something like packet length.

You could try something like this:

Classes:
Name: Gaming, Percent BW: 1%, Min BW: [at least 512], Min RTT: Yes
Name: High, Percent BW: 60%
Name: Medium, Percent BW: 30%
Name: Bulk, Percent BW: 9%

Rules in the order they appear in:
Destination Port: [ports used by your favorite games], Class: Gaming
Source Port: 53, Connection bytes reach: 3 kBytes, Class: Medium
Source Port: 53, Class: High
Source Port: 80, Connection bytes reach: 512 kBytes, Class: Medium
Source Port: 80, Class: High
Source Port: 443, Connection bytes reach: 512 kBytes, Class: Medium
Source Port: 443, Class: High
Destination Port: [your Torrent client's], Class: Bulk
Maximum Packet Length: 512 bytes, Class: High

This is for the Download side. Swap Destination and Source ports if you are setting up the Upload side. Maximum packet length/Connection bytes reach/Gaming minimum bandwidth values can be lower on the upload side as well.

pbix
Developer
Posts: 1373
Joined: Fri Aug 21, 2009 5:09 pm

Re: Default QoS Rules Contest

Post by pbix »

I have read the ideas of adding a rule for smaller packets. It is reported that systems with such rules are "more responsive" or give better scores on "bufferbloat" tests.

But it seems rather subjective to me with no quantitative explanation about why this would be the case. I wrote about my thoughts about this idea in the QoS page, years ago. second to last Myth at the bottom here:
https://www.gargoyle-router.com/wiki/doku.php?id=qos

I will concede that the calculation I propose there is not so simple. So it may be that a fast class on the uplink would be of some benefit for small packets if only to avoid anyone having to pull out their calculator. I cannot see the benefit of such a class on the downlink since the link is not asymmetrical in that direction. So I amend the first my OP to include one fast class for short packets on the uplink. This addition should be of help to torrent type people who are saturating their uplinks.

I would really appreciate someone who feels the small packet classes are beneficial to test my default against what they have now a report the differences.
Linksys WRT1900ACv2
Netgear WNDR3700v2
TP Link 1043ND v3
TP-Link TL-WDR3600 v1
Buffalo WZR-HP-G300NH2
WRT54G-TM

Daeron
Posts: 28
Joined: Mon Oct 31, 2016 5:30 am

Re: Default QoS Rules Contest

Post by Daeron »

As far as P2P goes, the conclusion here is that prioritizing ACK is detrimental:
http://www.linksysinfo.org/index.php?th ... ost-138513

The first post is also a nice read. I can't really say whether I agree or disagree, I'll just keep testing and see what I come up with on my own.

topshot
Posts: 9
Joined: Fri Sep 01, 2017 6:40 pm

Re: Default QoS Rules Contest

Post by topshot »

Volaris wrote:I do have an additional QoS rule option for those that care about improving bufferbloat (lag that occurs when your bandwidth is saturated). When tested on DSLReports' speed test, this gets you an A/A+.
It hasn't gotten me an A consistently (last test was a C), but using the current new defaults in post #1 gives results much better than it was. Can't post pics/links but this was last test I ran:
dslreports.com/speedtest/21179936.png

Image

ispyisail
Moderator
Posts: 5180
Joined: Mon Apr 06, 2009 3:15 am
Location: New Zealand

Re: Default QoS Rules Contest

Post by ispyisail »

@pbix

You might want to push your decision as an official build might be coming out soon?

I would just use a conservative rules

pkm
Posts: 106
Joined: Sat Aug 22, 2015 4:49 am

Re: Default QoS Rules Contest

Post by pkm »

topshot wrote:
Volaris wrote:I do have an additional QoS rule option for those that care about improving bufferbloat (lag that occurs when your bandwidth is saturated). When tested on DSLReports' speed test, this gets you an A/A+.
It hasn't gotten me an A consistently (last test was a C), but using the current new defaults in post #1 gives results much better than it was. Can't post pics/links but this was last test I ran:
dslreports.com/speedtest/21179936.png

Image

Is this with ACC enabled?

Volaris
Posts: 177
Joined: Thu May 01, 2014 1:02 pm

Re: Default QoS Rules Contest

Post by Volaris »

I upgraded to 1.10.0 and did further testing.

What happens if you don't do a BufferBloat rule and simply leave no rules? In general it works fine since Gargoyle equally splits bandwidth, but if you maximize upload on the SAME device (say you're sending a big file or doing a phone/photos back up), then web browsing gets really laggy. Same if you start torrenting. Only the machine uploading or torrenting is affected. Other devices continue working fine with normal web browsing speed - again, thanks to Gargoyle's splitting of bandwidth.

----

To try to fix the above issue, I tried a variety of tests and rules. I would maximize upload by uploading a large 1.5GB file to Google Drive, then I'd test ping, bufferbloat with DSLReports, and web browsing in general. Then I'd torrent an Ubuntu ISO and again test ping, bufferbloat with DSLReports, and web browsing in general. What I tried prioritizing:

max 128 bytes, then max 128 bytes on upload only, then max 128 bytes on both upload and download BUT TCP ONLY, then max 512 bytes upload/download TCP only, among a few others.

Ultimately the combination that worked best for me was the following:

Upload: max 512 bytes gets Fast 50%. Normal 50% (10/90 didn't work because torrent would max the Fast 10%)

Download: max 512 bytes gets 10% and Normal 90% (torrenting didn't max out the 10%... gives you lots of room to still create your own rules as needed).

Using that combination, when torrenting to maximizing upload on the same device, web browsing remains zippy, pings normal/load, and Bufferbloat an A/A+.

What my setup looks like:

Download:
Image
Upload:
Image
Download and upload:
Image
QoS Tip: Don't complicate your QoS settings. Gargoyle evenly splits available bandwidth between active devices as needed. Just delete all your classification rules and leave only one normal service class and you're done. No more arguing over bandwidth.

topshot
Posts: 9
Joined: Fri Sep 01, 2017 6:40 pm

Re: Default QoS Rules Contest

Post by topshot »

pkm wrote:
topshot wrote:
Volaris wrote:I do have an additional QoS rule option for those that care about improving bufferbloat (lag that occurs when your bandwidth is saturated). When tested on DSLReports' speed test, this gets you an A/A+.
It hasn't gotten me an A consistently (last test was a C), but using the current new defaults in post #1 gives results much better than it was. Can't post pics/links but this was last test I ran:
dslreports.com/speedtest/21179936.png

Image

Is this with ACC enabled?
Yes. Should it not be?

Post Reply