[Make-wifi-fast] [Codel] fq_codel_drop vs a udp flood
dave.taht at gmail.com
Thu May 5 15:41:22 EDT 2016
On Thu, May 5, 2016 at 12:23 PM, Eric Dumazet <eric.dumazet at gmail.com> wrote:
> On Thu, 2016-05-05 at 19:25 +0300, Roman Yeryomin wrote:
>> On 5 May 2016 at 19:12, Eric Dumazet <eric.dumazet at gmail.com> wrote:
>> > On Thu, 2016-05-05 at 17:53 +0300, Roman Yeryomin wrote:
>> >> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
>> >> quantum 1514 target 5.0ms interval 100.0ms ecn
>> >> Sent 12306 bytes 128 pkt (dropped 0, overlimits 0 requeues 0)
>> >> backlog 0b 0p requeues 0
>> >> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>> >> new_flows_len 0 old_flows_len 0
>> > Limit of 1024 packets and 1024 flows is not wise I think.
>> > (If all buckets are in use, each bucket has a virtual queue of 1 packet,
>> > which is almost the same than having no queue at all)
>> > I suggest to have at least 8 packets per bucket, to let Codel have a
>> > chance to trigger.
>> > So you could either reduce number of buckets to 128 (if memory is
>> > tight), or increase limit to 8192.
>> Will try, but what I've posted is default, I didn't change/configure that.
> fq_codel has a default of 10240 packets and 1024 buckets.
> If someone changed that in the linux variant you use, he probably should
> explain the rationale.
I guess that would be me.
Openwrt has long shipped with the fq_codel default outer queue limit
being lower than the default (e.g. 1024). Think: itty bitty 32MB
routers. 10240 packets can = boom, particuarly while there were 4
fq_codel instances per wifi interface (and people in the habit of
creating 2 or more wifi interfaces).
back then: I viewed the probability of flooding all 1024 queues as low
and thus the queue depth would be sufficient for any given set of
flows to do well. (and long ago we gave codel a probability of working
on all queues). And did not do enough udp flood testing. :(
Totally not the right answer, I know. And the problem is even worse
now, with 128MB arm boxes like the armada 385 (linksys 1200ac, turris
omnia) using software GRO to be bulking up 64k packets at gigE and
trying to ship them to an isp at 5mbit, or over wifi at some rate
lower than that.
cake switched to byte, rather than packet, accounting, for these
reasons, and we're still trying various methods to peel apart
superpackets at some load level efficiently.
And routers are tending to ship with a lot more memory these days,
overall. We are discussing changing the sqm system to dynamically size
the packet limit by overall memory limits here, for example:
AND: As sorta now implemented in the mac80211 fq_codel code, it's per
radio, rather than per interface (or was, when I last thought about
it), which is *vastly saner* than four fq_codel instances for each
Let's go make home routers and wifi faster! With better software!
More information about the Make-wifi-fast