And for those wondering why I''d care to have RED instead of basic SFQ (although GRED might handle this as I''d like it to), see: http://www.google.com/search?q=cache:3RbzYw9RPU4:www-users.cs.umn.edu/~mhasan/finalpres.ppt+gred+queue&hl=en Scroll down to about the 1/3 mark or search ''red vs. tail drop''. Its a converted powerpoint presentation (from: http://www-users.cs.umn.edu/~mhasan/finalpres.ppt) Remember that Google allows you to view PPT and PDFs as HTML as above so searches are more thorough now. -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/
On Fri, Dec 07, 2001 at 11:57:34AM -0500, Michael T. Babcock wrote:> And for those wondering why I''d care to have RED instead of basic > SFQ (although GRED might handle this as I''d like it to), see: > > http://www.google.com/search?q=cache:3RbzYw9RPU4:www-users.cs.umn.edu/~mhasan/finalpres.ppt+gred+queue&hl=en > > Scroll down to about the 1/3 mark or search ''red vs. tail drop''. Its > a converted powerpoint presentation (from: > http://www-users.cs.umn.edu/~mhasan/finalpres.ppt)Also, try a search on SFB (Blue queue). I started writing a kernel qdisc for SFB, but never finished, partly because it really needs to be integrated with a class based system to give the needed flexibility (i.e. if it isn''t you will have to choose between the two) and partly because figuring out how to correctly hook the ''busyness'' of the interface. A further problem is that Linux based shaper boxes are often not directly connected to the ''slow link'', but instead there is a separate router which is taking in a much faster interface, performing it''s own (often tail drop) queuing, and pushing out on the slow interface. This configuration is the biggest contributer to traffic control not behaving as expected.
On Fri, Dec 07, 2001 at 12:08:25PM -0500, Gregory Maxwell wrote: Greg, good to see that ou are still alive :-)> A further problem is that Linux based shaper boxes are often not directly > connected to the ''slow link'', but instead there is a separate router which is > taking in a much faster interface, performing it''s own (often tail drop) > queuing, and pushing out on the slow interface. This configuration is the > biggest contributer to traffic control not behaving as expected.You need to own the queue to shape it, yes, and in order to make this happen, your linux box must be the slowest device in the chain. This is why I am thinking of the ''stack'' qdisc which would work like this: ___ 10:___ / / \ \ / | | \ 10:1 10:2 10:3 10:4 <- <- <- Enqueue()s always happen at the highest class, 10:4 in this case, dequeue()s happen via 10:1, 10:2, 10:3 and 10:4. This would allow you to ''stack'' RED, SFQ and TBF, for example. Haven''t worked out how this would work in the kernel though. The question is if we should ''push'' or ''pull'' - should a dequeue first always try to dequeue 10:4 to 10:3, and then from 10:3 to 10:2 etc etc. What I really miss by the way is a way to poll devices for their queue length, so ''downstream'' devices would be able to own the queue so to speak. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services Trilab The Technology People Netherlabs BV / Rent-a-Nerd.nl - Nerd Available - ''SYN! .. SYN|ACK! .. ACK!'' - the mating call of the internet