From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (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 4C54D3B2D3; Fri, 26 Feb 2016 17:20:07 -0500 (EST) Received: by mail-ob0-x235.google.com with SMTP id jq7so89989480obb.0; Fri, 26 Feb 2016 14:20:07 -0800 (PST) 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; bh=Mt9mOqLEi0/GLOiVlunxJF2lyfdQKt1VFK3TmByg3E4=; b=MD1lbGFX4B2Y3ZQ450pLL5HR8w+iZTtwCvwjAZnCF6Nd0wYXeLG2VU6cxdN+OFqzCa vRMPs703C8xXL+M4GbAWtYdVFYHRgK339o7Xl/eRZf4YQlaxOr8wivY/cx2Ya+WD/s8S N+38PHYXo10K8TfPYd7E/p2NrWDFHqggTY5pLgAogVnj4yiiVEeT6oACPwd1I4trB9Xk k0rswYR2wmdzCaYX8pWlnhtX/mj8MsUjlaQdsGaccQNwXG77BITGXRmbNs+sKqmuIaGJ ggZICrfj2p3XKQ99oCmUFwNqC2mWrXeDJuzdVWaTGhOqhfqrUapJ0Sixfx+s63otesUj KimQ== 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; bh=Mt9mOqLEi0/GLOiVlunxJF2lyfdQKt1VFK3TmByg3E4=; b=NGVyzfHpqkKrjuexyb9HnyDH/GDzZNJymxenXrkTYcqtBAK22irysJTB3P80sbprQ6 0E2mCpI8irt9ZZBoI6lh3IgzfG1r3wUcAzlscM2Jb4XOiyEZkN/hOyuoX+8iqK3EBVS+ 6zfOrFEtmPdYVdooKs0qcKgevBCyu5GQxDLs5CtKi0l8mtItx+JM+bMuXn7xPa5NpJIM 5ASTkJTLHsCcrfSaBUtemJ8kKshPUE0RvfJUnxBil8hyFlw3hs5NysptJma/rHpiXBdL CY6rAMIqm1YzuF0IAw2foBdYlf0VrZaL8cQo6X2ZCorfMj2uq1H2mCW7R4tB8hiVooJk xyGw== X-Gm-Message-State: AD7BkJI3g5ME6rsNFqBaVUhBBfDdSu9GU14hQf7/Gm9v7ZpptUOGgiHI9+RXB7yYpvW5+roQBTgBPbROm2bamQ== MIME-Version: 1.0 X-Received: by 10.60.232.133 with SMTP id to5mr3053127oec.33.1456525206643; Fri, 26 Feb 2016 14:20:06 -0800 (PST) Received: by 10.202.79.67 with HTTP; Fri, 26 Feb 2016 14:20:06 -0800 (PST) In-Reply-To: References: <1456492163-11437-1-git-send-email-michal.kazior@tieto.com> Date: Fri, 26 Feb 2016 14:20:06 -0800 Message-ID: From: Dave Taht To: Michal Kazior Cc: make-wifi-fast@lists.bufferbloat.net, "codel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [Make-wifi-fast] [RFC/RFT] mac80211: implement fq_codel for software queuing 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: Fri, 26 Feb 2016 22:20:07 -0000 Dear Michal: Can you take a picture of your setup? Our intent is to continue to improve the flent test suite to be able to generate repeatable tests, track relevant wifi behaviors and pull relevant data back, graphed over time (of test) and time (over test runs). A problem with udp flood tests is that tcp traffic is always bidirectional (data vs acks), so a naive thought would be, that yes, you should get half the bandwidth you get with a udp flood test. But in the age of aggregation that is not correct. It is my hope for us to join you on testing/evaluating the various bits, but with so many patches (wonderfully, but suddenly) flying around in loose formation ( can we start a lowlatency-wifi kernel tree somewhere? - oy, there are so many other moving parts!), that's going to take a bit. While we have some ath10k gear, the biggest testbeds (karstad, san francisco, yurtlab) are all ath9k based. Some things you could do for us whilst we try to catch up. Take packet captures! - there are plenty of tcp experts on the codel list. For single station tests: run a repeatable test series: rrul, rrul_be, tcp_upload, tcp_download. Provide those flent.gz files. rrul exercises 3 of the 4 802.11e queues on most systems. rrul_be one queue Example: #!/bin/sh T="some meaningful title like fq_codel_target_30ms_10meters-crazynewpatch-1" S=some.netperf.server.nearby F="fent -x -l 60 " TESTS="rrul rrul_be tcp_upload tcp_download" for i in $TESTS do $F -H $S -t "$T" done flent-gui *.gz If you are running tests overnight (recommended, wifi data is noisy so are office environments), iterate on the $T-test number... You can also track remote queue lengths and stats with other flent options. My assumption however is that you are almost entirely bypassing the qdisc queue now(?) and injecting things into a queue that cannot be seen by userland? For playing with MU-mimo, the various rtt_fair tests in flent were our starting point, which test anywhere from 1 to 4 stations. example testing 2 stations with two tcp streams. rtt_fair4be -H station1 -H station2 -H station1 -H station2 The packet captures should be *fascinating* on that. Aircaps interesting also. Other variables to tweak: 0) Use the same driver on server and client. Then a reference driver. 1) Disable codel entirely or give it a really big target/interval (30ms, 300ms) to just look at the fq portion of the algorithm. 2) enabling ECN on the tcps on server and client will give you a clear idea as to when codel was kicking in vs packets being dropped elsewhere on the packet captures. 3) One of my biggest ongoing concerns with adapting codel in wifi has been the impact of multicast on it - mdns-scan (along with any of the above tests), or some other heavy mcast program in the background (uftp is not bad). mu-mimo introduces new issues with sounding that I don't think anyone understands at any detail yet. Can wireshark or some other tool "see" a sounding? 4) Distance and rate control. MCS4 was my basic rate for transmits from stations for the longest time as that appeared to be the median rate I'd got in various coffee shops... while I realize you have to achieve peak throughput under ideal conditions, it's achieving good overall performance in more abusive conditions... ... and ... 5) come to battlemesh with what you got.