<div dir="ltr"><div dir="ltr">Thanks for the feedback!</div><div dir="ltr"><br></div><div>Some comments and questions added inline.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 4 Feb 2020 at 18:07, Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Feb 4, 2020 at 7:25 AM Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>> wrote:<br>
><br>
> > On 4 Feb, 2020, at 5:20 pm, Bjørn Ivar Teigen <<a href="mailto:bjorn@domos.no" target="_blank">bjorn@domos.no</a>> wrote:<br>
> ><br>
> > Are there any plans, work or just comments on the idea of implementing cake in mac80211 as was done with fq_codel?<br>
><br>
> To consider doing that, there'd have to be a concrete benefit to doing so.<br>
<br>
Research is research! :) Everything is worth trying! There's got to be<br>
some better ideas out there, and we have a long list of things we<br>
could have done to keep improving wifi had funding not run out.<br>
<br>
We barely scratched the surface of this list.<br>
<br>
<a href="https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit</a><br>
<br>
> Most of Cake's most useful features, beyond what fq_codel already supports, are actually implied or even done better by the WiFi environment and the mac80211 layer adaptation (particularly airtime fairness).<br>
<br>
In my opinion(s)<br>
<br>
A) I think ack-filtering will help somewhat on 802.11n, but it's not<br>
worth the added cpu cost on an AP and I'd prefer hosts reduce their<br>
ack load in the tcp stack (IMHO, others may differ, it's worth trying)<br>
B) The underlying wifi scheduler essentially does per host fq better<br>
than cake can (because it's layer 2 vs layer 3), as per jonathan's<br>
comment above   </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
C) Instead of using a 8 way set associative hash and 1024 queues,<br>
fq_codel for wifi uses 4096 with a disambiguation pointer for<br>
collisions. Seems good enough.<br></blockquote><div> </div><div>Didn't catch that before. Are the extra queues there because of the different access categories on Wi-Fi? Seems like that would mean most of them are not in use considering how little traffic is marked with DSCP.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
D) "cobalt" is proving out better in several respects than pure codel,<br>
and folding in some of that makes sense, except I don't know which<br>
things are the most valuable considering wifi's other problems<br></blockquote><div><br></div><div>Reading paper now. Thanks for the pointer.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
E) I'd like to dynamically increase the quantum size as a function of<br>
load or number of flows. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
I'd really like benchmarks of the proprietary versions coming out.<br>
Qualcomm has their own fq_codelish thing baked into their firmware<br>
now... I have no idea what broadcom is doing... fq-pie?<br></blockquote><div><br></div><div>I've started looking at benchmarking proprietary drivers with emphasis on queueing performance. If you have any tips, or if you would like to co-author a paper (I'm working on a PhD), I am very interested.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The librerouter is now available. I'd like to try that.<br>
<br>
Recently I benchmarked red rock cafe in mountain view, which had the<br>
best bufferbloat and rrul score of any cybercafe I'd ever tried - they<br>
have a mojo networks AP, which arista bought a while back. It was<br>
lovely.... I have no idea what they do,<br>
but whatever it was it was *good*. I'm really happy see bufferbloat<br>
getting fixes everywhere, but really need to add quic to the benchmark<br>
suite somehow in order to feel better about people not rewriring tcp<br>
headers to do what they want.<br>
<br>
more importantly:<br>
<br>
Would really like to get cracking on a wifi 6 version. So far, all the<br>
vendors are lying, there is no OFDMA support in anything we've played<br>
with. There are some new outer limits there (1000+ devices), a need to<br>
do gang scheduling, and per-station firmware, and I'm<br>
profoundly unimpressed with proprietary vendor's efforts so far and<br>
wish they'd open up their firmware more so more of us could take a<br>
crack at it....<br></blockquote><div> </div><div>I agree, there are some interesting problems arising there. Interested to follow the work if and when this happens. Any luck finding a company willing to work on open-source drivers for Wi-Fi 6?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I'd really like to get the intel  (iwl) version, especially the ax200<br>
chips, ported over to the AQL + fq_codel interfaces, at least.  The<br>
first attempt went badly, last quarter. Needs eyeballs and time...<br>
Would like to find some other wifi chip worth fixing - raspi 4? Some<br>
android wifi chip? what?<br>
Don't know how the ath11k effort is going...<br>
<br>
In mainline...<br>
 I'd like to get the wifi codel target on 5ghz down from 20ms (too<br>
much) to 10ms, (or as I run it here to 8ms) in mainline, or at least<br>
openwrt, but that would require some benchmarking by multiple folk,<br>
and I was waiting for the ath10k ATF code to go upstream first. At<br>
least make it tunable.<br></blockquote><div><br></div><div>Have done some testing myself and 10ms looks like the correct limit on 5GHz.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Overall, reducing hw retries to sanity would be a nice thing to<br>
attempt in the ath9k, at least. Although the ongoing SCE work (gradual<br>
rate reduction) is interesting, I tend to think reducing hardware<br>
retries (with increased loss) would have a more dramatic effect on<br>
reducing wifi latencies.<br>
Presently with the codel target of 20ms in both directions, I get<br>
60-80ms tcp latencies (still better than most fiber!) over wifi with a<br>
20ms target at 70mbits. What happens at 300+, no idea. cynically I<br>
think much of the internet is essentially running at a max rwind or<br>
swind rather than within athe sawtooth.<br></blockquote><div><br></div><div>Also interesting<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
doing something more sane to rate limit multicast would be good also.<br>
It was quite the long list in that google document, back in the day we<br>
thought the wifi industry might decide to collaborate in order to meet<br>
the 5G threat.<br>
<br>
> a Cake instance to the wifi interface as well, if you have a need to do so.<br>
<br>
It certainly is feasible to do that. I do that now on several 802.11ac<br>
devices that don't have the fq_codel for wifi hooks, preferring to<br>
rate limit them well below capacity so as to ensure consistent low<br>
latency. It's really neat to see people able to play world of warcraft<br>
and other games over<br>
the wifi here. ( started deploying ubnt's uap mesh products, reflashed<br>
with openwrt, along portions of my wifi backbone . Looking forward to<br>
the AQL backport for those, but I hope someone else does it)<br></blockquote><div><br></div><div>Have this setup at home and it really does make a difference, even with just normal browsing. Has bigger impact than I would have guessed!<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
><br>
>  - Jonathan Morton<br>
> _______________________________________________<br>
> Cake mailing list<br>
> <a href="mailto:Cake@lists.bufferbloat.net" target="_blank">Cake@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/cake</a><br>
<br>
<br>
<br>
-- <br>
Make Music, Not War<br>
<br>
Dave Täht<br>
CTO, TekLibre, LLC<br>
<a href="http://www.teklibre.com" rel="noreferrer" target="_blank">http://www.teklibre.com</a><br>
Tel: 1-831-435-0729<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Bjørn Ivar Teigen</div><div>Head of Research<br></div>Domos, Machine Learning for the Home<br><a href="http://www.domos.no" target="_blank">www.domos.no</a><br></div></div></div></div></div></div></div>