[simoncion]

> Although I believe all channels are high-power channels now...

If they are, my Linux systems aren't yet aware of the change.

They make the claim that the only ranges with a 30dBm transmit power are 2402 - 2472MHz and 5735 - 5835MHz. All other WiFi bands are 23dBm. (Though it does seem like the transmit power in the 5.49 - 5.73 GHz range got increased from 17 to 23dBm somewhat recently.)

> I have yet to see any scientific paper that says 5GHz penetrates structural elements worse than 2.4GHz.

I can't point you to any studies, but -anecdotally- I've found that (at the same transmit power, and all other things being equal) a 5GHz link provides a lower SNR than a 2.4GHz link. Before I switched to an AP with better antenna and radio, I found that I would not-infrequently permanently lose the 5GHz connection in my bathroom [0][1], but the 2.4GHz connection could be reliably established in the bathroom and remained solid.

Even after I've switched APs, I get a substantially better signal [2] from the 2.4GHz connection than the 5GHz one.

[0] My bathroom is tile covered, filled with pipes, and the furthest point in the apartment from my AP.

[1] "Permanently" as in "once I left the bathroom I could reestablish the 5GHz connection".

[2] Obviously, a better signal doesn't guarantee a faster connection. At my site, 2.4GHz is so overcrowded as to be nearly useless.

[jrockway]

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:

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...

[simoncion]

> 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?

[jrockway]

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.