Re: [LARTC] exploring HTB

[Martin Devera <devik@cdi.cz>]

> 
> 1> Is "default" is must while attaching queue discipline HTB to device?

no it is optional.

> 	My observation for above question is, when I do following 4 command then I’
> m able to reach to all hosts on eth1. But if I remove "default 12" from
> second command then I cannot reach to hosts on eth1, but I can reach to the
> host on other device (eth0, eth2). This occurs after I create extra class to
> serve as the root (i.e. creating class having parent 1:1, 4th command)
> tc qdisc del dev eth1 root
> tc qdisc add dev eth1 root handle 1: htb default 12
> tc class add dev eth1 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps
> burst 2k
> tc class add dev eth1 parent 1:1 classid 1:11 htb rate 10kbps ceil 100kbps
> burst 2k
> tc class add dev eth1 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps
> burst 2k
> 
> 	Ya, this reachability can be restored only after delition of root class,
> i.e. classid 1:1. I'm taking this as a feature but is it a bug?

depends on filters you are using. Without "default" all unclassified
traffic is lost (like ARP packets) unless you have some catch-all
filter which cares about such traffic.
The bahaviour changed in htb2 patch - not even without default all
unclassified traffic goes into virtual X:0 class which is pass-thru
internal fifo IIRC.
It is funny that I can't remember how I implemented latest semantic here.
... well I just checked the source and I'm right with the fifo.

You can look at stats from tc -s class ... to see fate of your packets.

> 2> Manual states that "... ... ... Now we can optionally attach queuing
> disciplines to the leaf classes... ... ... tc qdisc add dev eth0 parent 1:10
> handle 20: pfifo limit 5... ... ...". If I not going to do that still I'm
> fine with my rule set, as written "optional". Then is there benefit or
> payoff against this leaf-class?

this general tc issue was replied by Stef to you :) (thanx Stef)

> 3> A Small but nice document about Cross device sharing on link
> http://luxik.cdi.cz/~devik/qos/htb/htbmeas1.htm. Can’t this limitation of
> slot be increased?

the slots was removed from latest code and link above is obsolete (where
you have found it ?) ;)
The slots concept was too much of hack and there was too many races
on SMP (unfixable ones). The IMQ device is superior for Cross device
sharing and it is a LOT simpler ;)
See http://luxik.cdi.cz/~devik/qos/

> 4> It would be nice if someone help me by providing statistics over number
> of queues and filter. What is maximum limit of these two for a PIII 700 with
> 256 MB RAM? How much maximum bandwidth can be shaped?

I've tried on my pII 375, I was able to shape 100Mbit with 5 classes (3
leaves). But both CBQ and HTB has O(N) worst case complexity where N is
no of classes. I just finished new HTB design (with the same interface
of course) and it should be faster in this way.
The I will do some serious testing on ratw vs. no of classes.

Just to note that speed depends ONLY on number of ACTIVE classes (active
flows). Those without data enqueued are idle and don't decrease
throughtput.
Also limiting is packet rate not byte rate .. The limit is somewhere
at 30000 packets per second for both CBQ and HTB with 5 classes which
is cca 500Mbit for 1.5k packets (on my PII).

devik

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/