From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 7385C3B29E; Mon, 25 Jun 2018 21:27:57 -0400 (EDT) Received: by mail-qt0-x229.google.com with SMTP id z6-v6so13803542qti.2; Mon, 25 Jun 2018 18:27:57 -0700 (PDT) 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:content-transfer-encoding; bh=iyQLjCzI4tR39ni8SU3vIHj5ViRJIrU7+tPncW5TyR4=; b=Quy3PwdI5uHedec2dcFgjcbvCQan1Ka1zXq61s/u7nKduoqHykkQvE51jmUBwqmX84 sgIMFvE7B5NLPE4oQlO+Ft9gt7uDaZqzcSZngLD9DB8XvptM/AN5xbH7SgiDW8tE231K ZOgiURYdhMHATYYPccIz4oQ16CPwpEeI7RXhS7pNvJhymkQMSm4+Ehd3ZQHnAZYh9AhR +yMzJAJRAQQkhOnL/4j9YNxlGwr1x3m8w48I9qQ8AqxENIC5H2vKXbGC016VDe4ITnPQ IH6oMEzu7qOtghGyx4f0GsvtPU5JxMEBzWceiObbUGjd1MCIIGOWE7IFzdH+WUGoebr1 itmw== 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:content-transfer-encoding; bh=iyQLjCzI4tR39ni8SU3vIHj5ViRJIrU7+tPncW5TyR4=; b=msu1PHyvMgWoQhm+qet7/qW/Q/Ud8fvbmdPG6qEUgiCBtl6flQCrJTSRGCAaNMM/nE N+LedbqjWM9uAhcIOclYqy5hJHDHk7BmzZOo1ES+iG5VZ7QeWRWyOtU0j6F6iNpVj2wi c2LeOhgOKNyVD+cMoqOyKzDcqftq72d8qk18m5ew5pxsxUW3jyI2A2JhxutaSmkakeEC tZUVan3yzmZErZb41OWJCL2P89tE7n2uY2IIrp48+yUKsQPeqlsMVmGlMC7+zEPEdyWj 7G6cLybOlwN+a14p2mrYQP4LHUt0yj4Uihero6w5Xuo9uAZ0aYINhms18oYel2q/UqBN 4+cw== X-Gm-Message-State: APt69E0x6TdjKVij/YsH+rzZq1GpbGwkjBd0W3jArvMqUwCthnYe31ZE ISMCPtQXjSZfvztwGVnQc+a4yHC8yVkXintSqps= X-Google-Smtp-Source: ADUXVKJvUgioXqiIIhYEpyPeLqHq8lMNsVZrvmtJMkq18bWOcQkdDilPdrlvqPPqI3Zbz1aZEd6S34SA/O6IZbTgXDw= X-Received: by 2002:ac8:33cf:: with SMTP id d15-v6mr13407743qtb.261.1529976476839; Mon, 25 Jun 2018 18:27:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:24f0:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 18:27:55 -0700 (PDT) In-Reply-To: <422BFE8C-1AAC-4A55-AF1F-448B3B5C0E28@gmail.com> References: <8736xgsdcp.fsf@toke.dk> <838b212e-7a8c-6139-1306-9e60bfda926b@gmail.com> <8f80b36b-ef81-eadc-6218-350132f4d56a@pollere.com> <9dbb8dc8-bec6-8252-c063-ff0ba5fd7c1a@pollere.com> <25305.1529678986@localhost> <47EC21F5-94D2-4982-B0BE-FA1FA30E7C88@gmail.com> <18224.1529704505@localhost> <87muvjnobj.fsf@toke.dk> <68C3BBE1-96DA-41F7-9878-582074C4E769@gmail.com> <642CBFAE-A182-4D6E-968B-411159CBFD9B@superduper.net> <422BFE8C-1AAC-4A55-AF1F-448B3B5C0E28@gmail.com> From: Dave Taht Date: Mon, 25 Jun 2018 18:27:55 -0700 Message-ID: To: Jonathan Morton Cc: Simon Barber , bloat , Make-Wifi-fast Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [Bloat] lwn.net's tcp small queues vs wifi aggregation solved 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: Tue, 26 Jun 2018 01:27:57 -0000 On Mon, Jun 25, 2018 at 5:44 PM, Jonathan Morton wr= ote: >> On 26 Jun, 2018, at 3:36 am, Simon Barber wrote: >> >> Most hardware needs the packet finalized before it starts to contend for= the medium (as far as I=E2=80=99m aware - let me know if you know differen= tly). One issue is that if RTS/CTS is in use, then the packet duration need= s to be known in advance (or at least mid point of the RTS transmission). > > This is a valid argument. I think we could successfully argue for a dela= y of 1ms, if there isn't already enough data in the queue to fill an aggreg= ate, after the oldest packet arrives until a request is issued. Whoa, nelly! In the context of the local tcp stack over wifi, I was making an observation that I "frequently" saw a pattern of a single ack txop followed by a bunch in a separate txop. and I suggested a very short (10us) timeout before committing to the hw - not 1ms. Aside from this anecdote we have not got real data or statistics. The closest thing I have to a tool that can take apart wireless aircaps is here: https://github.com/dtaht/airtime-pie-chart which can be hacked to take more things apart than it currently does. Looking for this pattern in more traffic would be revealing in multiple ways. Looking for more patterns in bigger wifi networks would be good also. I like erics suggestion of doing more ack compression higher up in the tcp stack. There are two other things I've suggested in the past we look at. 1) The current fq_codel_for_wifi code has a philosophy of "one aggregate in the hardware, one ready to go". A simpler modification to fit more in would be to (wait the best case estimate for delivering the one in the hardware - a bit), then form the one ready-to-go. 2) rate limiting mcast and smoothing mcast bursts over time, allowing more unicast through. presently the mcast queue is infinite and very bursty. 802.11 std actually suggests mcast be rate limited by htb, where I'd be htb + fq + merging dup packets. I was routinely able to blow up the c.h.i.p's wifi and the babel protocol by flooding it with mcast, as the local mcast queue could easily grow 16+ seconds long. um, I'm giving a preso tomorrow and will run behind this thread. It's nice to see the renewed enthusiasm here, keep it up. >> If there are no other stations competing for airtime, why does it matter= that we use two txops? > > One further argument would be power consumption. Radio transmitters eat = batteries for lunch; the only consistently worse offender I can think of is= a display backlight, assuming the software is efficient. > - Jonathan Morton > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619