G
@kambeeng:
Maaf bro lom sempat ana terjemaahkan ;D semoga bermanfaat
Notes on HFSC and its syntax within PF+ALTQ
* realtime
1. method: guaranteed rate
2. designed for traffic which has precise latency or throughput requirements
3. all realtime values take from total of root queue. (no inhereting from parent queues)
4. maximum value is 75% of total bandwidth in root queue
* linkshare
1. method: best-effort dequeuing (inactive if there are no queued packets waiting)
2. works with the bandwidth left over after realtime rates have been met.
3. all linkshare values take from total of parent queue
4. maximum bandwidth is 100%
* bandwidth
1.
2. pf-specific variable, redundant for linkshare
3. recommend matching this value to your linkshare value
4. if you use this value but omit linkshare, it might use it as the linkshare value (I have not tested this)
5. if you omit this value PF will complain of syntax errors
( explaination of this redundancy is quoted below from the mailing list)
"q: Who needs two config parameters to control one variable"?
"a: HFSC has 2 distinct bandwidth parameters; one for the realtime scheduling and the other for the linksharing scheduling. So, the bandwidth parameter is redundant but the current implementation is less surprising for those who don't understand hfsc. (I agree that it's confusing for those who knows hfsc, though.)"
* qlimit
1. the amount of packets that will be queued before PF begins to drop packets.
2. default is 50
3. recommend higher values for traffic in which reliability is more important than delay
4. for p2p traffic, best results are achieved through trial and error tweaking of this value. You want packets to drop when other queues are competing bandwidth, as this allows for quicker response for the non-p2p queues, but do not want to drop packets when this queue is the only bandwidth consumer.
* priority
1. queues with a higher priority are preferred in the case of overload. (ie: this affects the order in which packets are dequeued, when packets are awaiting dequeue)
Recommedations
* realtime
1. use this to specify the minimum bandwidth a queue should be guaranteed in a worst case scenario in order to function reasonably.
* linkshare
1. use this to specify the amount of bandwidth a queue will receive when attempting to dequeue packets. (I believe this is relative to what bandwidth is available)
* upperlimit
1. use this to specify that maximum bandwidth a queue will receive. It will never go beyond this.
(note: upperlimit is not part of the original HFSC and I do not recommend using it except for your root queue)
Notes
* Assignments of linkshare and realtime are cumulative. Any traffic which exceeds the assignedrealtime threshhold will be dequeued using the assigned linkshare values.
Tips/Ideas
* Assigning a zero linkshare value
1. You can assign a linkshare of 0Kb and still assign realtime value.
2. If traffic in queue exceeds realtime value no linkshare would be used to dequeue those backlogged packets
* Reducing or increasing bandwidth values over time
Realtime and Linkshare can be adjusted automaticly based on a timed delay.
Reducing rate over time
example: hfsc(realtime (192Kb 5000 64Kb))
1. 192Kbit of bandwidth is guaranteed for the first 5000ms
2. After 5000ms the throughput guarantee is dropped to 64Kbit
3. When using this method, the first and second bandwidth value can be anything you want, keeping in mind that the first value must be higher than the second
Increasing rate over time
example: hfsc(realtime (0Kb 300 128Kb))
1. 0Kbit of bandwidth guaranteed for the first 300ms
2. After 300ms 128Kbit of bandwidth is provided
3. When using this method, the first value must be 0.
Examples
1. I like to assign an upperlimit to match the bandwidth/linkshare value.
2. This ensures hfsc is receiving exactly as much bandwidth as you are telling it to work with.
altq on $ext_if bandwidth 1216Kb hfsc(linkshare 1216Kb upperlimit 1216Kb) queue { o_def, o_intr, o_crit }
1. Here i've given 640Kb of linkshare to the o_def queue.
2. No traffic is being assigned to this queue, but child queues under it will take from this value.
3. Priority is lower than the other queues because this traffic is not critical.
queue o_def bandwidth 640Kb priority 7 hfsc(linkshare 640Kb) { o_brst, o_other, o_tput }
1. Here i've given 32Kb of realtime, to ensure a smooth flow at low speed.
2. I've also given 128Kb of linkshare, so that any queues packets can be dequeued quickly.
queue o_other bandwidth 128Kb qlimit 50 hfsc(realtime 32Kb linkshare 128Kb default)
1. Same as above.
queue o_brst bandwidth 128Kb qlimit 50 hfsc(realtime 32Kb linkshare 128Kb)
1. Here i've given 384Kb of linkshare to distribute between the two child queues.
2. No realtime is given here because bulk traffic is the least important of all.
3. (ie: p2p applications and file transfers. traffic which is know to cause the slowdowns you wanted to use ALTQ for in the first place).
queue o_tput bandwidth 384Kb qlimit 30 hfsc(linkshare 384Kb) { o_tp1, o_tp2 }
1. Here I assign two subqueues for bulk traffic.
2. Each one is given 192Kb of linkshare.
3. If bulk in each of these queues is fighting over bandwidth, they will both get 50% of the total available to them.
queue o_tp1 bandwidth 192Kb qlimit 30 hfsc(linkshare 192Kb)
queue o_tp2 bandwidth 192Kb qlimit 30 hfsc(linkshare 192Kb)
1. Here i've given 384Kb of linkshare to the o_intr queue.
2. No traffic is being assigned to this queue, but child queues under it will take from this value
3. Priority is higher than o_def because this traffic require low delays and steady throughput (games, ssh, im, vpn, etc).
queue o_intr bandwidth 384Kb priority 8 hfsc(linkshare 384Kb) { o_gme, o_dly, o_vpn }
1. Here I give realtime of 256Kb and linkshare of 128Kb.
2. This ensures my gaming queue receives a guaranteed rate of 256Kbit.
3. The linkshare value is to dequeue anything which exceeds the realtime value.
queue o_gme bandwidth 128Kb qlimit 50 hfsc(realtime 256Kb linkshare 128Kb)
1. Essentialy the same as above but different values.
queue o_dly bandwidth 128Kb qlimit 100 hfsc(realtime 192Kb linkshare 128Kb)
1. Essentialy the same as above but different values.
queue o_vpn bandwidth 128Kb qlimit 150 hfsc(realtime 192Kb linkshare 128Kb)
1. Here i've given 192Kb of linkshare to the o_crit queue.
2. No traffic is being assigned to this queue, but child queues under it will take from this value
3. Priority is higher than o_def and o_intr because this traffic requires low delays and steady throughput. (dns, icmp, voip, etc)
queue o_crit bandwidth 192Kb priority 9 hfsc(linkshare 192Kb) { o_voip, o_ctl, o_ack }
1. Here I've given a guarantee of 120Kb with my realtime value.
2. Notice I've given 0kb of linkshare because this traffic will never exceed 120Kbit/s and there is no concern about dequeuing because of this.
3. I also use a qlimit of 500 to ensure no packets are ever dropped in this queue.
queue o_voip bandwidth 0Kb qlimit 500 hfsc(realtime 120Kb)
1. Here i've given a realtime of 48Kb to ensure smooth flow of dns and icmp traffic.
2. I've given 64Kb of linkshare to ensure any overflow is dequeued quickly.
queue o_ctl bandwidth 64Kb qlimit 150 hfsc(realtime 48Kb linkshare 64Kb)
1. Here i've given a realtime of 92Kb to ensure my ack packets are always flowing quickly.
2. I have allocated 128Kb of linkshare to ensure any overflow, no mater how unlikely, is dequeued quickly.
queue o_ack bandwidth 128Kb qlimit 500 hfsc(realtime 92Kb linkshare 128Kb)
?
Kalo kita menggunakankan internet sebagai fokus utamnya, maka setting-an diatas.. akan mengakibatkan overlimit di koneksi internya.. Oleh karena itu perlu disesuaikan lagi dengan fokus utama company yg kita jalankan. :)