> 1. In order of priority, we satisfy all leaf classes' rates (while the class > is ?green?) > 2. When the leaf classes' rate is reached (all the leaf classes are ?yellow?), > borrow the unused speed from parent classes if they have something to give > (if they are not ?red?). In this case, each leaf class is equal to others > until their ceil is met or until they will have no parent to borrow from... > Or maybe their level matters? In both cases DRR is used to cycle classes to dequeue - this gives us fairness (weighted by "quantums"). > I also think that: > 1. Until all leaf classes' rate is met we even do not check anything else > (including ceil of parent classes) correct > 2. the root queue is unlimited feed for the classes which are attached to it > directly yes > One think I do not understand neither for SFQ nor for HTB (please explain for > both) - how can we maintain fairness in case of differently-sizes packets. As > I understand, one packet is atomic unit, and interface is requesting not more > and not less than one packet. Now given a quantum for each leaf class in HTB > or the same for SQF (are they different in this process?) of 1500 bytes - do > they wait for more packets from one subclass (asking it once again in the > next turn, of course, if they have nothing to send, we switch to the > next...)? And if one subclass is providing 1500 packets in each turn, and > another subclass is providing 800-byte packets - will they be equal on the > amount of traffic they are allowed to send in case the real channel is > smaller than the sum of their effective ceil values? both SFQ and HTB (and CBQ) uses DRR which uses BYTES as count not packets. Look into literature for "leaky bucket" description. To answer your last mail, cannonical HTB theory (v.3 = latest one) is: http://luxik.cdi.cz/~devik/qos/htb/manual/theory.htm. It is up to date - mainly because algorithm is the same since 2002. > (I am preparing for a seminar in which I will tell people how it works, so I > need to know this perfectly :))) ) Hmm I have talk at SUCON (http://www.suug.ch/sucon/04/speakers.html#7) so that I'll need to refresh it too :) devik _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
