From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 97FB53B260 for ; Wed, 27 Apr 2016 02:28:19 -0400 (EDT) Received: by mail-wm0-x22e.google.com with SMTP id g17so6024557wme.0 for ; Tue, 26 Apr 2016 23:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=pmmXtLqCTs/uKxrf6hBDEmlPQp9yi2lMBK3kGNyfIYo=; b=3WsjZYnPTX2D2U+JV6bkz8SQ8OEN5UceCHSfe1dBwKWqK6Xtxh9+9WVlAaKfYG+Ed7 i+YYDTYJMpQHJzEhAejb7yUul0i4IVpBjM1bBeMqv46mIuaSd4CKmrN12h9YKGbSwzsr 5s9Yeb/LuhyRfpLbUTZKpnyomwBtGLqjUgdSY= 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=pmmXtLqCTs/uKxrf6hBDEmlPQp9yi2lMBK3kGNyfIYo=; b=awJALNN31NJD8LaViMDc/H6l1bfwd/DPwrEJre5nYW4OF3JdtVTJZnI6aZmHoBEfkB MzHZb9nJ65jZxZ+yWVTiuN4vQZP2sE+VsMLDYijcTu1WTgXgR5MEypYxPaYFucaMdtKD Yj2nz9dMznyMjSPnWOYhpR+KcO6hsBsNrSeWt7IRL873InYwvSvjk/hOy6tt9UdJXypm lSZ4SL1BGHVttJwjXGehGtyocv4rTj6Kam548QJVupccau52YowzlM+s/O5SJol67D9V F7VqgMIc716nZYTXDZHIRkS++Vs4eMpHkz9rrWs5gxoGSUoyQN2szCmDKgjIqPcPsw2H KSuA== X-Gm-Message-State: AOPr4FUiCQj1KSWPqKB9mM7Pb4fpL5vjo7MGcVFczrlxzjUlGHE2wbogHpyLUuztDghWjQsKTcmDnvvJgYuWc6J0u5bAszLEPR0DZriL1g4d5UjjR26U++RRkMev7aWNY2OJ+2TOTVNIWbHqLElZHpWtFyUdLLfY86B9Vg== MIME-Version: 1.0 X-Received: by 10.194.166.228 with SMTP id zj4mr7333223wjb.83.1461738497811; Tue, 26 Apr 2016 23:28:17 -0700 (PDT) Received: by 10.194.104.105 with HTTP; Tue, 26 Apr 2016 23:28:17 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Apr 2016 08:28:17 +0200 Message-ID: From: Michal Kazior To: Dave Taht Cc: make-wifi-fast@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Subject: Re: [Make-wifi-fast] ath10k+fq_codel+fqmac3.5 test kernel - woot! 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: Wed, 27 Apr 2016 06:28:19 -0000 On 27 April 2016 at 07:46, Dave Taht wrote: > 1) I am confused - I only see a single phy - this means one phy for > both 2.4 and 5ghz? or do I just set them up with iw? 1 card is 1 phy. It may be dual-band. You can check this with `iw list` or `iw phyX info`. > 2) (long, speaking to the crowd for posterity) [...] > while *extremely* useful to see CE (yea! codel working!), seeing no > wifi media induced loss at all.... is just unnatural!!! :) and rtt > varies by about 40ms in some of these tests. But most of that was from > the other side. Well, wifi does a lot of re-transmits, even within a single "try", right? And then you have the sw-retry. Micha=C5=82 > > On Tue, Apr 26, 2016 at 10:22 PM, Michal Kazior = wrote: >> On 26 April 2016 at 22:03, Dave Taht wrote: >>> I got fqmac3.5 booted on the pcengines apu2d4 board and did do a few >>> tests at 2.4ghz at HT20 to start with. >>> >>> 1) Although the captures indicate CE is being asserted, the statistics >>> do not show that. >>> >>> root@apu2:/sys/kernel/debug/ieee80211/phy0# cat codel_ecn_mark >>> 0 >> >> Yeah. I've noticed that as well. The in-kernel codel.h does the ecn >> thing slightly differently compared to codel5.h. I didn't really look >> into it as my upload tests worked fine. > > codel5 added overload and drop and mark support. No tcp actually > responds to "drop and mark", but it seemed like a good idea to signal > the endpoint better when catastrophe was immanent & Overload support > seems needed in a world where evil senders may one day exist. mainline > fq_codel is pretty robust against that but overload behavior is a bit > cpu and memory intensive. > > I have no problem with sticking with the mainline codel for now. > > One of these days I'll pester the tcp wg group (who are all busy > redefining ecn to not be equivalent to loss) to do something about > drop and mark.... > > >>> >>> 2) an upload test: http://blog.cerowrt.org/flent/fqmac35/latency_contro= lled.png >>> >>> I also tested a rrul_be test to the heavily optimized ath9k box I >>> have, it was pretty nice but still over 60ms. I have to figure out how >>> to go about a/b-ing stuff, I have a few more ath10k boards on order. >>> >>> 3) also, the packet capture was *perfect* - not a trace of loss. >>> really... don't need perfect! well, >>> I guess, for testing..... >> >> Interesting. Did codel_drop show anything? > > Not on the ecn enabled tests. :) > > I will test harder, I had other issues today, like: I ended up not > testing the ath10k wifi path at all for a while. > > http://blog.cerowrt.org/post/poking_at_powersave/ > > The last plot was verrah interesting, I don't know what to make of it. > > tomorrow two more cards arrive so I can test both sides enabled this way. >> >> >> Micha=C5=82 > > > > -- > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org