Lets make wifi fast again!
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	make-wifi-fast@lists.bufferbloat.net,
	"codel@lists.bufferbloat.net" <codel@lists.bufferbloat.net>,
	ath10k <ath10k@lists.infradead.org>
Subject: Re: [Make-wifi-fast] [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

  reply	other threads:[~2016-05-03  5:21 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-01  3:41 [Make-wifi-fast] " Dave Taht
2016-05-01  4:46 ` Jonathan Morton
2016-05-01  5:08 ` Ben Greear
2016-05-01  5:23   ` Dave Taht
2016-05-01 14:47     ` dpreed
     [not found]       ` <CAJq5cE2woA3yb6i_7NLPpxjzvhsVk5uL8BnSTAY7Lp-M0KiPNg@mail.gmail.com>
     [not found]         ` <CAJq5cE2K0yrz6ALAoKWu23RSJZX9Y_P7Mqcy9ba8e-L3AVhOaA@mail.gmail.com>
2016-05-01 15:51           ` Jonathan Morton
2016-05-02 14:03       ` Roman Yeryomin
2016-05-02 18:40         ` Dave Taht
2016-05-02 20:17           ` [Make-wifi-fast] [Codel] " Isaac Konikoff
2016-05-05 13:55           ` [Make-wifi-fast] " Roman Yeryomin
2016-05-05 14:55             ` Roman Yeryomin
2016-05-02 19:47         ` David Lang
2016-05-01 17:59 ` [Make-wifi-fast] [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  9:42                           ` [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood) Jesper Dangaard Brouer
2016-05-06 12:47                             ` Jesper Dangaard Brouer
2016-05-06 18:43                               ` Roman Yeryomin
2016-05-06 18:56                                 ` Roman Yeryomin
2016-05-06 19:43                                   ` Dave Taht
2016-05-15 22:34                                     ` Roman Yeryomin
2016-05-15 23:07                                       ` Eric Dumazet
2016-05-15 23:27                                         ` Roman Yeryomin
2016-05-16  8:12                                       ` David Lang
2016-05-16  8:26                                         ` Roman Yeryomin
2016-05-16  8:46                                           ` David Lang
2016-05-16 10:34                                             ` [Make-wifi-fast] [OpenWrt-Devel] " Sebastian Moeller
2016-05-16  8:14                                       ` [Make-wifi-fast] " Roman Yeryomin
2016-05-16 14:23                                         ` Eric Dumazet
2016-05-16 16:04                                         ` Dave Taht
2016-05-16 19:46                                           ` Roman Yeryomin
2016-05-07  9:57                             ` Kevin Darbyshire-Bryant
2016-05-15 22:47                               ` Roman Yeryomin
2016-05-03  2:26     ` [Make-wifi-fast] [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-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

  List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox