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 4CF593B29E for ; Fri, 22 Jun 2018 10:52:49 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3662D20090 for ; Fri, 22 Jun 2018 11:07:10 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B1A3A16E1; Fri, 22 Jun 2018 10:49:46 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AF01C91C for ; Fri, 22 Jun 2018 10:49:46 -0400 (EDT) From: Michael Richardson To: bloat In-Reply-To: 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> 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 Date: Fri, 22 Jun 2018 10:49:46 -0400 Message-ID: <25305.1529678986@localhost> 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 14:52:49 -0000 Jonathan Morton wrote: >> Your original note was looking for a way >> for finding out if the probability of seeing more data in the next 10us >> was sufficiently large to delay "a teeny bit" so that would be the >> problem statement. > 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? -- ] 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 [