Additions:
root (4Mbps)
|
+---------------+---------------+
| | |
A (1.5Mbps) B (1.5Mbps) C (1Mbps)
| | |
+---+---+ +---+---+ +---+---+
| | | | | |
video music http game voice ssh
(1Mbps) (500kbps) (1Mbps)(500Kbps)(500Kbps) (500Kbps)
|
+---------------+---------------+
| | |
A (1.5Mbps) B (1.5Mbps) C (1Mbps)
| | |
+---+---+ +---+---+ +---+---+
| | | | | |
video music http game voice ssh
(1Mbps) (500kbps) (1Mbps)(500Kbps)(500Kbps) (500Kbps)
Deletions:
|
+---------------+---------------+
| | |
A (1.5Mbps) B (1.5Mbps) C (1Mbps)
| | |
+---+---+ +---+---+ +---+---+
| | | | | |
video music http game voice ssh
(1Mbps) (500kbps) (1Mbps)(500Kbps)(500Kbps) (500Kbps)
Additions:
* if you DO not specify "linkshare", you should specify bandwidth.
* HFSC isn't documented real well, but the bandwidth option is used if
"linkshare" m2 parameter is not specified. The curve is used as a "weight" for bandwidth
distribute available bandwidth equally among those waiting it.
* 'realtime' is the maximum guarantee; its m1 parameter will always be satisfied in the
timeframe specified by d and m2 is the maximum that this discipline will allow to be used,
'linkshare' is for sharing the remaining bandwidth, after all realtime' guarantees have been taken care of.
pf also has 'upperlimit' for a hard limit. So a queue will get "bandwidth = 'realtime'
than 'linkshare', if it qualifies for it, in the bounds specified by 'upperlimit'.
* 'upperlimit' m1 parameter can even be used as limiting the bursting option.
It means that in the timeframe(d) you will not get more than packet size(m1) service.
* HFSC isn't documented real well, but the bandwidth option is used if
"linkshare" m2 parameter is not specified. The curve is used as a "weight" for bandwidth
distribute available bandwidth equally among those waiting it.
* 'realtime' is the maximum guarantee; its m1 parameter will always be satisfied in the
timeframe specified by d and m2 is the maximum that this discipline will allow to be used,
'linkshare' is for sharing the remaining bandwidth, after all realtime' guarantees have been taken care of.
pf also has 'upperlimit' for a hard limit. So a queue will get "bandwidth = 'realtime'
than 'linkshare', if it qualifies for it, in the bounds specified by 'upperlimit'.
* 'upperlimit' m1 parameter can even be used as limiting the bursting option.
It means that in the timeframe(d) you will not get more than packet size(m1) service.
Deletions:
* Setting the bandwidth on each queue to 25% should do that. HFSC isn't
documented real well, but the bandwidth option is used if
"linkshare" m2 parameter is not specified. That curve is used as a "weight" for bandwidth
distribute available bandwidth equally among those wanting it.
'realtime' is the maximum guarantee; it will always be satisfied, if you specify parameter m1 greater than m2.
'linkshare' is for sharing the remaining bandwidth, after all realtime' guarantees have been taken care of.
pf also has 'upperlimit' for a hard limit. So a queue will get "bandwidth =
realtime <= (linkshare) <= upperlimit". Or should, anyway :)
* 'upperlimit' m1 parameter can even be used as bursting option or minimum delay guarantee.
Revision [234]
Edited on 2008-01-24 23:59:11 by ErmalLuci [Correct the first part of these notes. The other part needs to be checked.]Additions:
* in hfsc, "realtime" is the scheduler used to guarantee upper bound delay
for a class it is valid only for child queues. "Linkshare" shares the bandwidth
between classes if available, and a hard limit for a "linkshare" specification
can be set by "upperlimit".
* if you will not specify "linkshare", you should specify bandwidth
documented real well, but the bandwidth option is used if
"linkshare" m2 parameter is not specified. That curve is used as a "weight" for bandwidth
'realtime' is the maximum guarantee; it will always be satisfied, if you specify parameter m1 greater than m2.
'linkshare' is for sharing the remaining bandwidth, after all realtime' guarantees have been taken care of.
pf also has 'upperlimit' for a hard limit. So a queue will get "bandwidth =
realtime <= (linkshare) <= upperlimit". Or should, anyway :)
* 'upperlimit' m1 parameter can even be used as bursting option or minimum delay guarantee.
for a class it is valid only for child queues. "Linkshare" shares the bandwidth
between classes if available, and a hard limit for a "linkshare" specification
can be set by "upperlimit".
* if you will not specify "linkshare", you should specify bandwidth
documented real well, but the bandwidth option is used if
"linkshare" m2 parameter is not specified. That curve is used as a "weight" for bandwidth
'realtime' is the maximum guarantee; it will always be satisfied, if you specify parameter m1 greater than m2.
'linkshare' is for sharing the remaining bandwidth, after all realtime' guarantees have been taken care of.
pf also has 'upperlimit' for a hard limit. So a queue will get "bandwidth =
realtime <= (linkshare) <= upperlimit". Or should, anyway :)
* 'upperlimit' m1 parameter can even be used as bursting option or minimum delay guarantee.
Deletions:
for the class, plus some bandwidth borrowed by "linkshare" from
parent if available, and hard limited by "upperlimit".
* if link_share is not specified, use bandwidth
documented real well, but the bandwidth option is used to set the
linkshare curve. That curve is used as a "weight" for bandwidth
'realtime' is the minimum guarantee; it will always be satisfied.
'linkshare' is for sharing the remaining bandwidth, after all
'realtime' guarantees have been taken care of. pf also has
'upperlimit' for a hard limit. So a queue will get "bandwidth =
realtime <= (excess weighted by linkshare) <= upperlimit". Or should,
anyway :)
