*~ r a K u ~ * wrote:> I have a lot question about tc-command because now i''m doing
research to compare
> performance between HTB and HFSC
> so i''m doubt a lot thing and your reply are so very helpful to me
... My
> question is
>
> *In HTB tc command question*
> 1. I''m use opensource (Mastershaper) for help to config traffic
control
> but when i''m try to config HTB,
> I''m doubt about in each chain must identify fallback service level
> and If i''m don''t specify it,it will unable to contain
pipe.
> Every traffic and if traffic not matched in chain''s pipe can only
use the
> fallback service level
> (ps. Mastershaper represent interior class as pipe and leaf class as
chain)
>
> Is it only true definition in HTB tc command?? or it''s only a
creative function
> from developer??
Don''t know what you mean really - mastershaper is OK but if you want to
test HTB and HFSC you should do it by hand so you can play with
different HTB settings.
quantum/burst/cburst can affect things at low rates there is also a
compile time define that makes HTB more accurate - HYSTERESIS 0 is more
accurate than the default 1. HTB accuracy is limited by Hz setting aswell.
Testing on low bandwidth links shows HTB to be sensitive to how you set
things up. Trying to have a class for each user, with prio for
interactive within that doesn''t work well - your interactive needs to
be
top level prio 0. I haven''t tested doing per user within that.
At low rates I find hfsc is alot better, but then my tests may have been
flawed.
You won''t see any results from ping output when simulating a low rate
on
eth unless you make an artificial link with another queue. This can be
tricky - hfsc seems Ok - but it doesn''t add bitrate latency quite like
a
real link would. If you use hfsc to simulate a link then to be fair to
htb you need to choose packet sizes carefully, because htb uses rate
tables that are only right if (on eth) ip_len+14/8 is an integer. In
effect (on eth) this means setting mtu to 1498 and ping -s 54 rather
than default 56.
You could instead, just tcpdump on a remote box and look at time
deltas/packet lengths and deduce how much a real link would be backlogged.
>
> *In HFSC tc command question *
> after i read HFSC paper , i''m doubt in Service curve declaration
like this
> > | SC := [ [ m1 BPS ] [ d SEC ] m2 BPS
> > |
> > | m1 : slope of first segment -> umax
> > | d : x-coordinate of intersection -> dmax
> > | m2 : slope of second segment -> rate
You can specify curves two ways and you don''t need m1/umax or d/dmax
for
a linear "curve". Whether you say m1 as a bitrate or umax bytes for
packet length hfsc will convert to bitrate.
You need to think of the link you shape for as a linear curve and make
sure all your rates do not exceed that.
>
> 2. In all leaf class must specify rt (realtime service curve) ??? and Is it
> important to
> specify sc (Service curve) in all leaf class ?? and in all leaf class must
> specify link-sharing (ls) too??
I think you can have any type on leaf - inners can''t be rt, though you
can use sc rather than ls I suppose they are just ls. On a leaf sc is rt
+ ls, ie. it can borrow and is capped by the first ul above/on it, rt
alone will not get a share above its rate.
> because i think after read HFSC theory about by default All leaf
class(Service
> class)
> will use Link-sharing critirion for allocation bandwidth from Service curve
> (My assumtion think this calculation bandwidth is "m1" or
"umax" ->total bandwidth
> that can send at ceil rate??) and when total delay are exceed to
"demax" or "d"
> -> it mean
The way I see it may be wrong -
There is no ceil rate for rt as such , that''s for ls - it is up to you
to work out m1 and delay for every leaf (not sure if ls leaf matters but
I still did in my test, just to make the curves add up) so that you
don''t go over the link curve. On a slow link if you assume big packets
that makes for long delays. In practice it will be jitter - Patrick
wrote he may make hfsc even more non work conserving one day (IIRC).
Until then I don''t think it''s possible to get optimal
behaviour for prio
between rt classes. The original hfsc algorithym assumes some device
driver controls the queue - in practice that won''t happen without alot
of buffering to mess things up, the current hfsc rate limiting is good
but doesn''t quite simulate the perfect (non existant) driver that asks
for a packet at a time.
> it''s time for HFSC to manage QoS to guarantee bandwidth and delay
> in each leaf class by use Real-time Criterion so bandwidth rate will change
to "m2"
> or bandwidth rate that guarantee QoS in eache leaf class
> Is it true??? i fear may be misunderstand in HFSC theory,
> example in my test lab ,i have leaf class 3 type such real-time ,data
,default
> Can i specify
> - real-time leaf class -> rt (for guatantee delay and bw) ,ls (by
default when
> not exceed max delay)
It will get (max) delay according d upto m2 bandwidth if it needs to
borrow more from ls those packets get no delay guarantee.
> - data lead class -> ls (by default and not delay sensitive so delay
are not
> important)
ls bandwidth is shared between siblings according to the relation of
their rates. An rt class can be ls aswell - that''s what sc is.
>
> 3. I''m doubt in How to declaration ls, and ul about .. in thoery
it a type of
> service curve that not
> relative with real-criterion, so Delay may be not important for consider
????
> Is it true when declaration, parameter in each service curve may be link
this?
> ls [ umax BPS, rate BPS]
> ul [ umax BPS, rate BPS]
> and
> Is it important to declaration all of three parameter (umax,demax,rate) If
three
> parameter
> are important to setting traffic control????
Not sure really - it seemes to make sense to make sibling curves add up
even if ls, so when I tested I made an ls m1 0 d Xms rate Xkbit because
it had as a sibling, an rt that had m1 = parent rate for Xms.
>
> 3. I''m try to search HFSC command example, it have a lot case but
i''m doubt in
> service curve (sc)
> declaration sometime declaration in root class, interior class, in leaf
class
> so I''m not sure to understand about ls ->calculate bandwidth
for interior
> class,root class and
> rt -> calculate bandwidth for leaf class and what about service
curve(sc)???
> it''s specify only in root class???
I guess on leaf it means rt + ls, as a parent just ls.
>
> 4. Is it true??
> In root class, or interior class will doing with only Link-sharing
criterion, so
> can specify declaration
> only link-sharing ->ls(umax, dmax, rate) and Upperlimit
> ->ls(umanx,dmax,rate) it''s not important
> to declaration real-time curve (rt) because in HFSC theory will use
real-time
> criterion only Leaf class
All my inners are linear only.
>
> 5. In HFSC, upper limit are bandwidth rate that guarantee maximum bandwidth
rate in
> each class as ceil in HTB???
>
> 6. I''m doubt about priority in HFSC, in HFSC paper telling about
in support
> priority
> but in HFSC tc-command it not specify priority in each class,
> So In HFSC how to manage priority class link HTB????
In theory for rt priority is from the way you make the curves - in
practice see above. For ls share of bandwidth is worked out between
siblings at each level using their rates. If you give bulk class x:y
rate 5 kbit and bulk class x:z 1kbit bandwidth will share 5:1.
Andy.