OpenWrt Funding/Make-Wifi-Fast on OpenWrt

Jump to: navigation, search


Wifi can become very congested and slow under load from slow stations or many.

FQ_Codel derived algorithms at the mac80211 layer are restoring good congestion control and network latency at low and medium rates for wifi, leading to a much better wifi experience under normal (rather than lab) conditions. ( )

Wifi is the last part of the last mile, for many, and it is important in the world of IoT and the ever increasing demands on Wifi that it continue to work well, with ever more stations and access points in range.

The advantages of "fq_codel at the 802.11 mac layer" can be the difference between a wifi connection that works, or not. We are observing 100x reductions in latency under load (a.k.a "bufferbloat) with the proof of concept code at 6Mbits (on ath10k), 25x reductions at 100Mbits vs the current ath9k driver (from 550ms to 25ms), and actual improvements in throughput at all but the highest MCS rates.

The make-wifi-fast project was founded to find more ways to make wifi work well, than just this ( ) , but getting this algorithm deep into all wifi stacks is the one with the most near-term promise. I discussed the top 7 problems in this talk at battlemeshv9:

The problem[edit]

Present funding for make-wifi-fast does not extend to testing openwrt integraton (backports), on the common hardware used in the openwrt project (presently the testbeds are all x86 + ath9k/ath10k on ubuntu.).

As we have already hit performance issues with the new code on openwrt based architectures but are unable to analyse them (lacking hardware, time, and funding)...

We propose to stress test and performance profile the upcoming "fq_codel at the mac wifi layer" patches for ath10k, ath9k, and mt72 on the pcengines apu2d platform, omnis turria, tp-link archer c7 v2, mt72, and another platform of choice (some 4x4?). This gives a good cross section of cpu architectures (x86, arm,mips,mips), and performance levels to analyze and improve.

We have already taken a hard look at the correctness of the code and other ongoing issues, primarily on high end x86 systems using older wifi cards. ( )


  • Will implementation of the project enhance the value of the community and/or improve the OpenWrt project, and be aligned with the goals of prplwrt industry members?
  • Does the broader OpenWrt community support the proposed solution? Or is there an important subset of the community which supports proposed solution?
  • Do core OpenWrt team members support proposed solution?
  • Do prplwrt members support the proposed solution?

All these questions are extremely hard to answer. I would hope that making for massively better wifi within the standards would have worldwide support, and that helping develop public and free algorithms that cut latency and jitter on many network loads by orders of magnitude, while often improving throughput, would have universal appeal.

Many openwrt members have participated in various derived efforts.

  • Does the implementer (or company/group) have a track record of delivering?

Yes. I have a hard time calling myself an implementer, however - I helped develop and explain the theory, analyze the code and results, find bugs, sometimes report them and sometimes fix them. In the entire history of the project I've only written one substantial body of code

- the first implementation of the codel algorithm ( ) for Linux - and while that was certainly the *right* piece of code, not a single line of that implementation survives after having been extensively tuned by others.

Everybody in the project contributes in various ways - from sage advice from the original creators of the Internet, to testing, documenting, and scripting, to outreach.

The closest I have for a title for myself at the moment is that I am filling the role of "architect" much of the time, and of the rest, "project manager", "chief bottle washer", and "nag", all come to mind.

A raging theorist that wants to turn a theoretical breakthrough into reality, by any means possible, is me. Having got some implementers finally on board my goal is to make sure the the implementation is correct, and performant, and we deal wiith new bugs, faster.

  • Is the proposed length of time for the project feasible?

Yes and no. We've been fixing bufferbloat for 5+ years now, there are no end of problems in sight. Getting these core fixes for wifi into openwrt's stack in the next few months seems quite feasible, getting it fully upstreamed, also, within this timeframe...

Wifi has many other problems that need to be addressed ( ), but getting the scheduling layer aqm'd and fq'd, as we hope to do in the coming months, blocks many of them.

  • Is the level of funding appropriate for the task to be accomplished?

The amount requested here is intended to join what has already been thrown in by Comcast Research, The NLNET foundation, CII, and individual donors. (Some of which was for "cake" and not wifi, although we've used cake to simulate wifi a lot). The total budget for this phase of the total project is only 1/3 met (130k so far ), and mostly spent. Big ticket items (like a larger testbed, programmable atennuators, better ns3 models, and so on, have already been dropped in favor of merely being able to full evaluate a working proof of concept, and test it thoroughly, while identifying other issues that might block deployment. ( )

Various other members of the project have their own sources of funding and/or interest.

  • Will the project be licensed under a free/open source software license? (use of an OSI or FSF-approved license is a requirement)

While we also attempt to produce a BSD license version of stuff we think makes networking better, and/or an internet draft, it is likely all code here will be GPLv2 (or GPLv2/BSD dual licensed). The Flent testing suite we use and plan to extend is under the GPLv3.


About the Bufferbloat project[edit]

Founded in early 2011, the objective was to make networks faster and responsive under load. We succeeded in those objectives. Algorithms developed and turned into usable code and tested include codel, pie, fq_codel, fq_pie, BQL, and many improvements to TCP. IETF standards for much of these have been produced and/or are in the process of finalization.

It's a big project (over 400 members on the mailing list), with many contributors to various aspects of the problems. As the remaining co-founder, I work on various pieces of it, full time, lending aid, evaluation, and architectural advice to many.

About CeroWrt[edit]

CeroWrt *was* an attempt to spin up new technolgies on an openwrt base, by making bleeding edge code more accessible and testable by more normal users.. The project ran from 2011-2014, with a long list of new techologies tested and/or pioneered there, and pushed first (after testing) into openwrt. Of note are fq_codel, sqm-scripts, and sch_cake. We also helped drive and test many ipv6 and routing enhancements into the openwrt core, improve comcast compatability, and so on.

Ironically, the original purpose of the project was to make wifi better - but we fixed a bunch of other problems instead, after disproving that two proposed algorithms would work. We later showed that fq_codel at the wifi layer would work but were unable to acquire sufficient resources (people/money) for the fork-lift upgrade to the stack that seemed required until recently.

it is hoped that closer integration with the lede project and various downstreams will eliminate the need to produce and QA regular independent builds of openwrt, and that members of the existing cerowrt userbase will join in on the testing, allowing us to focus harder on making the new algorithms work well on more hardware.

The cerowrt userbase remains very active in discussing and testing new ideas, hardware, and code, and rather than "fork" the userbase into make-wifi-fast, current developments limp along on the make-wifi-fast, cerowrt-devel, and cake mailing lists, as well as the blog pointed to multiple times in this proposal.

About Teklibre & Dave Taht[edit]

Teklibre was founded to make the Internet better, especially in parts of the world with poor infrastructure. Teklibre has long been a contributor to the openwrt build cluster, in particular, but exists primarily as Dave Taht's corporate face for dealing with larger entities.