>>>>> "i" == irix <irix%ukr.net@localhost> writes:
i> From pf/altq was removed most of the functional altqd, like
i> CDNR (in kernel added, but in pf not), shaping algoritms like
i> Jobs and Blue and many other.
Are you sure you want it? I think HFSC is probably a superset of
those in terms of what it can accomplish.
If you want to actually try all those old algorithms from 2000, maybe
they would be less bitrotted in the network simulator (ns)?
http://nsnam.isi.edu/nsnam/index.php/User_Information
If you look in CVS, you can see ALTQ has not gotten any love since a
year or two after the algorithms in it were first invented. I do use
it myself, but wouldn't suggest it to anyone trying to get work done.
The ALTQ idea, AIUI, was a proof of concept that we can do QoS on
full-duplex Ethernet, with the idea the best ALTQ algorithms would
then get pushed into the ASIC and the NIC driver where they could
perform well. But now we understand Ethernet QoS will not be
implemented that way because electrical engineers are just too dumb to
implement something like HFSC in an ASIC. Even WRED is really pushing
the envelope for them, and going further than that is a solid brick
wall, so there is no point in deciding which algorithm is the most
scalable/implementABLE and featureful because we hit the limit of
their competence almost before we began. so...for research the ns
might actually be more realistic even though it's a
``simulator''---the results ought to be closer to what a system worth
building would deliver than ALTQ would be.
Linux queueing took a different approach from ALTQ: they support silly
things like scheduling on ingress and in tunnels that ALTQ
deliberately doesn't (since it's pretending to be NIC QoS), but these
things are not so silly when you look at the ways Linux/BSD QoS
actually get used prescheduling T1's or DSL's or ASIC-QoS-provided
dumb-CIR channels.
Attachment:
pgpqYbNuZmmYS.pgp
Description: PGP signature