[Make-wifi-fast] mesh deployment with ath9k driver changes

[bkil]

In reply to this thread:
https://lists.bufferbloat.net/pipermail/make-wifi-fast/2018-April/001787.html

Sorry for the late response, although I can see from yesterday's
SmokePing plots that the issue still prevails.

1.
You should definitely not allow rates as low as 1Mb/s considering:
* plots of signal vs. rate,
* topology of closely packed cabins;
* mostly static, noise-free camp ground.

Almost all of your clients were able to link with >20Mb/s even at
70-80dBm. Those below were probably just idling. I'd limit the network
to 802.11g/n-only, and would even consider disabling all rates below
12Mb/s.

This should help both in working around imperfect schedulers and
clients roaming.

You could double check the coverage afterwards with a simple site
survey. You may also test whether disassoc_low_ack makes things more
stable around the edge.

Despite the recently introduced air fairness patches, most other
points are still valid from these earlier articles due to pathological
schedulers:
http://divdyn.com/disable-lower-legacy-data-rates/
https://blogs.cisco.com/wireless/wi-fi-taxes-digging-into-the-802-11b-penalty
https://www.networkworld.com/article/2230601/cisco-subnet/dropping-legacy-802-11-support-from-your-infrastructure--part-2-.html

Disabling 802.11/b modulation also brings the added benefit of
occupying less bandwidth (16.5-20 OFDM vs. 22 Barker/CCK), enabling
the previously mentioned channel spacing of 1-5-9-13.

https://wifinigel.blogspot.hu/2013/02/adjacent-channel-interference.html

2.
Enable client isolation to mitigate broadcast storms.

3.
If you still couldn't split the two cells that work on the same
channel, at least try to reduce their TX power to reduce their range
of interference. This may or may not improve things overall due to
hidden nodes, though.

We'd definitely love to hear from you whether any of these worked or
made things worse. Happy camping!