<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 21, 2018 at 10:18 AM Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Jun 21, 2018 at 5:55 AM, Eric Dumazet <<a href="mailto:eric.dumazet@gmail.com" target="_blank">eric.dumazet@gmail.com</a>> wrote:<br>
><br>
><br>
> On 06/21/2018 02:22 AM, Toke Høiland-Jørgensen wrote:<br>
>> Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>> writes:<br>
>><br>
>>> Nice war story. I'm glad this last problem with the fq_codel wifi code<br>
>>> is solved<br>
>><br>
>> This wasn't specific to the fq_codel wifi code, but hit all WiFi devices<br>
>> that were running TCP on the local stack. Which would be mostly laptops,<br>
>> I guess...<br>
><br>
> Yes.<br>
><br>
> Also switching TCP stack to always GSO has been a major gain for wifi in my tests.<br>
><br>
> (TSQ budget is based on sk_wmem_alloc, tracking truesize of skbs, and not having<br>
> GSO is considerably inflating the truesize/payload ratio)<br>
><br>
> <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a6b2a1dc2a2105f178255fe495eb914b09cb37a" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a6b2a1dc2a2105f178255fe495eb914b09cb37a</a><br>
> tcp: switch to GSO being always on<br>
><br>
> I expect SACK compression to also give a nice boost to wifi.<br>
><br>
> <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d9f4262b7ea41ca9981cc790e37cca6e37c789e" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d9f4262b7ea41ca9981cc790e37cca6e37c789e</a><br>
> tcp: add SACK compression<br>
><br>
> Lastly I am working on adding ACK compression in TCP stack itself.<br>
<br>
One thing I've seen repeatedly on mac80211 aircaps is a tendency for<br>
clients to use up two TXOPs rather than one.<br>
<br>
scenario:<br>
<br>
1) A tcp burst arrives at the client<br>
2) A single ack migrates down the client stack into the driver, into<br>
the device, which then attempts to compete for airtime on that TXOP<br>
for that single ack, sometimes waiting 10s of msec to get that op<br>
3) a bunch more acks arrive "slightly late"[1], and then get queued<br>
for the next TXOP, waiting, again sometimes 10s of msec<br>
<br>
(similar scenario in a client making a quick string of web related requests)<br>
<br>
This is a case where inserting a teeny bit more latency to fill up the<br>
queue (ugh!), or a driver having some way to ask the probability of<br>
seeing more data in the<br>
next 10us, or... something like that, could help.<br>
<br>
...<br>
<br>
[1] if you need coffee through your nose this morning, regarding usage<br>
of the phrase "slightly late", read<br>
<a href="http://www.rawbw.com/~svw/superman.html" rel="noreferrer" target="_blank">http://www.rawbw.com/~svw/superman.html</a><br>
<br>
-- <br>
<br>
Dave Täht<br>
CEO, TekLibre, LLC<br>
<a href="http://www.teklibre.com" rel="noreferrer" target="_blank">http://www.teklibre.com</a><br>
Tel: <a href="tel:(669)%20226-2619" value="+16692262619" target="_blank">1-669-226-2619</a><br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</blockquote></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Caleb Cushing<div><br></div><div><a href="http://xenoterracide.com">http://xenoterracide.com</a></div></div></div>