At Wed, 18 Jun 2025 15:11:30 +0000, Emmanuel Nyarko <emmankoko519%gmail.com@localhost> wrote: Subject: ALTQ modifications proposal > > The previous disciplines are not well maintained and adding > another discipline makes it worse(maintainability). I haven't actually touched any of this code (just used it) so I have questions. :-) What does it mean for the code for a queueing discipline to be "not well maintained"? What kind of regular maintenance does such code actually require? I would expect that if the code for a queueing discipline is working well with no apparent bugs, and so long as the framework it fits into is stable, then no maintenance at all would ever be necessary. I would also expect that most changes to the framework should be easy to do without having any specific knowledge about the internals of the code for the various disciplines. That was the point of ALTQ in the first place I think. As an aside I would like to mention that back when I used ALTQ (with IPFILTER), I only found HFSC to be useful for my connection at the time (which was asymmetric in terms of its up/down bandwidth). I'm pretty sure that was well before I had ever heard the term "bufferbloat". I had tried CBQ (as I was trying to shape traffic based on its "class"), but CBQ caused bizarre fluctuations in delay and caused major problems with VoIP traffic. One other (somewhat minor) concern I have is that whatever traffic shaping mechanism is there to continue to be usable with IPFILTER, at least so long as IPFILTER remains integrated in NetBSD and/or until NPF is on par with IPFILTER in terms of the features I've come to love and use in IPFILTER. :-) -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpI_IdxoYKfk.pgp
Description: OpenPGP Digital Signature