[Make-wifi-fast] AREDN and Make Wifi Fast

Sat Feb 6 12:44:37 EST 2016

All:

The AREDN project is doing very good stuff and seeing many of the same
issues in wifi as we see, they use nearly all the same hardware we did,
and have expertise to share....

http://www.aredn.org for more details

Trevor:

On 2/3/16 6:37 AM, Trevor Paskett wrote:
> Dave I talked with the AREDN group last night and we decided it was worth taking some time and looking / learning the driver to be able to at least quantify what the effort is to pull this off.

Groovy!

We have quite a bit of knowledge on the ath9k chipset, diagrams of how
it and the 80211 stack fit together, but it's not up anywhere.

now... as I am working to finally get make-wifi-fast off the ground in a
month or two more... I'm stuck on committing on some infrastructure
methods. Anyone have preferences here?:

In my case I've been mostly trying to find working methods for our
far-flung group that could replace redmine (which is how we stuck
together the bloat and cerowrt projects for 5 years).

The world has shifted to github (love the SSO, hate that level of
centralization, gittorrent looks neat), we used to use irc heavily, I
used to have linux be my main box in front of me, now I'm using virtual
machines but will probably go buy some new hardware, I have a strong
liking for a static site generator like hugo, and other flailings like:

Email lists themselves seem to have become passe' - the "discourse"
engine seems like a good idea - but I LIKE email.

I also tend to prefer store and forward chat systems like jabber, but
again, irc (+bitlebee or znc) is how the world seems to work.

My whole life used to integrate into emacs, and I was tons more
productive that way.

At the moment I'm thinking of just sticking with redmine, using github
more effectively, going back to irc, staying with email lists.

> I ordered a x86 dev unit to work on. Once that is here I’ll start looking at the driver and code and figure out what it is doing now. Now granted I don’t know how this stuff works under the hood yet, but could we just dumb down the driver? I mean if the driver did not have it’s own queues and when it was asked to xmit it would *block* more when it could not transmit more like an ethernet driver would that give the back pressure needed for fq_codel to do it’s magic where it currently is in the stack?

There's also been some recent discussion on linux-wireless on these\
issues. Yes, "dumbing down the driver and firmware" makes sense, however
having some key features propagate up the stack also makes sense.

Your take on the essential flow control needed at that layer of the
stack is basically correct. Theoretically we could get to one aggregate
in the hardware, one in the driver, and one waiting to go on the
completion interrupt.

> Also if you give give me a list of flent tests that I can run to expose the problem with wifi that I can run on my dev box that would be helpful. Then I can start playing with code to see where things are getting backed up.

rrul was designed to thoroughly break wifi, and gets you the mostest
data fastest. Breaking that apart simpler tests like

rrul_be
tcp_upload
tcp_download

give more focused detail. So I typically have a script that runs those.
4 minutes later I have a starting point.

I note that the "best" topology for driving wifi while testing a chipset
on a given AP is

testclient -> ethernet -> AP -> AP -> ethernet -> testserver

because chipsets on wifi clients tend to suck in different ways. (like
the sith, there are always two devices in the loop)

Certainly I regularly do tests from my laptop(s) (iwl, osx) also,
directly to the AP... and I have some hope for a set of iwl patches that
went by on the list this week.

lastly, people perpetually test wifi under "lab" conditions, I try to do
it mostly under bad conditions from 20 feet away through a wall -
because that's the most annoying set of behaviors. Some level of
semi-repeatably "bad" conditions... what I dream of is having tons of
testers all with a different semi-repeatably "bad" condition to run 5
minutes of testing through regularly with each new build.

Finally:

The rtt_fair series of tests in flent are the ones most suited for
growing into testing per-station queueing fixes, presently. We need to
start capturing more per-station data wifi with them.

However, you need more than one station setup in your topology,

testpeer0 -> ethernet -> AP - testpeer1
                             - testpeer2
                             - testpeer3
                             - testpeer4

(there is not a huge difference between a "client and server" in flent,
most tests are bi-directional, the "client" needs to have python on it,
the servers just need a fairly recent netperf and (if you feel
ambitious) things like d-itg to simulate voip.

> 
> I’ll try installing SQM on my firewall and try it out.

I really want to get people to understand deeply what a "good result"
is... before buying into the gospel! Sometimes I think that's too much
to want... but...

a *metric ton* of people have been blaming wifi for their bufferbloat
problems when it is really the ISP connection to blame first. Now that
downlink speeds have cracked 20Mbit generally, however, the bloat and
bad behavior is shifting to wifi, generally. So please try fiddling with
your internet uplink(s) first.

I look forward to hearing about your gaming results. ;)

