From: Dave Taht <dave.taht@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: make-wifi-fast@lists.bufferbloat.net,
"codel@lists.bufferbloat.net" <codel@lists.bufferbloat.net>,
ath10k <ath10k@lists.infradead.org>,
Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [Codel] fq_codel_drop vs a udp flood
Date: Mon, 2 May 2016 22:21:34 -0700 [thread overview]
Message-ID: <CAA93jw5NwBMzNrm6S2wPnx4yLTYq1k_J-cJ_Bi73p_uD_uo1xw@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw6WKyWmgzni1Tn0oQfJyN7hss++MKLkJ8+3sRcVLu7krg@mail.gmail.com>
On Mon, May 2, 2016 at 7:26 PM, Dave Taht <dave.taht@gmail.com> wrote:
> On Sun, May 1, 2016 at 11:20 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>>
>>> On 1 May, 2016, at 20:59, Eric Dumazet <eric.dumazet@gmail.com> 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 “fat flow” happens to be a TCP in slow-start on a long-RTT path. Such a flow is responsive, but on an order-magnitude longer timescale than may have been configured as optimum.
>>
>> The real problem is that fq_codel_drop() performs the same (excessive) amount 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%)
OK, the above weirdness in calculating a "rate" is due to me sending
8k fragmented packets.
-l1470 fixed that.
> 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.0ms raw
> Sent 219736818 bytes 157121 pkt (dropped 989289, overlimits 1152272 requeues 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.
And to simplify matters I got rid of the advanced qdiscs entirely,
switched back to htb+pfifo and get the same ultimate result of the
test aborting...
Joy.
OK,
ethtool -s enp2s0 advertise 0x008 # 100mbit
Feeding packets in at 900mbit into a 1000 packet fifo queue at 100Mbit
is predictably horriffic... other flows get starved entirely, you
can't even type on the thing, and still eventually
[ 28] 28.00-29.00 sec 11.4 MBytes 95.7 Mbits/sec 0.120 ms
72598/80726 (90%)
[ 28] 29.00-30.00 sec 11.4 MBytes 95.7 Mbits/sec 0.119 ms
46187/54314 (85%)
[ 28] 189.00-190.00 sec 8.73 MBytes 73.2 Mbits/sec 0.162 ms
55276/61493 (90%)
[ 28] 190.00-191.00 sec 0.00 Bytes 0.00 bits/sec 0.162 ms 0/0 (-nan%)
vs:
[ 4] 188.00-189.00 sec 105 MBytes 879 Mbits/sec 74614
iperf3: error - unable to write to stream socket: No route to host
Yea! More people should do that to themselves. System is bloody
useless with a 1000 packet full queue and way more useful with
fq_codel in this scenario...
but still this ping should be surviving with fq_codel going and one
full rate udp flood, if it wasn't for all the cpu being used up
throwing away packets. I think.
64 bytes from 172.26.64.200: icmp_seq=50 ttl=63 time=6.92 ms
64 bytes from 172.26.64.200: icmp_seq=52 ttl=63 time=7.15 ms
64 bytes from 172.26.64.200: icmp_seq=53 ttl=63 time=7.11 ms
64 bytes from 172.26.64.200: icmp_seq=55 ttl=63 time=6.68 ms
ping: sendmsg: No route to host
ping: sendmsg: No route to host
ping: sendmsg: No route to host
...
OK, tomorrow, eric's new patch! A new, brighter day now that I've
burned this one melting 3 boxes into the ground. and perf.
--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2016-05-03 5:21 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-01 3:41 fq_codel_drop vs a udp flood Dave Taht
2016-05-01 4:46 ` [Make-wifi-fast] " Jonathan Morton
2016-05-01 5:08 ` Ben Greear
2016-05-01 5:23 ` Dave Taht
2016-05-01 14:47 ` [Make-wifi-fast] " dpreed
2016-05-02 14:03 ` Roman Yeryomin
2016-05-02 18:40 ` Dave Taht
2016-05-05 13:55 ` Roman Yeryomin
2016-05-05 14:55 ` Roman Yeryomin
2016-05-02 19:47 ` David Lang
2016-05-01 17:59 ` [Codel] " Eric Dumazet
2016-05-01 18:20 ` Jonathan Morton
2016-05-01 18:46 ` Eric Dumazet
2016-05-01 19:55 ` Eric Dumazet
2016-05-02 7:47 ` Jesper Dangaard Brouer
2016-05-01 20:35 ` Jonathan Morton
2016-05-01 20:55 ` Eric Dumazet
2016-05-02 14:18 ` Roman Yeryomin
2016-05-02 15:07 ` Eric Dumazet
2016-05-02 15:43 ` Roman Yeryomin
2016-05-02 16:14 ` Eric Dumazet
2016-05-02 17:08 ` Dave Taht
2016-05-02 17:44 ` Eric Dumazet
2016-05-05 14:32 ` Roman Yeryomin
2016-05-05 14:53 ` Roman Yeryomin
2016-05-05 15:32 ` Dave Taht
2016-05-05 16:07 ` Roman Yeryomin
2016-05-05 16:59 ` Jonathan Morton
2016-05-05 17:39 ` Roman Yeryomin
2016-05-05 18:16 ` Dave Taht
2016-05-05 18:33 ` Dave Taht
2016-05-05 16:12 ` Eric Dumazet
2016-05-05 16:25 ` Roman Yeryomin
2016-05-05 16:42 ` Roman Yeryomin
2016-05-06 10:55 ` Roman Yeryomin
2016-05-05 19:23 ` Eric Dumazet
2016-05-05 19:41 ` Dave Taht
2016-05-06 8:41 ` moeller0
2016-05-06 11:33 ` Jesper Dangaard Brouer
2016-05-06 11:46 ` moeller0
2016-05-06 13:25 ` Eric Dumazet
2016-05-06 15:25 ` moeller0
2016-05-06 15:58 ` Eric Dumazet
2016-05-06 16:30 ` moeller0
2016-05-06 15:55 ` [PATCH net-next] fq_codel: add memory limitation per queue Eric Dumazet
2016-05-09 3:49 ` David Miller
2016-05-09 4:14 ` Cong Wang
2016-05-09 4:31 ` Eric Dumazet
2016-05-09 5:07 ` Cong Wang
2016-05-09 14:26 ` Eric Dumazet
2016-05-10 4:34 ` Cong Wang
2016-05-10 4:45 ` Eric Dumazet
2016-05-10 4:57 ` Cong Wang
2016-05-10 5:10 ` Eric Dumazet
2016-05-16 1:16 ` [PATCH net-next] fq_codel: fix memory limitation drift Eric Dumazet
2016-05-17 1:57 ` David Miller
2016-05-06 9:42 ` OpenWRT wrong adjustment of fq_codel defaults (Was: fq_codel_drop vs a udp flood) Jesper Dangaard Brouer
2016-05-06 9:42 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Jesper Dangaard Brouer
2016-05-06 12:47 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Jesper Dangaard Brouer
2016-05-06 12:47 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Jesper Dangaard Brouer
2016-05-06 18:43 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Roman Yeryomin
2016-05-06 18:43 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Roman Yeryomin
2016-05-06 18:56 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Roman Yeryomin
2016-05-06 18:56 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Roman Yeryomin
2016-05-06 19:43 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Dave Taht
2016-05-06 19:43 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Dave Taht
2016-05-15 22:34 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Roman Yeryomin
2016-05-15 22:34 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Roman Yeryomin
2016-05-15 23:07 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Eric Dumazet
2016-05-15 23:07 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Eric Dumazet
2016-05-15 23:27 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Roman Yeryomin
2016-05-15 23:27 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Roman Yeryomin
2016-05-16 8:12 ` [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: " David Lang
2016-05-16 8:12 ` [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " David Lang
2016-05-16 8:26 ` Roman Yeryomin
2016-05-16 8:26 ` Roman Yeryomin
2016-05-16 8:46 ` [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: " David Lang
2016-05-16 8:46 ` [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " David Lang
2016-05-16 10:34 ` [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: " Sebastian Moeller
2016-05-16 10:34 ` [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Sebastian Moeller
2016-05-16 8:14 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Roman Yeryomin
2016-05-16 8:14 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Roman Yeryomin
2016-05-16 14:23 ` [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: " Eric Dumazet
2016-05-16 14:23 ` [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Eric Dumazet
2016-05-16 16:04 ` Dave Taht
2016-05-16 16:04 ` Dave Taht
2016-05-16 19:46 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Roman Yeryomin
2016-05-16 19:46 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Roman Yeryomin
2016-05-07 9:57 ` Kevin Darbyshire-Bryant
2016-05-15 22:47 ` Roman Yeryomin
2016-05-15 22:47 ` Roman Yeryomin
2016-05-03 2:26 ` [Codel] fq_codel_drop vs a udp flood Dave Taht
2016-05-03 5:21 ` Dave Taht [this message]
2016-05-03 12:39 ` Agarwal, Anil
2016-05-03 12:50 ` Agarwal, Anil
2016-05-03 13:35 ` Eric Dumazet
2016-05-03 15:37 ` Agarwal, Anil
2016-05-03 17:37 ` Dave Taht
2016-05-03 17:54 ` Eric Dumazet
2016-05-03 18:11 ` Dave Taht
2016-05-03 13:20 ` Kevin Darbyshire-Bryant
2016-05-01 18:26 ` Dave Taht
2016-05-01 22:30 ` Eric Dumazet
2016-05-02 14:09 ` Roman Yeryomin
2016-05-02 15:04 ` Eric Dumazet
2016-05-02 15:42 ` Roman Yeryomin
2016-05-02 13:47 ` [Make-wifi-fast] " Roman Yeryomin
2016-05-02 15:01 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw5NwBMzNrm6S2wPnx4yLTYq1k_J-cJ_Bi73p_uD_uo1xw@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=ath10k@lists.infradead.org \
--cc=chromatix99@gmail.com \
--cc=codel@lists.bufferbloat.net \
--cc=eric.dumazet@gmail.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.