Re: [Bloat] lwn.net's tcp small queues vs wifi aggregation solved

[Caleb Cushing <xenoterracide@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2785 bytes --]

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.

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 <(669)%20226-2619>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
-- 
Caleb Cushing

http://xenoterracide.com

[-- Attachment #2: Type: text/html, Size: 4279 bytes --]