Re: [LARTC] HTB and HFSC,declaration tc command question
*~ 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. - da
[LARTC] HTB and HFSC,declaration tc command question
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 question1. 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?? 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 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?? 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 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 ,defaultCan i specify - real-time leaf class -> rt (for guatantee delay and bw) ,ls (by default when not exceed max delay) - data lead class -> ls (by default and not delay sensitive so delay are not important) 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 parameterare important to setting traffic control 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 classso 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??? 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 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 Thank you for all reply, it's so very helpful to me alot.which all will suggest or advise me about in something i'm misunderstand raku Express yourself instantly with MSN Messenger! MSN Messenger Download today it's FREE! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
