From: Jonathan Morton <chromatix99@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: dstanley@arubanetworks.com,
Andrew McGregor <andrewmcgr@gmail.com>,
Stig Thormodsrud <stig@ubnt.com>,
netdev@vger.kernel.org,
linux-wireless <linux-wireless@vger.kernel.org>,
Jesper Dangaard Brouer <jbrouer@redhat.com>,
cerowrt-devel@lists.bufferbloat.net,
Matt Mathis <mattmathis@google.com>,
Derrick Pallas <pallas@meraki.com>,
Mahesh Paolini-Subramanya <mahesh@dieswaytoofast.com>,
Kathy Giori <kgiori@qca.qualcomm.com>,
Tim Shepard <shep@alum.mit.edu>,
Avery Pennarun <apenwarr@google.com>
Subject: Re: [Cerowrt-devel] Fwd: Throughput regression with `tcp: refine TSO autosizing`
Date: Sun, 1 Feb 2015 12:47:23 +0200 [thread overview]
Message-ID: <CAJq5cE3ETbpEtecFHmhgHQveNRUhVfrzjTOygHm-TRCTwHNyKA@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw7=oTex0Mp-0ThvuDRUnfR0N8tzdOQ8DD7QYWphp1b=4w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2975 bytes --]
Since this is going to be a big job, it's worth prioritising parts of it
appropriately.
Minstrel is probably already the single best feature of the Linux Wi-Fi
stack. AFAIK it still outperforms any other rate selector we know about. So
I don't consider improving it further to be a high priority, although that
trick of using it as a sneaky random packet loss inducer is intriguing.
Much more important and urgent is getting some form of functioning SQM
closer to the hardware, where the information is. I don't think we need to
get super fancy here to do some real good, in the same way that PIE is a
major improvement over drop-tail. I'd settle for a variant of fq_codel that
gets and uses information about whether the current packet request might be
aggregated with the previous packet provided, and adjusts its choice of
packet accordingly.
At the same time, models would undoubtedly be useful to help test and
repeatably demonstrate the advantages of both simple and more sophisticated
solutions. Ns3 allows laying out a reasonably complex radio environment,
which is great for this. To counter the prevalence of one-station Faraday
cage tests in the industry, the simulated environments should represent
realistic, challenging use cases:
1) the family home, with half a dozen client devices competing with several
interference sources (Bluetooth, RC toys, microwave oven, etc). This is a
relatively easy environment, representing the expected environment for
consumer equipment.
2) the apartment block, with fewer clients per AP but lots of APs
distributed throughout a large building. Walls and floors may provide
valuable attenuation here - unless you're in Japan, where they can be
notoriously thin.
3) the railway carriage, consisting of eighty passengers in a 20x3 m space,
and roughly the same number of client devices. The uplink is 3G based and
has some inherent latency. Add some Bluetooth for flavour, stir gently.
This one is rather challenging, but there is scope to optimise AP antenna
placement, and to scale the test down slightly by reducing seat occupancy.
4) the jumbo jet, consisting of several hundred passengers crammed in like
sardines. The uplink has satellite latencies built in. Good luck.
5) the business hotel. Multiple APs will be needed to provide adequate
coverage for this environment, which should encompass the rooms as well as
lounge, conference and dining areas. Some visitors may bring their own APs,
and the system must be able to cope with this without seriously degrading
performance.
6) the trade conference. A large arena filled with thousands of people.
Multiple APs required. Good luck.
I also feel that ultimately we're going to have to get industry on board.
Not just passively letting us play around as with ath9k, but actively
taking note of our findings and implementing at least a few of our ideas
themselves. Of course, tools, models and real-world results are likely to
make that easier.
- Jonathan Morton
[-- Attachment #2: Type: text/html, Size: 3211 bytes --]
next prev parent reply other threads:[~2015-02-01 10:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CA+BoTQkVu23P3EOmY_Q3E1GJnWsyF==Pawz4iPOS_Bq5dvfO5Q@mail.gmail.com>
[not found] ` <1422537297.21689.15.camel@edumazet-glaptop2.roam.corp.google.com>
[not found] ` <54CB5D08.2070906@broadcom.com>
[not found] ` <1422623975.21689.77.camel@edumazet-glaptop2.roam.corp.google.com>
[not found] ` <54CB8B69.1070807@broadcom.com>
[not found] ` <CAA93jw5fqhz0Hiw74L2GXgtZ9JsMg+NtYydKxKzGDrvQcZn4hA@mail.gmail.com>
2015-01-31 21:05 ` Dave Taht
2015-01-31 21:51 ` dpreed
2015-02-01 3:06 ` Avery Pennarun
2015-02-01 8:07 ` Andrew McGregor
2015-02-01 8:45 ` Dave Taht
2015-02-01 10:47 ` Jonathan Morton [this message]
2015-02-01 14:43 ` dpreed
2015-02-01 23:34 ` Andrew McGregor
2015-02-02 4:04 ` Avery Pennarun
2015-02-02 15:25 ` Jim Gettys
2015-02-02 4:21 ` Avery Pennarun
2015-02-02 7:07 ` David Lang
2015-02-02 16:22 ` dpreed
2015-02-02 18:29 ` David Lang
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/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJq5cE3ETbpEtecFHmhgHQveNRUhVfrzjTOygHm-TRCTwHNyKA@mail.gmail.com \
--to=chromatix99@gmail.com \
--cc=andrewmcgr@gmail.com \
--cc=apenwarr@google.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=dstanley@arubanetworks.com \
--cc=jbrouer@redhat.com \
--cc=kgiori@qca.qualcomm.com \
--cc=linux-wireless@vger.kernel.org \
--cc=mahesh@dieswaytoofast.com \
--cc=mattmathis@google.com \
--cc=netdev@vger.kernel.org \
--cc=pallas@meraki.com \
--cc=shep@alum.mit.edu \
--cc=stig@ubnt.com \
/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