From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 D2BF43B2A3; Mon, 30 Jan 2017 18:21:41 -0500 (EST) Received: by mail-qt0-x242.google.com with SMTP id s58so16950569qtc.2; Mon, 30 Jan 2017 15:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nk+SZ9jpA0ih+qlfI6YgoU2/wuHcw/pyjxuMtW/RdyU=; b=bq6P19m+0ynp9KHtDO85zFS7soEXYEnCDBsfDaUrQ5htcR9nAO1WXJ7LtLKTj++D4T Li6HpL3aayzSJsAnVlt6AmEKijdeBuQ3oPJpBHfUl1tis6Na0jpqSj81GWlQSf+Bae6L wPG30uM8aZ6L1VaCmYHG09BGWPNhgFCWXUlSk4+5Pd2k+M3j/2+wmD+LFC/IyO+ICsqZ AfNNw3SWiIsCiRS6A3JvSIhLo/7AuXB+BGVRpiGdV++GSaCzDGJPmKXRpgjCbQoBernA WjsZUVRIDGcVZ1Qcaf9jw9mCsM4NmxlC/ECrUiyTSQp5aq4QWO7LSH5KyIF4xCWwLw+g dcig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nk+SZ9jpA0ih+qlfI6YgoU2/wuHcw/pyjxuMtW/RdyU=; b=m0DPAMMOpxRBVm2ryoH5yYExruHFCyVzmj3MfZZfHlqCXGYPbsQLnKLGlTmW3Ka8kI V5ZDWqUJu3HCPWAacE36eRm31XiXtDx5RFhd074fEVUfap3xz0ydJUNR6CykV8WNvApi jTSrbGb7Nps45df9Yo3ZATTPOUvuCwuA73fFsppOgRJSsXOvuzLAVA0TphRZ5LtWXOtH HTRodh1baH8fe//2kpwtMhNmHHwVHTKzeNG6bA7s67Go9JWc03/yF8nNIQZNFjwvNY+c Ll9gZ0AEJlZ54gj/sf3n6djNCgSInyd8wJsZywVrvWyGJ+Yj1uGXJvqvfWhjtpG0psfC Q3aw== X-Gm-Message-State: AIkVDXLrxxzc/Ggz8lRFzeoA99Grc3dtDCdZSde+n9frZmyuQvfw0LMmoYSO6UosC9sKhrcLUdVQC0w9yfOSLw== X-Received: by 10.200.41.73 with SMTP id z9mr22516486qtz.137.1485818501357; Mon, 30 Jan 2017 15:21:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.132 with HTTP; Mon, 30 Jan 2017 15:21:40 -0800 (PST) In-Reply-To: <877f5c2pew.fsf@toke.dk> References: <32C42951-373F-4D90-8936-AA07039E5D73@gmail.com> <877f5c2pew.fsf@toke.dk> From: Dave Taht Date: Mon, 30 Jan 2017 15:21:40 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Pete Heist , cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Subject: Re: [Make-wifi-fast] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available 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: Mon, 30 Jan 2017 23:21:41 -0000 Very exhaustive work, thank you. A backstory of how I got involved in the bufferbloat effort was that I deployed some shiny "new" and "faster" wireless-n radios (6 years ago)... and my WISP network in Nicaragua collapsed in rain - which was about 6 months after I'd made the cutover from g and from motorola's radios. The signal strength was within expected parameters, the achieved rates were half to 1/3 what they were dry, but latencies climbed to over 30 seconds in some cases. I had *no* idea what was going wrong at the time, and it wasn't until 6 months after I closed the business that I ran into Jim Gettys, and the rest is history. I never got around to writing it up, I just gave a couple talks on the subject and moved onto fixing bufferbloat thoroughly. We got distracted by trying to solve it on the ISP backbones before tackling wifi in this past year. OpenWrt Chaos calmer generally should work "pretty good" on 802.11n p2p links with the fq_codel qdisc at the qdisc layer, and a bit of tuning of qlen_be (I deployed 12-24 on the yurtlab campus), and turning off 802.11e. Lacking ATF and good queue management closer to the radio, p2mp did not work well with chaos calmer. with the new stuff now landing in lede I still recommend turning off 802.11e and relying entirely on fq_codel down there, and I have high hopes that basic p2mp will work well for up to X stations. ... As for the performance of openmesh being pretty good... they were the first group to test the fq_codel intermediate queues and ATF code way back in september, :) - it's not clear to me if that's what you were testing or not or they shipped an update yet. Your 20-30ms p2p latency performance on the rrul_be test is consistent with the results we get from the fq_codel intermediate queue patches, which keep 2 ~4ms aggregates near the hardware. Applying a qdisc on top should make little to no difference, as all the real work gets done there. [2] A good test to run is to lower the mcs rates (set the rateset manually, or add distance, and/or rain) and to see how flat latency remains. This is also a better test of real-world conditions, if you can get some reports back on the actual mcs rates being achieved in the field, and use those. It would be my hope that 802.11e is off (rrul will show this, and we still do badly with it on) You can probably within this deployment shape the uplinks to some fairly low value and get good performance more the time. I do not have any real hope for being able to make wifi better with soft-shapers. It's a gordian knot - you need to respond rapidly to changes in rate, both up and down, and mix up flows thoroughly, optimize your aggregates to go to one station at a time and switch to the next, and that's what we got with codel close to the hardware as it is now in lede. [1] If it helps any, this is the best later talk I've given on these subjects: https://www.youtube.com/watch?v=Rb-UnHDw02o UBNT's gear (commonly used by wisps) has some neat tricks to manage things better, when I last took apart their qos system it was an insane set of sfqs with sfqs. [1] And as we have more radio-dense environments now, retries are becoming an issue. [2] http://blog.cerowrt.org/post/real_results/