From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 221193B260 for ; Wed, 27 Apr 2016 01:46:17 -0400 (EDT) Received: by mail-oi0-x232.google.com with SMTP id k142so38611231oib.1 for ; Tue, 26 Apr 2016 22:46:17 -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=i1zxCu1Rlflzq0D9p9Jd0GVr0ztZKtiUMqBGIWzbgyE=; b=uEEIlQ7TU93tsl9sJFoFZ4+EYGVclazeRcujqoW77irVo6AGB8gP/TJYdiJ8lffZiQ CN4kIkJYqkGUOLwcYJNxwljRpvQ9mLaG168WU63TFz9OV6HJbm70eoV848kD50pFVZTA GiDrRrcynq3WtHpqTg7yWJ+bDEhuWuidHZS4Mk4Go/6eBs7+NX41aVF30n+FNFCTvET9 CzCYcMg98KReXvfJYYFAvQAv6KkvdiigYsSpqVge+OW0uVner0h3anKAlndkBW+vIFGF Ll8eCXNlAb7gKny/Q4UWG58ymO9lX2ZxaSC3tKb6DmysFKsmh2wBGsRZnulhugicts6o PhbQ== 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=i1zxCu1Rlflzq0D9p9Jd0GVr0ztZKtiUMqBGIWzbgyE=; b=lQDGvn+4f7E4wBJiK3IRe5WLTZ0ghxuX24fZv3k4StSTrQnqdU3HTkDRAr7sxefRGL AoT+YDiUxnLcjLUxALs5+jCfM+QxTS9905gypNLowS/4ev0MdJWPuZHmWsMehKk6pt8L QaD0HGsGOAdyhwS8YQ/t97GMfYbQ/qGsQMTK6cCQ4QUIPZFYHnJN8ds4sUb57SUuKS7b BeCupq/i4BeHArbI6HWwnMAoi1g/TCbYJkSOBH8IQHEd5g74mEizAwnC/varfLg5gtUK TyL3wtJ/oLx1qKykT90ekmaPsZK0jJuVW0ZPhn4M4+95kLKfi4z6AHLlf3aO9YXGTVV8 wE0Q== X-Gm-Message-State: AOPr4FVE5FMhv92ayxy6Gky446lr6ZMxx3QcT4iZqz4FyZyedU1LLOZAejcgEqpTLhGqmju7lcMU0kKYb1xfkw== MIME-Version: 1.0 X-Received: by 10.202.185.214 with SMTP id j205mr2389854oif.68.1461735976533; Tue, 26 Apr 2016 22:46:16 -0700 (PDT) Received: by 10.202.79.194 with HTTP; Tue, 26 Apr 2016 22:46:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Apr 2016 22:46:16 -0700 Message-ID: From: Dave Taht To: Michal Kazior Cc: make-wifi-fast@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 05:46:17 -0000 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? 2) (long, speaking to the crowd for posterity) I did, eventually, see codel_ecn_marks stats. Don't know why I did not see them before. I see ecn marks in the capture, and the corresponding ecn echo bits and cwr in the capture (with ecn enabled on both sides via sysctl -w net.ipv4.tcp_ecn=3D1 ) in wireshark, to see it in acks (I am mostly doing tcp_upload testing) ip.dsfield.ecn =3D=3D 3 tcp.flags.cwr =3D=3D 1 # respond to a mark or drop and/or - to see the ecn-echo flag set tcp.flags.ecn =3D=3D 1 or: (ip.dsfield.ecn =3D=3D 3) or (tcp.flags.cwr =3D=3D 1) or ( tcp.flags.ecn =3D=3D 1) you can determine the length of the queue by looking at these timestamps also (any wireshark lua programmers out there?) but I've never got further than eyeballing them, and/or using xplot.org (and tcptrace -G) to look at the caps. Looked nice, queue a bit long, still. :) I put a ethernet capture up of a flent rtt_fair (both up and down at the same time, ath9k with a fq_codel qdisc on the other side). http://blog.cerowrt.org/captures/ath10k/fqwifi.cap.gz 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. On Tue, Apr 26, 2016 at 10:22 PM, Michal Kazior w= rote: > 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_control= led.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 --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org