From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7DD4D3B29E for ; Fri, 22 Jun 2018 17:58:08 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8DD6620090 for ; Fri, 22 Jun 2018 18:12:30 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C913775; Fri, 22 Jun 2018 17:55:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C6B8E71 for ; Fri, 22 Jun 2018 17:55:05 -0400 (EDT) From: Michael Richardson To: bloat In-Reply-To: <47EC21F5-94D2-4982-B0BE-FA1FA30E7C88@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> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Subject: Re: [Bloat] lwn.net's tcp small queues vs wifi aggregation solved X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 21:58:08 -0000 --=-=-= Content-Type: text/plain Jonathan Morton wrote: >>> I would instead frame the problem as "how can we get hardware to >>> incorporate extra packets, which arrive between the request and grant >>> phases of the MAC, into the same TXOP?" Then we no longer need to >>> think probabilistically, or induce unnecessary delay in the case that >>> no further packets arrive. >> >> I've never looked at the ring/buffer/descriptor structure of the ath9k, but >> with most ethernet devices, they would just continue reading descriptors >> until it was empty. Is there some reason that something similar can not >> occur? >> >> Or is the problem at a higher level? >> Or is that we don't want to enqueue packets so early, because it's a source >> of bloat? > The question is of when the aggregate frame is constructed and > "frozen", using only the packets in the queue at that instant. When > the MAC grant occurs, transmission must begin immediately, so most > hardware prepares the frame in advance of that moment - but how far in > advance? Oh, I understand now. The aggregate frame has to be constructed, and it's this frame that is actually in the xmit queue. I'm guessing that it's in the hardware, because if it was in the driver, then we could perhaps do something? > In principle it should be possible to delay frame construction until > the moment the radio is switched on; there is a short period consumed > by a data-indepedent preamble sequence. In the old days, HW designers > would have bent over backwards to make that happen. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWy1wN4CLcPvd0N1lAQJxLwf9EaTh2+VhJzPeSbvoYb6LKiEQw4ZxMVkX 8d5DQpVlMEBqsZCnLY/bSTvDmjmsaHAQOp3KbquINoqiz+gNv3PHH0uArYHQAA8N tsJ/5tJZ+AhNu4pM2r6biQWeYN96jToyWcLXZ/KVYul6ePGzWO+SZhP//eknMAyy RHVICFTUPzLc05yXO3DeoI8d61Opi0KeuDFhXjWDSAtbIcdXwi+AGZfLTR8zfjbd QnNgkuS7dJoGjl6wuSAWb8xUaw0T3fhOM5bNdIjfdK9YxSfG0eWhDp5//Qf2YX8f pZQiGgNYFlORvBi43g5dDUZ7aLIonhTVfY4+Uksqed29lYqNI5+Ofg== =vRgM -----END PGP SIGNATURE----- --=-=-=--