General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Rich Brown <richb.hanover@gmail.com>
To: David Lang <david@lang.hm>
Cc: Hal Murray <halmurray+mwf@sonic.net>,
	Starlink <starlink@lists.bufferbloat.net>,
	Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Real-world testing: wifi8 and 802.11 wg
Date: Mon, 2 Sep 2024 11:04:17 -0400	[thread overview]
Message-ID: <72A40762-6A00-42B2-83AA-5ABD4F02634B@gmail.com> (raw)
In-Reply-To: <13so850r-s23q-r0sp-0nqp-ss9q2q522542@ynat.uz>

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


How can this message be flagged as an important "stake in the ground" re: testing of Wi-Fi for common/useful situations? Thanks, David...

> On Sep 2, 2024, at 1:05 AM, David Lang via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> 
> I'll start off by saying that my experience is from practical in-the-field uses, deploying wifi to support thousands of users in a conference setting. It's possible that some people are doing the tests I describe below in their labs, but from the way routers and wifi standards are advertised and the guides to deploy them are written, it doesn't seem like they are.
> 
> My belief is that most of the tests are done in relatively clean RF environments where only the devices on the test network exist, and they can always hear everyone on the network. In such environments, everything about existing wifi standards and the push for higher bandwidth channels makes a lot of sense (there are still some latency problems)
> 
> But the world outside the lab is far more complex
> 
> you need to simulate a dispursed, congested RF environment. This includes hidden transmitters (stations A-B-C where B can hear A and C but A and C cannot hear each other), dealing with weak signals (already covered), interactions of independent networks on the same channels (a-b and c-d that cannot talk to each other), legacy equipment on the network (as slow as 802.11g at least, if not 802.11b to simulate old IoT devices), and a mix of bulk-transfers (download/uploads), buffered streaming (constant traffic, but buffered so not super-sentitive to latency), unbuffered streaming (low bandwidth, but sensitive to latency), and short, latency sensitive traffic (things that block other traffic until they are answered, like DNS, http cache checks, http main pages that they pull lots of other URLs, etc)
> 
> test large number of people in a given area (start with an all wireless office, then move on to classroom density), test not just one room, but multiple rooms that partially hear each other (the amount of attenuation or reflection between the rooms needs to vary). The ultimate density test would be a stadium-type setting where you have rows of chairs, but not tables and everyone is trying to livestream (or view a livestream) at once.
> 
> Test not just the ultra-wide bandwidth with a single AP in the rooms, but narrower channels with multiple APs distributed around the rooms. Test APs positioned high, and set to high power to have large coverage areas against APs positioned low (signals get absorbed by people, so channels can be reused at shorter distances) and set to low power (microcell approach). Test APs overhead with directional antennas so they cover a small footprint.
> 
> Test with different types of walls around/between the rooms, metal studs and sheetrock of a modern office have very little affect on signals, stone/brick walls of old buildings (and concrete walls in some areas of new buildings) absorb the signal, the metal grid in movable air walls blocks and reflects signals
> 
> Remember that these are operating in 'unlicensed' spectrum, and so you can have other devices operating here as well causing periodic interference (which could show up as short segments of corruption or just an increased noise floor). Current wifi standards interpret any failed signals as a weak signal, so they drop down to a slower modulation or increasing power in the hope of getting the signal through. If the problem is actually interference from other devices (especially other APs that it can't decipher), the result is that all stations end up yelling slowly to try and get through and the result is very high levels of noise and no messages getting through. Somehow, the systems should detect that the noise floor is high and/or that there is other stuff happening on the network that they can hear, but not necessarily decipher and switch away from the 'weak signal' mode of operation (which is appropriate in sparse environments), and instead work to talk faster and at lower power to try and reduce the overall interference while still getting their signal through. (it does no good for one station to be transmitting at 3w while the station it's talking to is transmitting at 50mw). As far as I know, there is currently no way for stations to signal what power they are using (and the effective power would be modified by the antenna system, both transmitted and received), so this may be that something like 'I'm transmitting at 50% of my max and I hear you at 30% with noise at 10%' <-> 'I'm transmitting at 100% of my max and I hear you at 80% woth noise at 30%' could cause the first station to cut down on it's power until the two are hearing each other at similar levels (pure speculation here, suggestion for research ideas)
> 
>> How many different tests would it take to give reasonable coverage?
> 
> That's hard for me to say, and not every device needs to go through every test. But when working on a new standard, it needs to go through a lot of these tests, the most important ones IMHO are how they work with a high density of users accessing multiple routers which are distributed so there is overlapping coverage and include a mix of network traffic.
> 
> David Lang
> _________________________________


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

  reply	other threads:[~2024-09-02 15:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-08 15:28 [Bloat] WiFi Livingood, Jason
2024-05-08 15:35 ` [Bloat] bloat on wifi8 and 802.11 wg Dave Taht
2024-05-08 21:18   ` Dorothy Stanley
2024-05-08 21:22   ` Dorothy Stanley
2024-09-02  1:15   ` [Bloat] [Make-wifi-fast] " Bob McMahon
2024-09-02  2:59     ` [Bloat] [Starlink] " David Lang
2024-09-02  4:20       ` [Bloat] [Make-wifi-fast] [Starlink] " Hal Murray
2024-09-02  5:05         ` David Lang
2024-09-02 15:04           ` Rich Brown [this message]
2024-09-02 15:09             ` [Bloat] [Make-wifi-fast] Real-world testing: " Sebastian Moeller
2024-09-02 15:37               ` David Lang
2024-09-02 17:28           ` [Bloat] [Make-wifi-fast] [Starlink] bloat on " Bob McMahon
2024-09-02 17:31             ` Frantisek Borsik
2024-09-02 18:02             ` Bob McMahon
2024-09-03  3:20             ` David Lang
2024-09-03 15:42               ` Bob McMahon
2024-09-02 23:22         ` David Collier-Brown
2024-09-02 12:09       ` [Bloat] [Starlink] [Make-wifi-fast] " Michael Richardson
2024-09-02 16:37       ` Brandon Butterworth

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/bloat.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=72A40762-6A00-42B2-83AA-5ABD4F02634B@gmail.com \
    --to=richb.hanover@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=david@lang.hm \
    --cc=halmurray+mwf@sonic.net \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=starlink@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