Lets make wifi fast again!
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Caleb Cushing <xenoterracide@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	 Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] [Bloat] lwn.net's tcp small queues vs wifi aggregation solved
Date: Thu, 21 Jun 2018 08:50:30 -0700	[thread overview]
Message-ID: <CAA93jw7ST2FGqg8zwhG8xY6JXfNmtbsYGbuS5UwPYgAK2WEn6w@mail.gmail.com> (raw)
In-Reply-To: <CAAHKNRGu_WJFWtk7HY8JD9BGFnc-GZifkZ8VRG1HaVg9SwkUFA@mail.gmail.com>

On Thu, Jun 21, 2018 at 8:31 AM, Caleb Cushing <xenoterracide@gmail.com> wrote:
> 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 <dave.taht@gmail.com> wrote:
>>
>> On Thu, Jun 21, 2018 at 5:55 AM, Eric Dumazet <eric.dumazet@gmail.com>
>> wrote:
>> >
>> >
>> > On 06/21/2018 02:22 AM, Toke Høiland-Jørgensen wrote:
>> >> Dave Taht <dave.taht@gmail.com> 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=0a6b2a1dc2a2105f178255fe495eb914b09cb37a
>> > 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=5d9f4262b7ea41ca9981cc790e37cca6e37c789e
>> > 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äht
>> 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



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

  parent reply	other threads:[~2018-06-21 15:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-21  4:58 [Make-wifi-fast] " Dave Taht
2018-06-21  9:22 ` [Make-wifi-fast] [Bloat] " Toke Høiland-Jørgensen
     [not found]   ` <838b212e-7a8c-6139-1306-9e60bfda926b@gmail.com>
2018-06-21 15:18     ` Dave Taht
2018-06-21 15:31       ` Caleb Cushing
2018-06-21 15:46         ` Stephen Hemminger
2018-06-21 17:41           ` Caleb Cushing
2018-06-21 15:50         ` Dave Taht [this message]
     [not found]       ` <8f80b36b-ef81-eadc-6218-350132f4d56a@pollere.com>
     [not found]         ` <CAA93jw7R2+yogxMHJWaS6vMwzeJUOfq9T7MWNg0JQfBcEm=0CQ@mail.gmail.com>
     [not found]           ` <9dbb8dc8-bec6-8252-c063-ff0ba5fd7c1a@pollere.com>
     [not found]             ` <C03B3E60-FD68-46BC-930F-143879904767@gmail.com>
     [not found]               ` <25305.1529678986@localhost>
     [not found]                 ` <47EC21F5-94D2-4982-B0BE-FA1FA30E7C88@gmail.com>
     [not found]                   ` <18224.1529704505@localhost>
     [not found]                     ` <87muvjnobj.fsf@toke.dk>
     [not found]                       ` <CAGhGL2BAnd7LAncKoK=1rWcTZTqpZo33BKOTFrNmrHzin2B8Vw@mail.gmail.com>
     [not found]                         ` <68C3BBE1-96DA-41F7-9878-582074C4E769@gmail.com>
     [not found]                           ` <alpine.DEB.2.02.1806251716290.10496@nftneq.ynat.uz>
     [not found]                             ` <642CBFAE-A182-4D6E-968B-411159CBFD9B@superduper.net>
     [not found]                               ` <422BFE8C-1AAC-4A55-AF1F-448B3B5C0E28@gmail.com>
2018-06-26  1:27                                 ` Dave Taht
2018-06-26  3:30                                   ` Simon Barber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw7ST2FGqg8zwhG8xY6JXfNmtbsYGbuS5UwPYgAK2WEn6w@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=eric.dumazet@gmail.com \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=xenoterracide@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox