Thanks very much, Devik and Andy, I had seminar today and I think it has some success, and (for now?) I do not feel like having unanswered questions. Dmitry On Sunday 13 June 2004 21:41, Martin Devera <devik@xxxxxx> wrote: > > 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/ _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
