Are these settings correct
-
BUMP! I have typed them out this time.
I have setup the WAN queue as follows, it has a bandwidth of 1600Kbit/s, Scheduler Type is HFSC
I then have a MAIN queue called qInterenet which then has all my queues in it.| Queue Name | Priority | Queue Length | Bandwidth | Min bandwidth for queue | Max bandwidth for queue | Scheduler options |
| qACK | 6 | none | 20% | m2:400Kb | None | Explicit Congestion Notification & Codel Active Queue |
| qDefault | 3 | 150 | 10% | None | None | Default & Explicit Congestion Notification & Codel Active Queue |
| qGames | 5 | none | 20% | m2:400Kb | None | Explicit Congestion Notification & Codel Active Queue |
| qOthersHigh | 4 | 10% | 10% | m2:400Kb | None | Random Early Detection & Explicit Congestion Notification & Codel Active Queue |
| qOthersLow | 2 | 5% | 5% | none | None | Explicit Congestion Notification & Codel Active Queue |
| qSuperLow | 1 | 50 | 10% | none | 800Kb | Explicit Congestion Notification & Codel Active Queue |LAN queue Bandwidth is 35840Kbit/s, Scheduler Type is HFSC
| Queue Name | Priority | Queue Length | Bandwidth | Min bandwidth for queue | Max bandwidth for queue | Scheduler options |
| qACK | 6 | none | 20% | m2:8Mb | None | Explicit Congestion Notification & Codel Active Queue |
| qLink | 2 | 150 | 20% | None | m1:33Mb d:7000 m2:25Mb | Default & Explicit Congestion Notification & Codel Active Queue |
| qGames | 5 | none | 20% | m2:8Mb | None | Explicit Congestion Notification & Codel Active Queue |
| qOthersHigh | 4 | none | 10% | m2:8Mb | None | Random Early Detection & Explicit Congestion Notification & Codel Active Queue |
| qOthersLow | 3 | 5% | 5% | none | None | Explicit Congestion Notification & Codel Active Queue |
| qSuperLow | 1 | 50 | 10% | none | m2:25Mb | Explicit Congestion Notification & Codel Active Queue |Rules
| Rule Name | Protocol | Port | Queue |
| ICMP | IPv4 ICMP | * | qOthersHigh |
| SSH | IPv4 TCP | 22 | qACK/qOthersHigh |
| DNS | IPv4 UDP | 53 | qOthersHigh |
| TeamSpeak | IPv4 UDP | 9987 | qOthersHigh |
| VPN | IPv4 UDP | 1197 | qSuperLow | -
Did you set the maximum for the interface? HFSC supports sharing and the settings you give it are MINIMUMS.
-
Hi Harvy,
I did 1600Kbit/s on the WAN and 35000Kbit/s on the LAN
Does HFSC follow priority rules?
-
Hi Harvy,
I did 1600Kbit/s on the WAN and 35000Kbit/s on the LAN
Does HFSC follow priority rules?
No. That section in the HFSC GUI is non-functional.
The "priority" in HFSC is defined by the bitrates you assign to queues.
-
Hi Harvy,
I did 1600Kbit/s on the WAN and 35000Kbit/s on the LAN
Does HFSC follow priority rules?
No. That section in the HFSC GUI is non-functional.
The "priority" in HFSC is defined by the bitrates you assign to queues.
Ow right, wonder why pftop didnt display it haha
So have I got it setup to make gaming traffic top priory?
or is HFSC not what I'm looking for?
-
Hi Harvy,
I did 1600Kbit/s on the WAN and 35000Kbit/s on the LAN
Does HFSC follow priority rules?
No. That section in the HFSC GUI is non-functional.
The "priority" in HFSC is defined by the bitrates you assign to queues.
Ow right, wonder why pftop didnt display it haha
So have I got it setup to make gaming traffic top priory?
or is HFSC not what I'm looking for?
Do not use HFSC's m1 & d unless you fully understand what it is doing. I would also disable all scheduler options except "Codel Active Queue".
The other algorithms are easier to use but if you exclusively use link-share's (and maybe upper-limit's) m2, HFSC isn't too complex.
-
Do not use HFSC's m1 & d unless you fully understand what it is doing. I would also disable all scheduler options except "Codel Active Queue".
The other algorithms are easier to use but if you exclusively use link-share's (and maybe upper-limit's) m2, HFSC isn't too complex.
Yeah I understand what the limits do. Just not quite sure how it knows to put the ICMP and gaming ports first.
I shall disable all queues but "Codel Active Queue" then
-
Just not quite sure how it knows to put the ICMP and gaming ports first.
You use floating rules to MATCH the traffic into the queue you want it to be in. It's up to you to figure out how to determine one game from the next, ie. you have to figure out which ports a particular game uses and then make a firewall rule to handle that traffic.
-
@KOM:
Just not quite sure how it knows to put the ICMP and gaming ports first.
You use floating rules to MATCH the traffic into the queue you want it to be in. It's up to you to figure out how to determine one game from the next, ie. you have to figure out which ports a particular game uses and then make a firewall rule to handle that traffic.
Yeah I've done that, I meant how does it know that qGaming needs to go before qDefault.
I got my Floating rules set, for overwatch, ICMP, VPN ports etc
Does it just go, qGaming has a minimum bandwidth of x amount and lets it all through with out dropping packets?
-
Do not use HFSC's m1 & d unless you fully understand what it is doing. I would also disable all scheduler options except "Codel Active Queue".
The other algorithms are easier to use but if you exclusively use link-share's (and maybe upper-limit's) m2, HFSC isn't too complex.
Yeah I understand what the limits do. Just not quite sure how it knows to put the ICMP and gaming ports first.
I shall disable all queues but "Codel Active Queue" then
The first thing you need to stop thinking about is which packets go "first" if you want to do proper shaping. HFSC is about bandwidth shaping and latency isolation, but it does not guarantee anything about the order of packets.
-
Makes sense now. thanks :)
-
If you are using HFSC you can set a minimum bandwidth as well on the queue , that way those queues will alway have that bandwidth available to them versus a max and then a sharing amount.
I typically set qGames and aHTTP at 35% each with qGames getting half of that as minimum. That leaves 30% for qACK and qP2P (Default). Granted this is at LAN parties as well where I only really care about Gaming traffic.
I use alias's for the gaming ports as well.
