Re: [tsvwg] New Version Notification for draft-baker-tsvwg-aqm-recommendation-00.txt

[Andrew McGregor <[e-mail]>]

A Netgear WNDR3800 (680MHz MIPS) can handle fq_codel on two flat out
802.11n interfaces at the same time and still be very lightly loaded.  CPU
is not a problem because fq_codel is a tiny fraction of the usage of the
firewall, connection tracking and 802.11 AP code, all of which are
necessary (in IPv4 the NAT also uses more CPU than fq_codel).



On Wed, Mar 13, 2013 at 11:09 PM, Mikael Abrahamsson <[e-mail]>wrote:

> 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: [e-mail]
>