On Wed, 13 Mar 2013, Andrew McGregor wrote:
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).
I'll have to look into what devices we're using and what CPUs they're using. The WNDR3800 seems to be a fairly high end device when I look at the price point.
However, the other part of your reply sounds hopeful. I read draft-nichols-tsvwg-codel-01 and I now realise that yes, it shouldn't be too cpu intensive as the hashing into bins sounds efficient on a per-packet level.
Would having multiple bin "trees" increase CPU usage a lot? I'm thinking of the use case where there are 10 computers in the home, of which one is doing 100 upload TCP sessions (bittorrent). If there was some mechanism that could identify a source IP address that caused most of the congestion and put them in a separate bin "tree" (basically each source IP would get its own set of bins, up to a maximum of perhaps 16 trees) and then these sets of bins would be emptied in a round-robin fashion (MDRR perhaps?). Or perhaps there would just be a "high volume speaker" tree and a "low volume speaker" tree, and it would be enough to just MDRR between these two trees. I realise we're now into "flow" territory which is exactly what Codel doesn't need to bother with currently, but just checking...
I saw in ICCRG that some testing was done with LEDBAT which I would imagine would help for the bittorrent case, but what about trying to achieve some of that without needing LEDBAT by using the above technique?
-- Mikael Abrahamsson email: [email protected]
