From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E7D703B260; Mon, 2 May 2016 22:26:45 -0400 (EDT) Received: by mail-oi0-x233.google.com with SMTP id x201so8526479oif.3; Mon, 02 May 2016 19:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=+8uw14bnqgTlXB283Ah4chbf7/o/uqNd41oa7RS5Cno=; b=eqlPw036d1wMuWLD0tfN8+pkj7IccGLO8VyTbqbs3onPuhJNWHXwB7dZmBXIdP0juU IaOhTWLxqOREDFH4W8wDvSkniBfmkjzYKa5d+/J0YXk82VdxuwAGVUDzbQXS+bvSbaUn W9tp1YO2G5OUMgu0U9PFobXdMYCKz/RIi5wmD/PW3l2lUM5wjEExEve3XUc3nQAXsb3h h7Ed36igCGGaT46i4e7DW17j4HnL4KF+ouyidHMK5IN3+OFJosxCkdvqSPndzS/ZLQ6z TWdcm19+ySOwWslBqZuuFWVbenC+oFpy8qFuNF/4O7ZS1s2QF9tAKdNO1pJSKBoBbAke RkBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=+8uw14bnqgTlXB283Ah4chbf7/o/uqNd41oa7RS5Cno=; b=fGmtwjidZk0ZKdFe1yPnOafbT+K7jewbuNudsCvCYCfZ+FlyeJzEqZB+Z4G+Jem26X ACKCk3afpY1cMffOpAvM4ZZZPhPPst9aUyqHWEyWhcuZ5J14xoQiTcjx1MtSk3dFRT0Q ybe4U0c+WU9k90qTA4BX4RsQV2DnMGYT2LRwdG/BAKxUfFluCanyvjERq715gFXEbyvG kn8V0/yKVg+dgBqqs9okLPu2ZMld8Pn/90zLhPEuNWz1H/T8kwkVaOFaQOzuhCBDZqlD pfgVSh4fh+xw/WhoCbaJRbexxtJSnmXyRRrl1O671ybV+HdealQWGMLm4suPp40/3E0G ecrw== X-Gm-Message-State: AOPr4FV1qNMIYaFkuMkkCg2NnnhsosQrITuQfIiPGzY6TRfHdOcKWeYfAXHDIOcD060xRsj5aDFw/BKkkolymQ== MIME-Version: 1.0 X-Received: by 10.202.216.68 with SMTP id p65mr16718562oig.152.1462242405365; Mon, 02 May 2016 19:26:45 -0700 (PDT) Received: by 10.202.78.23 with HTTP; Mon, 2 May 2016 19:26:45 -0700 (PDT) In-Reply-To: <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> References: <1462125592.5535.194.camel@edumazet-glaptop3.roam.corp.google.com> <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> Date: Mon, 2 May 2016 19:26:45 -0700 Message-ID: From: Dave Taht To: Jonathan Morton Cc: Eric Dumazet , make-wifi-fast@lists.bufferbloat.net, "codel@lists.bufferbloat.net" , ath10k Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [Codel] fq_codel_drop vs a udp flood X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 02:26:46 -0000 On Sun, May 1, 2016 at 11:20 AM, Jonathan Morton wr= ote: > >> On 1 May, 2016, at 20:59, Eric Dumazet wrote: >> >> fq_codel_drop() could drop _all_ packets of the fat flow, instead of a >> single one. > > Unfortunately, that could have bad consequences if the =E2=80=9Cfat flow= =E2=80=9D happens to be a TCP in slow-start on a long-RTT path. Such a flo= w is responsive, but on an order-magnitude longer timescale than may have b= een configured as optimum. > > The real problem is that fq_codel_drop() performs the same (excessive) am= ount of work to cope with a single unresponsive flow as it would for a true= DDoS. Optimising the search function is sufficient. Don't think so. I did some tests today, (not the fq_codel batch drop patch yet) When hit with a 900mbit flood, cake shaping down to 250mbit, results in nearly 100% cpu use in the ksoftirq1 thread on the apu2, and 150mbits of actual throughput (as measured by iperf3, which is now a measurement I don't trust) cake *does* hold the packet count down a lot better than fq_codel does. fq_codel (pre eric's patch) basically goes to the configured limit and stays there. In both cases I will eventually get an error like this (in my babel routed environment) that suggests that we're also not delivering packets from other flows (arp?) with either fq_codel or cake in these extreme conditions. iperf3 -c 172.26.64.200 -u -b900Mbit -t 600 [ 4] 47.00-48.00 sec 107 MBytes 895 Mbits/sec 13659 iperf3: error - unable to write to stream socket: No route to host ... The results I get from iperf are a bit puzzling over the interval it samples at - this is from a 100Mbit test (downshifting from 900mbit) [ 15] 25.00-26.00 sec 152 KBytes 1.25 Mbits/sec 0.998 ms 29673/29692 (1e+02%) [ 15] 26.00-27.00 sec 232 KBytes 1.90 Mbits/sec 1.207 ms 10235/10264 (1e+02%) [ 15] 27.00-28.00 sec 72.0 KBytes 590 Kbits/sec 1.098 ms 19035/19044 (1e+02%) [ 15] 28.00-29.00 sec 0.00 Bytes 0.00 bits/sec 1.098 ms 0/0 (-nan%) [ 15] 29.00-30.00 sec 72.0 KBytes 590 Kbits/sec 1.044 ms 22468/22477 (1e+02%) [ 15] 30.00-31.00 sec 64.0 KBytes 524 Kbits/sec 1.060 ms 13078/13086 (1e+02%) [ 15] 31.00-32.00 sec 0.00 Bytes 0.00 bits/sec 1.060 ms 0/0 (-nan%) ^C[ 15] 32.00-32.66 sec 64.0 KBytes 797 Kbits/sec 1.050 ms 25420/25428 (1e+02%) Not that I care all that much about how iperf is intepreting it's drop rate (I guess pulling apart the actual caps is in order). As for cake struggling to cope: root@apu2:/home/d/git/tc-adv/tc# ./tc -s qdisc show dev enp2s0 qdisc cake 8018: root refcnt 9 bandwidth 100Mbit diffserv4 flows rtt 100.0m= s raw Sent 219736818 bytes 157121 pkt (dropped 989289, overlimits 1152272 requeu= es 0) backlog 449646b 319p requeues 0 memory used: 2658432b of 5000000b capacity estimate: 100Mbit Bulk Best Effort Video Voice thresh 100Mbit 93750Kbit 75Mbit 25Mbit target 5.0ms 5.0ms 5.0ms 5.0ms interval 100.0ms 100.0ms 100.0ms 100.0ms pk_delay 0us 5.2ms 92us 48us av_delay 0us 5.1ms 4us 2us sp_delay 0us 5.0ms 4us 2us pkts 0 1146649 31 49 bytes 0 1607004053 2258 8779 way_inds 0 0 0 0 way_miss 0 15 2 1 way_cols 0 0 0 0 drops 0 989289 0 0 marks 0 0 0 0 sp_flows 0 0 0 0 bk_flows 0 1 0 0 last_len 0 1514 66 138 max_len 0 1514 110 487 ... But I am very puzzled as to why flow isolation would fail in the face of this overload. > - Jonathan Morton > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org