[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lartc
Subject:    Re: [LARTC] HTB and HFSC,declaration tc command question
From:       Andy Furniss <lists () andyfurniss ! entadsl ! com>
Date:       2006-09-26 22:23:32
Message-ID: 4519A864.7080802 () andyfurniss ! entadsl ! com
[Download RAW message or body]

*~ 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.




_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[prev in list] [next in list] [prev in thread] [next in thread]