>> On Feb 2, 2016, at 5:59 PM, Dave Täht <dave at taht.net> wrote:
>>
>> https://github.com/tohojo/sqm-scripts
>>
>> is mostly at the point where it's do a git pull and run on mainline linux.
>>
>> But I encourage you to measure your latency under load rrul test with
>> flent first. Or dslreports.
>>
>>
>>
>> http://www.bufferbloat.net/projects/codel/wiki/Cake
>>
>> has install and config instructions for cake.
>>
>>
>>
>> On 2/2/16 2:28 PM, Trevor Paskett wrote:
>>> Yeah that will work.
>>>
>>>> On Feb 2, 2016, at 3:29 PM, Dave Täht <dave at taht.net> wrote:
>>>>
>>>> grump. except for what ended up  being a long lunch.
>>>>
>>>> 4PM PDT?
>>>>
>>>> On 2/2/16 12:03 PM, Trevor Paskett wrote:
>>>>> How about 1 hour from now @ 1 PM PDT? Call me on my cell 801-953-5082 or we can do a google hangout.
>>>>>
>>>>>> On Feb 2, 2016, at 12:06 PM, Dave Täht <dave at taht.net> wrote:
>>>>>>
>>>>>> I am sorry, trevor, monday was hell. I have time today (I am in PDT) to
>>>>>> chat at length anytime from now til 10pm.
>>>>>>
>>>>>> On 1/29/16 8:59 AM, Trevor Paskett wrote:
>>>>>>> Yeah Joe one of our core dev’s was there. I’m watching your presentation now. You have time for a google hangout today / Monday?
>>>>>>>
>>>>>>>> On Jan 28, 2016, at 3:06 PM, Dave Täht <dave at taht.net> wrote:
>>>>>>>>
>>>>>>>> Note primary email address.
>>>>>>>>
>>>>>>>> Were you guys just at scale? I seem to remember passing a booth and
>>>>>>>> talking to someone....
>>>>>>>>
>>>>>>>> On 1/28/16 1:44 PM, Dave Taht wrote:
>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>> From: Trevor Paskett <snoopytjp at gmail.com>
>>>>>>>>> Date: Thu, Jan 28, 2016 at 1:42 PM
>>>>>>>>> Subject: AREDN and Make Wifi Fast
>>>>>>>>> To: dave.taht at gmail.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Dave,
>>>>>>>>>
>>>>>>>>> I have read a lot of your work at bufferbloat.net. Great stuff and
>>>>>>>>> thanks for having the initiative to help the networking world out.
>>>>>>>>
>>>>>>>> Well, honestly, my initiative is at a low ebb.
>>>>>>>>
>>>>>>>>> I’m a core developer for the AREDN project: http://www.aredn.org
>>>>>>>>
>>>>>>>> It is cool stuff and exactly why I got involved in adhoc networks so
>>>>>>>> many years ago.
>>>>>>>>
>>>>>>>>> AREDN is mesh networking software for HAM radio operators that is
>>>>>>>>> based on OpenWRT. There are hundreds and hundreds of nodes running
>>>>>>>>> around the world with our software. We have been researching ways to
>>>>>>>>> implement a level of QOS in the firmware to prevent HAM’s from
>>>>>>>>> congesting the RF channel and preventing emergency traffic from
>>>>>>>>> getting through. I have a bit of experience with linux QOS using HTB,
>>>>>>>>> SFQ, etc. These do not seem to be the right tools to use for our RF
>>>>>>>>> based / shared medium use case.
>>>>>>>>>
>>>>>>>>> Basically we have 4 types of traffic that needs to be prioritized /
>>>>>>>>> handled: (in order or priority)
>>>>>>>>>
>>>>>>>>> Web UI, and OLSR routing protocol traffic
>>>>>>>>> Traffic destined to designated priority stations (ie hospital, city
>>>>>>>>> emergency comm center)
>>>>>>>>> Traffic marked as high priority / TOS (voip, etc).
>>>>>>>>> Everything else
>>>>>>>>
>>>>>>>> What you basically need is effective backpressure from the wireless
>>>>>>>> device, then layering something like cake on top will do what you want.
>>>>>>>>
>>>>>>>> no wireless device has enough backpressure right now that I know of. The
>>>>>>>> hope is to fix that - did you see the battlemesh preso?
>>>>>>>>
>>>>>>>> https://www.youtube.com/watch?v=Rb-UnHDw02o
>>>>>>>>
>>>>>>>> after a bit of funding - any funding at all - arrived. A bit is arriving
>>>>>>>> in march, enough for me to cut $DAYJOB down by a lot for a few months at
>>>>>>>> least.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Would you be willing to chat? I think we could collaborate on this
>>>>>>>>> together and our combined work would help both our causes. We have
>>>>>>>>> several developers that are very familiar with 802.11 / ath9k and tons
>>>>>>>>> of gear and beta test environments. I think any QOS improvements that
>>>>>>>>> were made that benefit AREDN, would also benefit Make Wifi Fast.
>>>>>>>>
>>>>>>>> I agree. And you dropping out of the blue today really cheered me up.
>>>>>>>>
>>>>>>>> I half-joke: after the grueling last 8 months of the cerowrt project, I
>>>>>>>> have PTFD - post traumatic flashing disorder. My desire to reflash stuff
>>>>>>>> day in and day out while working deep in the linux kernel, is nearly nil
>>>>>>>> - so toke and I established an x86 based ath9k wifi testbed back in
>>>>>>>> december, and we could share that as we iterate over to the embedded
>>>>>>>> platforms?
>>>>>>>>
>>>>>>>> We've got most of the core algos worked out, we have good testing tools,
>>>>>>>> we have two testbeds, toke and a few others... and not a single line of
>>>>>>>> kernel code yet written.
>>>>>>>>
>>>>>>>>> Thanks for your consideration and time.
>>>>>>>>
>>>>>>>> I am back in SF, where are you based? And can do a videoconference
>>>>>>>> (but am behind a buggy wifi router right now tweaking my PTFD!)
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Trevor Paskett
>>>>>>>>> K7FPV
>>>>>>>>>
>>>>>>>
>>>>>
>>>
> 