101–109 of 109 posts
In case someone is interested, I got Claude to create a small Linux tool that analyze the capabilities of your WiFi adapter + the current established Wifi link, and explain each of them based on wiisfi.com: https://gist.github.com/severin-lemaignan/d3f854f6111e8275ae...
It seems the throughput has evolved over each spec but the reliability and distance hasn't, unless I'm mistaken? This is a big problem in place where concrete is used to build homes (e.g. the tropics) as the improvements to Wifi are basically not really relevant.
And 802.11ah, in 900MHz which has some hope of penetrating such walls, is still very scarce and the hardware fairly expensive. Otherwise you just have to run a wire through the wall and put an AP in the room. Your clients can still be wireless for the last few feet, which preserves the convenience of usage, just not the convenience of deployment.
https://www.wiisfi.com/images/wifi-phy-table.jpg
Basically, it shows how a different encoding scheme/modulation is used based on distance (1024-QAM 5/6 - BPSK 1/2) (https://en.wikipedia.org/wiki/Signal_modulation), which is interesting!
If we think about it, any WiFi adapter (in its most basic core functionality) is just the ability to send/receive radio at a specific frequency, and a modulation (send) and corresponding demodulation (receive) scheme on top of that.
If the modulation/demodulation can be handled by a DSP, FPGA or fast-enough CPU, then all that's really required to create a WiFi device is that and the radio component, and then of course, there are devices like "Cantennas" that could give increased range, although loss of omnidirectionality is the trade-off there...
Anyway, I never thought about the fact that different encoding methods are used relative to distance prior to reading this article (i.e., I learned something!) -- but it makes perfect sense now that I think about it!
Earlier quoted context omitted.
So that table is using distance as a proxy for signal to noise ratio. SNR is what really matters. Each data rate in the standard uses a different encoding technique. "Faster" encoding techniques cram more data into a given transmission interval but require a higher signal to noise ratio to be received without error. Since SNR declines with distance you can have a rough idea at what distance from a transmitter you wil…
Do most clients do a constant throughput or do they do bursts? Because speed does matter a lot if it's burst (send 100MB to fill a buffer, then wait). The faster you fill whatever buffer, the faster you can let another client use the connection. Correlated, but obviously bad code can really fuck with neighbors. And each client has an incentive to be greedy so users of that client get a better experience. So you fall…
Basically this. They way we usually put it is that we want clients to "get on and off the channel as quickly as possible". That requires all clients in range of each other to be behaving (respecting the rules) and using fast enough data rates to minimise their consumption of precious air-time.
Under the hood though, it's a very granular frame-by-frame, almost nanosecond-by-nanosecond thing that leads to the overall throughput at a human timescale. To give you a sense, let me try to summarise the factors affecting throughput this way:
- Data Rate: the transmitting client can adjust the data rate of each frame up or down per frame if they want. For example, a single TCP session on a 2.4GHz channel could in theory see data rates everywhere between 1Mbps and 450Mbps. But in practice most drivers I've seen adjust up or down incrementally. And in a healthy network, they usually hover around the top 25% of the mutually supported data rates (but they also spend very little time at the highest data rate, typically less than 1%). Also the AP could be using different data rate to the client, and usually is. The rx and tx directions are effectively separate streams and data rate is always chosen solely by the transmitter.
- Block Size: Similar to TCP windowing. Data can be sent in multi-frame 'bursts' before an acknowledgement is required by the transmitter for it send more. In the original Wi-Fi, every frame had to be acknowledged. Later standards introduced this idea of block acknowledgements.
- Re-transmits: Whenever acknowledgements are not received, the data has to be resent. Block size will be reduced, possibly to 1, so it will also take longer. Note that re-transmits are expected and very routine in Wi-Fi, whereas in TCP they are usually considered more of an exception (except on the internet). I've observed re-transmit rates of 20% in networks where no user is perceiving any sort of issue at all. So Wi-Fi is very robust to frame loss, up to a point, but even so, re-transmits do end up having a large impact on the aggregate throughput.
- Clear channel wait time: It's no exaggeration to say that transmitters spend most of their _waiting_ to transmit. And a big chunk of that wait time is just waiting for the medium to be clear - the clear channel assessment. If the client thinks there is a transmission going on, it just has to kill time.
- Other wait times: Even when the channel seems clear, there are various requirements to do nothing before and after transmitting. For example, the inter-frame spacing interval and the random back-off interval. These are just the rules of play. In fact, congestion avoidance on Wi-Fi could be said to be entirely a matter of timing.
Note that these are a simplification and clearly I can't mention everything or cover all the nuances. But, in the way I've framed it here, the clear-channel wait time and the re-transmit rate do basically encapsulate the impact of intangibles I didn't mention, like congestion and noise/interference.
TLDR; Wi-Fi transmissions are extremely lumpy at their native timescale, but many seem a lot smoother than many TCP transmissions at human timescales.
> Correlated, but obviously bad code can really fuck with neighbors.
Also true. Bad code is usually exemplified in Wi-Fi by bad drivers (looking at you Broadcom). These will cause clients to "stick" to bad APs when they should roam, or pick the wrong channel/AP/band in the first place. Intel is generally very good.
> And each client has an incentive to be greedy so users of that client get a better experience.
Greed is good in the sense that clients want to transmit their data as soon and as fast as possible and we want them too! But they have to respect the rules. Of course there's only a handful of chipset vendors so they mostly do. But within that, there's still plenty of room for clients and APs to do things that are _sub-optimal_ even if they are Wi-Fi legal, as per the sticky client example I mentioned.
> So you fall back again to QOS for what you care about..
Wi-Fi does indeed have its own implementation of QoS which is of course a timing dance! But I think you're referring to QoS in higher layers like IP. So it's worth mentioning that this WiFi stuff is all happening at layers 1 & 2. All the congestion detection and re-transmissions and so on that may be happening in higher-layer protocols like TCP are happening _in addition_ to what is going on at the WiFi layers.
I'd like to understand why the WiFi spec developed so slowly from G to N and finally to AC but now it's seems like a new version is released every other year yet many of the features/extensions are poorly implemented or have nearly 0 real world improvement.
Speaking just on timelines (rather than actual underlying innovations or improvements), 802.11 was in 1997, next in 1999, G in 2003, then a 6 year gap to N in 2009, 4 year gap to AC in 2013, 8 year gap to wifi 6 in 2021, wifi 7 in 2024 (though apparently buyer beware), and wifi 8 expected (according to the article) in 2028. Doesn't seem too rapid? The 8 year gap is the weird one out. I think part of it is that if the…
Earlier quoted context omitted.
> only 1 transmitter at a time per channel - across all WLANs, yours and your neighbours, with no deterministic way to avoid collisions. Not true with newer standards: > Orthogonal Frequency-Division Multiple Access (OFDMA) is a multi-user wireless transmission technology that divides a single Wi-Fi or cellular channel into smaller subcarriers called Resource Units (RUs), allowing multiple devices to transmit data si…
OFDMA just makes the channels smaller. Sure there are now 10 transmitters on channel 5, but there's one transmitter on channel 5.1, one on 5.2, ... and each 'channel' has 1/10th the capacity of "channel 5".
Yes, and? If a device only needs 26 tones, that's what will be assigned; if it needs 52 or 106, then that will assigned:
> RU allocations can happen with a combination of tones. For example – if there are three stations associated, then the AP can assign 106 tones to the first two users and 26 tones to the third user. The AP can also assign 52 tones to the third user. These RU allotment decisions are dynamically made by the AP based on the client’s traffic type and its available amount for transmission. The AP learns the client’s buffer status by using a periodic sounding mechanism.
* https://blogs.cisco.com/networking/wi-fi-6-ofdma-resource-un...
Scheduling is not static; Figure 4:
> In the first scheduling interval, the AP allocates the whole 20 MHz channel—a single, 242-tone RU—to Client 1. And in the third interval, it allocates two 106-tone RUs to Client 2 and Client 3.
* https://www.arista.com/assets/data/pdf/Whitepapers/WiFi-6.pd...
And can even be done on a per frame/PPDU basis:
* https://assets.ctfassets.net/wcxs9ap8i19s/2cAbZviv89ZKQZrXo9...
Why give one client more than it needs (when another client can also share the transmission time slot)? If it happens to need the entire x MHz channel, it may be given it (all the RU tones).
Earlier quoted context omitted.
Do most clients do a constant throughput or do they do bursts? Because speed does matter a lot if it's burst (send 100MB to fill a buffer, then wait). The faster you fill whatever buffer, the faster you can let another client use the connection. Correlated, but obviously bad code can really fuck with neighbors. And each client has an incentive to be greedy so users of that client get a better experience. So you fall…
> The faster you fill whatever buffer, the faster you can let another client use the connection. Basically this. They way we usually put it is that we want clients to "get on and off the channel as quickly as possible". That requires all clients in range of each other to be behaving (respecting the rules) and using fast enough data rates to minimise their consumption of precious air-time. Under the hood though, it's…
Earlier quoted context omitted.
Inwas about to buy a pair of those, but then I saw the new mikrotik wifi 7 router (and probably upcoming access point) with thread radio. Now every other brand is dead to me.
What are the chances of a 3x3 or 4x4 router from them I wonder.
Earlier quoted context omitted.
So that table is using distance as a proxy for signal to noise ratio. SNR is what really matters. Each data rate in the standard uses a different encoding technique. "Faster" encoding techniques cram more data into a given transmission interval but require a higher signal to noise ratio to be received without error. Since SNR declines with distance you can have a rough idea at what distance from a transmitter you wil…
There are a lot of people who are the only ones using their Wi-Fi, so they probably don't care about the performance for anyone else
This is also why it's often better if everyone uses lower transmit power (while still retaining coverage), as networks farther away will see less interfering networks.
