On Wed, 13 Mar 2013, Fred Baker (fred) wrote:
That depends on how FQ is implemented. The implementation I did in 1994 probably would have been high overhead. It has been minted by others, and I believe rewritten to be a calendar queue implementation. For that, I would not expect it was that much higher. I'll go take a look, though.
To be concrete, turning on fair-queue (and some other stuff to assure bw for certain tcp/port combinations) on a Cisco 7200 style device seems to give 2-3x CPU usage for the same traffic. This is with just 30-100 flows. This is in latest code available (15.2).
So since in my market we have gig speeds (we have low cost residential CPEs capable of moving ~600 megabits/s in a single tcp session), CPU impact of these queueing mechanisms is important.
And yes, I feel doing AQM at 100/100 speeds is still important, but here the limiting factor for speed might actually be the CPU of the CPE, so the queueing mechanism should preferrably be able to prioritize and gracefully handle the case where the links are not full but instead the CPE CPU is insufficient and that's what causing congestion/drops.
-- Mikael Abrahamsson email: swm...@swm.pp.se
