From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (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 35EFC3B29E for ; Fri, 22 Jun 2018 11:02:58 -0400 (EDT) Received: by mail-lf0-x241.google.com with SMTP id d24-v6so9171501lfa.8 for ; Fri, 22 Jun 2018 08:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eG3NptSpFAjUzrK1wx4C0Zy1mVJyLI12o57ZIhe86q8=; b=EzhBDiq9GaIwtg6D1/5l1bppJp1Wg10mqrGNYkSwcMR/UG5FDml2RopBTAMGLjKW5L 5WZBMWhc9f5d5Wew16+VrIRnp4oJgZnTnUD8Dc3DggBG1EOEafCllPX/qB9UjOc2xzEo sv7xOTPE5a9aRlDGlw9doqV9kaORC7m0QgAEm3Cpyl1xMaj4iBP7geQqXIi+TF5Sn8z7 L3WbjJNzu744XiWZgU5FqUdR0eKlyOV5Gr37YBQYvrxpvLXlF/8lqgJi36/MRt7+mkU/ ybt+9M/jThRC+mC0NniTIpxqdWRkYL4IUlEaGUykaweRezZJer4IlD2vUXyrB59MLBFJ SxiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eG3NptSpFAjUzrK1wx4C0Zy1mVJyLI12o57ZIhe86q8=; b=p/MIbBKfjORVLgE0aMLJ9JqRt55pbNyZgGWhoKq2dM90ZqIjMtDRM5p/01kC8N5A34 O/fIWmZ9GvDBeX5HxYWRPUfBWelYl8XQF7CIyprWAn5Xb2RAUAKa/KCUm4lF8tLsHsMo lKlOxoZz0VP+zbVUqITYe5IeXg3piCJYUFny90Jw0/8lSXRbhOpgJN7z6IeO/UImGwVo j1OyH3e0the/Ur2P0YSmnbPJ4A3FgRVFP1EDYa85FAEMMZxE77XLMPrKjEAcG/vMVEiy GOn/UuFk+x9cdOm5luVRTTf1+9/9NQV5d3g0pcGWDBCSxyo5buRyK5SKPOraW7RoCv2K tlmQ== X-Gm-Message-State: APt69E0dEnb0QaB2m3O9pWgj7k/nVe+PInji5w8lZLXnXrElx4FbRWOO geemn7L42eNGVn9UdCFrssz50yN8 X-Google-Smtp-Source: ADUXVKLTJDqnylXYa3TrD6dvHVT2+NxNnubFjRuInW4pDMGmCH84bstbO+3ZZno4Wwh+5IweduiOAQ== X-Received: by 2002:a19:1d8c:: with SMTP id d134-v6mr1679230lfd.56.1529679777065; Fri, 22 Jun 2018 08:02:57 -0700 (PDT) Received: from [192.168.239.105] (83-245-237-65-nat-p.elisa-mobile.fi. [83.245.237.65]) by smtp.gmail.com with ESMTPSA id l25-v6sm1348398ljj.30.2018.06.22.08.02.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jun 2018 08:02:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Jonathan Morton In-Reply-To: <25305.1529678986@localhost> Date: Fri, 22 Jun 2018 18:02:55 +0300 Cc: bloat Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Michael Richardson X-Mailer: Apple Mail (2.3445.8.2) 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 15:02:58 -0000 > On 22 Jun, 2018, at 5:49 pm, Michael Richardson = wrote: >=20 >> 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. >=20 > 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? >=20 > 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? Behaviour suggests that it can be as soon as the MAC request is issued, = in response to the *first* packet arriving in the queue - so a second = TXOP is required for the *subsequent* packets arriving a microsecond = later, even though there's technically still plenty of time to reform = the aggregate then. 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. - Jonathan Morton