Regarding footnote [2], this is where 5GHz really helps. With 80MHz channels, you'll be using 1/4 the airtime to send the same amount of data.
2.4GHz is to be avoided if at all possible.
Also, measuring SNR is interesting, but you should really run a speed test of some sort. A team I work with wrote this to let access points speedtest clients without any code on the client:
(Only really tested with ath9k and ath10k. Could possibly work with other chips.)
Of course, there are many variables on translating link quality to actual throughput. Rate control algorithms are essential, and often wrong. For example, consider sending at 10x the speed and losing 2x the data. Most rate control algorithms will avoid that scenario, even though it's actually faster and conserves valuable airtime.
> Also, measuring SNR is interesting, but you should really run a speed test of some sort.
No doubt. Next time I find myself in something similar to my apartment, but in the middle of nowhere so's the three or four-dozen 2.4GHz APs that surround me don't confound the results, I'll do just that. :)
FWIW, the SNR measurements were taken with a UBNT SR-71E (802.11agn ath9k-driven) client that Linux reports as an AR928X.
I'll make a note to look at that wifiblaster program later this week. That could be pretty useful. Unrelated to that, how's the ath10k driver looking? Does it work most of the time for most supported cards these days, or does it still come with a boatload of caveats?
I think the open source ath10k driver is in a pretty good state. We're using it for the Google Fiber routers, and it's working pretty well. OnHub is also using ath10k.
That said, now that the drivers are working, it's old technology. 4x4ac is all the rage now, and ath10k is 3x3.
2.4GHz is to be avoided if at all possible.
Also, measuring SNR is interesting, but you should really run a speed test of some sort. A team I work with wrote this to let access points speedtest clients without any code on the client:
https://gfiber.googlesource.com/vendor/google/platform/+/mas...
(Only really tested with ath9k and ath10k. Could possibly work with other chips.)
Of course, there are many variables on translating link quality to actual throughput. Rate control algorithms are essential, and often wrong. For example, consider sending at 10x the speed and losing 2x the data. Most rate control algorithms will avoid that scenario, even though it's actually faster and conserves valuable airtime.
This is good reading on that subject: https://wireless.wiki.kernel.org/en/developers/documentation...