Lets make wifi fast again!
 help / color / mirror / Atom feed
From: Pete Heist <peteheist@gmail.com>
To: make-wifi-fast@lists.bufferbloat.net
Subject: [Make-wifi-fast] Testing airtime fairness and other "make wifi fast" project code
Date: Mon, 31 Oct 2016 18:18:51 +0100	[thread overview]
Message-ID: <C3265748-007B-496D-AA6D-B2CFF9CB971B@gmail.com> (raw)

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

Question: What kind of testing is most needed or useful for the airtime fairness code and related work in the make WiFi fast project? And, is it best to post any results to this mailing list?

Test Environment: I’ve got a single spare OM2Pv1 AP with the head of LEDE as of today installed (r2032). I’ve got two MacBook Pros available as clients. I could do some flent or iperf3 runs, or other testing.

Background: I’m evaluating LEDE to improve the WiFi setup at an outdoor camp, both the WiFi LAN and point-to-point WiFi Internet uplink. So the testing I’m doing is also for us, to see if any improvements can be made.

For the LAN, we’re currently running Open Mesh firmware on a 7 node mesh network (4 gateways and 3 repeaters, a mixture of OM2Pv2 and OM2P-HS APs).  The goal is to try to improve roaming, reduce latency and provide airtime fairness, as clients connect at a mixture of data rates. With up to 150 clients connected (10-15 people doing “something”, at times), things can be rather “active”, as it were. Latency can suffer.

For the WAN, our WISP uses Routerboard 911-5HnD's for the point-to-point devices (Atheros AR9300 chipset, running RouterOS 6.34.6, probably Linux kernel 3.3.5). I’m not sure I’ll be able to change that, so I don’t think I can run any “make wifi fast" code here today, unless a backport is done to this rather prehistoric kernel version. Our Internet connection is advertised as "40 Mbps symmetric with 1:3 aggregration”, but after real world testing what that really means for us is 8 - 25 Mbps symmetric, depending on the time of day. With this kind of variable data rate, it doesn’t make much sense to do rate limiting, so I don’t see how we can run HTB+fq_codel in the same way we did with our old ADSL connection. But I’m holding out hope that one day we’ll get queue management this good in the WiFi driver itself, somehow.

PS- I was sorry to miss the recent OpenWRT summit in Berlin, for the Speeding up WiFi presentation, but the conference filled up before I could register. I’m glad this great session was made available online (https://youtu.be/fFFpo_2xlfU?list=PL3bvPCw5QCLJ0xR1oXui6M7QBh6UElgvn <https://youtu.be/fFFpo_2xlfU?list=PL3bvPCw5QCLJ0xR1oXui6M7QBh6UElgvn>). Nice work!

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

                 reply	other threads:[~2016-10-31 17:18 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C3265748-007B-496D-AA6D-B2CFF9CB971B@gmail.com \
    --to=peteheist@gmail.com \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox