>=20 > 1> Is "default" is must while attaching queue discipline HTB to device? no it is optional. > =09My observation for above question is, when I do following 4 command th= en I=92 > 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 t= he > 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 100kbp= s > burst 2k > tc class add dev eth1 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbp= s > burst 2k >=20 > =09Ya, this reachability can be restored only after delition of root clas= s, > 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. =2E.. 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=92t 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 numbe= r > of queues and filter. What is maximum limit of these two for a PIII 700 w= ith > 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
