From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 3D41A3B25D for ; Fri, 13 May 2016 16:21:09 -0400 (EDT) Received: by mail-oi0-x22f.google.com with SMTP id v145so187923842oie.0 for ; Fri, 13 May 2016 13:21:09 -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=KZjn28Xi0nr69OibHGFUmjNsMrUHtRqvco7lgzsdNHA=; b=WVXjHZnwxhiAcHLfvd9LLpy4gJnSYaCaluDEZi7zpQ/234qjnzUexjcrjHZaV6b3uQ K3Sli/8JAXo3KnoFzTREso6c4FeQ6pSBU9z9oGJWMNLvVy1law7PHfafGOhLpFh1hWMA rqFBQV20v8H4wiTJ2trtAizadEImvmg6AsForghx6VP3UbkaIXfHdpGXcyqwgNYXoms9 LILHTe1v1KhTPVhrjv+nLdlAsqPiqKkf27Lx9BIPH5zE1NTMDIUrjMXLEzp58VS32838 rNkwiuZEg6D8uVxcpYhe//zug8TsSNAttvv4Vyqlzjh7f5vDFyi7Rwbua+PRaMDQRdMK iADQ== 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=KZjn28Xi0nr69OibHGFUmjNsMrUHtRqvco7lgzsdNHA=; b=hsVwbYj1hCxQkGPAQ3VyOEryhrKpRvE4INJPl/ED+iWuCqNsaLO7xrjjybybH7ksIq ErAXDooWP+92qRVpsiofQLkOrsZ88TtF8Ab7SUjmNhS7UL0TuA+n56hwTOBp9getTs3K /HQlmf8zSbYoOmWahRaM9uKsicsUIBpdXN8gK3ELymNhuL/sBd2LLeoFfLyyikFZJAXm /1yX/K+ksgqHtSKtPfJ2o1zZwnqbqcNCtSgU+nkHfe5dh1dcceKSCiHPxCgdcmJnoEXy s8j4imiFpVPIVrMYaS+/i+WjXjlApMCqEeV8eb0xiFiLEEr1eWmvq2g1CXltBSXaE6YC gT3Q== X-Gm-Message-State: AOPr4FXBxz5pdLkoBfEPPJ/RzdMd2NzVH9+AEyEXhY9L1GYEuHXnXIt5aD7CbCiR7sAsUVGSnxDsfLIKT7PXnQ== MIME-Version: 1.0 X-Received: by 10.202.178.135 with SMTP id b129mr8607252oif.139.1463170868664; Fri, 13 May 2016 13:21:08 -0700 (PDT) Received: by 10.202.229.210 with HTTP; Fri, 13 May 2016 13:21:08 -0700 (PDT) In-Reply-To: References: <871t5bpkc7.fsf@toke.dk> <6ADC1A9D-72C9-47A5-BDC7-94C14ED34379@gmail.com> Date: Fri, 13 May 2016 13:21:08 -0700 Message-ID: From: Dave Taht To: Aaron Wood Cc: Bob McMahon , make-wifi-fast@lists.bufferbloat.net, "ath9k-devel@lists.ath9k.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] Diagram of the ath9k TX path 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, 13 May 2016 20:21:09 -0000 On Fri, May 13, 2016 at 12:20 PM, Aaron Wood wrote: > On Fri, May 13, 2016 at 11:57 AM, Dave Taht wrote: >> >> On Fri, May 13, 2016 at 11:05 AM, Bob McMahon >> wrote: >>> >>> don't have the data available for multiple flows at the moment. >> >> >> The world is full of folk trying to make single tcp flows go at maximum >> speed, with multiple alternatives to cubic. > > > And most web traffic is multiple-flow, even with HTTP/2 and SPDY, due to > domain/host sharding. Many bursts of multi-flow traffic. About the only > thing that's single-flow is streaming-video (which isn't latency sensitiv= e). And usually, rate limited. It would be nice if that streaming video actuall= y fit into a single txop in many cases. > The only local services that I know of that could use maximal-rate wifi a= re > NAS systems using SMB, AFP, etc. And many of these, until recently, were actually bound by the speed of their hard disks and by inefficiencies in the protocol. > > -Aaron A useful flent test for seeing the impact of good congestion control, are tcp_2up_square and tcp_2up_dleay. There are also other related tests like "reno_cubic_westwood_cdg" which try one form of tcp against another. I really should sit down and write a piece about these, to try to show that one flow grabbing all the link hurts all successor flows. Both could be better. I like what the teacup people are doing here, using 3 staggered flows to show their results. ... and I misspoke a bit earlier, meant to say txop where instead I'd said ampdu. Multiple ampdus can fit into a txop, and so far as I know, be block acked differently. https://books.google.com/books?id=3DXsF5CgAAQBAJ&pg=3DPA32&lpg=3DPA32&dq=3D= multiple+ampdus+in+a+txop&source=3Dbl&ots=3DdRCYcD9rBc&sig=3DtVocMORuEXBOsf= UlcmuSLTdM0Lw&hl=3Den&sa=3DX&ved=3D0ahUKEwiLxurP69fMAhVU5WMKHVejAlUQ6AEIHzA= A#v=3Donepage&q=3Dmultiple%20ampdus%20in%20a%20txop&f=3Dfalse One thing I don't have a grip on is the airtime cost on packing multiple ampdus into a txop, in terms of the block ack, also in relation to using amdsus as per the 2015 paper referenced off the "thoughts about airtime fairness thread" that the ath9k list was not cc'd on. https://lists.bufferbloat.net/pipermail/make-wifi-fast/2016-May/000661.html I note that some of my comments on that thread was due to the overly EE and math oriented analysis of the "perfect" solution, but I'm over that now. :) It was otherwise one of the best recent papers on wifi I've read, and more should read: http://www.hindawi.com/journals/misy/2015/548109/ (and all the other cites in that thread were good, too. MIT had the basics right back in 2003!) One of my longer term dreams for better congestion control in wifi is to pack one aggregate in a txop with stuff you care about deeply, and a second, with stuff you don't (or vice versa). As also per here, filling in my personal memory gap from 2004 or so (when I thought block acks would only be used on critical traffic) and where I started going back and reviewing the standard. http://blog.cerowrt.org/post/selective_unprotect/ --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org