From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 AD9363B2A4; Thu, 21 Jun 2018 11:50:32 -0400 (EDT) Received: by mail-qk0-x243.google.com with SMTP id a195-v6so2012518qkg.3; Thu, 21 Jun 2018 08:50:32 -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=VCg4E0UYf/n+Ud2aX4Kb7Vmt5rViYQ2rShN/RptrhRI=; b=aJKkmn1Ziw4FL8cqavPNhjY2BeBzoyjzRL2nwLtQASU2XBzcV6SY6jhGLpLXTgNksa JEOA8zz7wgOz+0V1aRW0LfLc9mqcGstE9QY5orBloaOjg6UpewQn/THAwpmcHc6mCJ1X ejYArBW0QX7uMhRKoqKPyf2xVNoU6fyg/yRD54g4He2zutINrrgKBsCSv5pt40t/fe+y ebVj5RdltcpTq1RMLMC+XSllFLqFJqP94UMwGJZATQSqCKCxUE4F8u510YJt0544OT/X DdtZZre8xXY83sWbx6SltqrdJ7RoAVSPdVhRFO6ZpwBiGykxNpxxkpDgbtZybzksgL36 frSA== 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=VCg4E0UYf/n+Ud2aX4Kb7Vmt5rViYQ2rShN/RptrhRI=; b=S1eE2/pvI7sAl2uq7/6wO9wXfP0SwGigiAvDGE1kovT+3ZkbzM59GIC/GjYLe76m/5 zHsVB0WrNyC8U8zIi6Lm2tx6lMlto7VaGmZt9wlNjH6JO3p4ShPRK9f876VuAg5IbxDl Wx0vpWXlw6ssS//JXuDAT4lsY7f9VWfT/VbvB/FnOGbwM8xG+i65BbE2WQ5uW+KgFett K8Y+lxXGE2b5m/++75UNNOH5NbcSzficdXqUEvADV8513J3hVuRPsWv5L4tRANF/47M8 T8GG6YNYHPaapyc+fuP9dB8nu8JaiMUN8n1hd5v4PyoVkqTpSnJGsBadoGc7V8VUfIDk g3HA== X-Gm-Message-State: APt69E1G6e8NsKp+R/5ctV6t3MKqFUJ+xjlA2G2ewDf049PHMYHyDhLP OcLdKZWqwcop44XAbSGrElOtWfTnnRdjF5sUZ8Q= X-Google-Smtp-Source: ADUXVKK6fcmwOTVp9u2NCIDqKQHPkGR7FDnAk3qhGPXLJ89ByIB/QY1eWOIQx9FUz77ZK64NmbuMk3izFcP3BYjravc= X-Received: by 2002:a37:c403:: with SMTP id d3-v6mr21445733qki.190.1529596231929; Thu, 21 Jun 2018 08:50:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:24f0:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 08:50:30 -0700 (PDT) In-Reply-To: References: <8736xgsdcp.fsf@toke.dk> <838b212e-7a8c-6139-1306-9e60bfda926b@gmail.com> From: Dave Taht Date: Thu, 21 Jun 2018 08:50:30 -0700 Message-ID: To: Caleb Cushing Cc: Eric Dumazet , Make-Wifi-fast , bloat 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: Thu, 21 Jun 2018 15:50:32 -0000 On Thu, Jun 21, 2018 at 8:31 AM, Caleb Cushing wr= ote: > actually... all of my devices, including my desktop connect through wifi > these days... and only one of them isn't running some variant of linux. Yes the tendency of manufacturers to hook things up to the more convenient, but overbuffered and less opaque USB bus has become an increasingly large problem (canonical example - raspberry pi). In the case of LTE, especially, everything is a USB dongle, and the CDC_ETH driver and device spec actually mandates at least 32k of on-chip buffering on the other side of the bus. We had tried at one point (5 years ago) to find ways to apply something BQL-like to this but failed. I am currently getting miserable performance out of the one LTE dongle I have (16K/sec up) but have not gone and fiddled with it with more modern kernels. I ended up just tethering via an android phone, which cracks 1mbit up. The quality of the wifi drivers for USB is almost uniformly miserable, and out of tree. > > On Thu, Jun 21, 2018 at 10:18 AM Dave Taht wrote: >> >> On Thu, Jun 21, 2018 at 5:55 AM, Eric Dumazet >> wrote: >> > >> > >> > 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 co= de >> >>> 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/com= mit/?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/com= mit/?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 >> >> -- >> >> Dave T=C3=A4ht >> CEO, TekLibre, LLC >> http://www.teklibre.com >> Tel: 1-669-226-2619 >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat > > -- > Caleb Cushing > > http://xenoterracide.com --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619