Hi Alejandro >Yes, I know. I was trying to ask why to attach htb qdisc instead >of htb class to the root. >In fact, I really don't understand what means "htb qdisc" since >I just know htb as a classfull tc node, and (I guess) qdisc are >classless tc nodes (am I wrong?) mhmh, I think you are a little confused here. I would recommend reading both the document on HTB pointed out by Andy and the general LARTC howto. Traffic control defines different object types: - qdisc (queueing disciplines: how packets enqueued/dequeued) HTB is one kind of qdisc. - classes (a mechanims for organizing packets inside qdiscs) Only classfull qdiscs allow you to create classes ... HTB is a classful qdisc. - classifiers (used to define filters to map traffic to classes) - classifier extensions: legacy policers and actions. (one of the action types is "police", which replaces the legacy policers) - ... >> You can only create HTB classes under a HTB qdisc, and you can only >> create CBQ classes under a CBQ class. However you can attach any >> qdisc to a given class. >> What is exactly that you find strange? >Well, I thought I just could attach qdisc nodes to class nodes, not >viceversa, and that's the case when attaching htb qdisc to the root >and then, declaring a child of the root as a htb class, doesn't it? You can create classes inside classfull qdiscs. The classes you create are of the same type as the parent qdisc, which explains why you create HTB classes inside HTB qdiscs. You can attach a qdisc to class (if you want to replace the default pFIFO). Well, you can also attach a qdisc directly to another qdisc if you like, but it makes sense only in few cases. >> The default pFIFO qdisc that get attached to the classes are not >> shown by the above command. >...and which is the command that will show them?? There is no command that does that. If you really want to see them, you can explicitly attach a pFIFO queue to the classes. >> I would say that that is a misconfiguration. >> Neither the tc command nor the kernel gives you any warning. >> You could implement it as part of your project ... :) >I agree with you: it is a wrong configuration, and I need to deal with it as >part of my project. But I am able to run those lines, and I will get a >behavior, and I want to know if there is some kind of logic around it: ...how >it works?? There are lots of misconfigurations that neither the tc command nor the kernel detects or cares about. The one you pointed out is just one of them. >> You are right. Class 1:20 does not limit the class 1:21's rate to >> 1kbit. >> This is due to the way the kernel schedules the HTB classes. >Could you (please) tell me more about how the kernel do this? You can refer to the document pointed out by Andy: http://luxik.cdi.cz/~devik/qos/htb/ Devik has documented HTB fairly well. This is a simplified model: for each level L (starting from the leafs) for each priority P (starting from the highest priority) for each class C with priority P at level L serve class C Regards /Christian [http://benve.info] _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
