From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 3CB943B2A4; Thu, 21 Jun 2018 11:18:09 -0400 (EDT) Received: by mail-qk0-x242.google.com with SMTP id j12-v6so1946496qkk.4; Thu, 21 Jun 2018 08:18:09 -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=kDOSIyy5LO/q1URotHHvCxiZYYJDfweZSLxf7bIPbjg=; b=oC4aIXl5WvEKjmcMEcO2cZtvUDEKLdzReo/VpRGtigXd2PFUt0My1BQQqXTOl32sFK eKwFiuVgGzuZW4ImkqLUDwli34f7omXGUp1zZsGmKY1QSFyJRPG9OTIpqSTOf4NTyX7S MIsAmjcBHsLZY38N4dyrExtfiSz+fwe0iazzCuB4Dc+N1n/bXmLsVKx8jFhUl3nkLWxN Q86Mmw905kIWPcU+sf8/h9hysjcjHbeqVZORaRUi4WhXhvIqZ+vHPNZqcxcIuRm2Xcqd XVLBC2C9pxoumLlHyf8SR73OH2KqVitJ59iWSbhrzz97KswAuN6uPWKBcVhRTVtpOKYf Opnw== 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=kDOSIyy5LO/q1URotHHvCxiZYYJDfweZSLxf7bIPbjg=; b=rgjT8QFva53g4YMxNEwjDhkOc+NUxR2MPNWoTa9N3AGPo6yxFDlBASvTs15VK/SiST nF/iZmu4hapSDOJIeWgXFa2aeUDfrzYyro8N8Y9VUqV6l39Gcpek7KrIQyaWuBD48qNw vpRPzrux/yNut2whsSZMUnRTVD8Ww4TZHhS/2BkHFBuWBIKhkQxaNrGWfpLoJiGWiMXA o0wSAf3FiaHr13Aan9EZB0b1+RCoqpRDJpHccGgplnVOUnFETKAYMorQFhICBZVMV/z8 aPJTp7MDtG0ALxg7mQsNbyeWkc2GYfJXFfhvZkTUoKf7XxqzHmvVEMCLZNHi6UXZkxDq 5Ypw== X-Gm-Message-State: APt69E2NU6tfP8Ydcq5H1V7FOl56guyF3V1BsD/fMgtqbcjFZQarQqb0 KaInZimh++rnVL3Lq0yO3MOzE3TP0tWZqJswDgI= X-Google-Smtp-Source: ADUXVKKcG4d6g7HoteCFiPVL5YnpJbW+ZqZsYigPw+5Xx11hoI4HCB1DzDylptn+qcp33l2lnsyadlfCd8DUoJl6Hus= X-Received: by 2002:a37:21e6:: with SMTP id f99-v6mr2624249qki.206.1529594288564; Thu, 21 Jun 2018 08:18:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:24f0:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 08:18:07 -0700 (PDT) In-Reply-To: <838b212e-7a8c-6139-1306-9e60bfda926b@gmail.com> References: <8736xgsdcp.fsf@toke.dk> <838b212e-7a8c-6139-1306-9e60bfda926b@gmail.com> From: Dave Taht Date: Thu, 21 Jun 2018 08:18:07 -0700 Message-ID: To: Eric Dumazet Cc: bloat , Make-Wifi-fast Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Thu, 21 Jun 2018 15:18:09 -0000 On Thu, Jun 21, 2018 at 5:55 AM, Eric Dumazet wrot= e: > > > On 06/21/2018 02:22 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> Dave Taht writes: >> >>> Nice war story. I'm glad this last problem with the fq_codel wifi code >>> is solved >> >> This wasn't specific to the fq_codel wifi code, but hit all WiFi devices >> that were running TCP on the local stack. Which would be mostly laptops, >> I guess... > > Yes. > > Also switching TCP stack to always GSO has been a major gain for wifi in = my tests. > > (TSQ budget is based on sk_wmem_alloc, tracking truesize of skbs, and not= having > GSO is considerably inflating the truesize/payload ratio) > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit= /?id=3D0a6b2a1dc2a2105f178255fe495eb914b09cb37a > tcp: switch to GSO being always on > > I expect SACK compression to also give a nice boost to wifi. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit= /?id=3D5d9f4262b7ea41ca9981cc790e37cca6e37c789e > tcp: add SACK compression > > Lastly I am working on adding ACK compression in TCP stack itself. One thing I've seen repeatedly on mac80211 aircaps is a tendency for clients to use up two TXOPs rather than one. scenario: 1) A tcp burst arrives at the client 2) A single ack migrates down the client stack into the driver, into the device, which then attempts to compete for airtime on that TXOP for that single ack, sometimes waiting 10s of msec to get that op 3) a bunch more acks arrive "slightly late"[1], and then get queued for the next TXOP, waiting, again sometimes 10s of msec (similar scenario in a client making a quick string of web related requests= ) This is a case where inserting a teeny bit more latency to fill up the queue (ugh!), or a driver having some way to ask the probability of seeing more data in the next 10us, or... something like that, could help. ... [1] if you need coffee through your nose this morning, regarding usage of the phrase "slightly late", read http://www.rawbw.com/~svw/superman.html --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619