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

[bkil]

Dear Pete,

We understand that you are reluctant to share full radiotap wlan
traces due to privacy reasons and collecting them would strain your
infrastructure still a bit more.

As a compromise, let me suggest a lightweight alternative. You can set
up to only collect trimmed frame metadata on your AP's of interest,
ie., cabin 20 & 24 and the gateway running on the same channel. You
can aggregate a full day's worth of data or just the interesting hours
at a central location using a PC or NAS. Then you can export only a
few key data fields to CSV to carefully mask out any remaining ID and
data parts. After compressing such an export with xz, it should have a
manageable size.

I've made a few small scripts to do such an export and to illustrate
how to run the central collection & the agents on your AP's in a quick
and dirty way. Feel free to improve and share your findings.

https://github.com/bkil/lede-pcap-investigation

I'm sure many of us would like to have a look into such real life
data, because your high density single radio setup sounds really
interesting from a contention standpoint.

Although I've tested it on both Atheros and Intel traces, you should
probably preserve the original pcap's as well until we verify that all
needed fields had been successfully exported. Also feel free to adjust
the snap length if needed.

After you have collected the data, please also attach a recent
SmokePing screenshot so we can correlate the two.

Although we can probably give more informed advice based on the
traces, as a stop gap measure until you finish cabling, you may
consider traffic shaping of the clients to improve QoS. For example,
you may put a hard bandwidth cap on each client (or only those coming
from an AP in question), prioritize HTTP & VoIP traffic and reduce P2P
traffic, depending on what is the biggest data hog.

Also, could you by any chance set up monitoring of some addition
metrics, like CPU usage, I/O wait, load average and memory usage on
your nodes?

N.b.: It's a pity that networking trace anonymization tools aren't up
to the challenge. Simple MAC randomization or hashing with data
omission would be just fine for such a use case.

https://sharkfestus.wireshark.org/sharkfest.11/presentations/A-11_Bongertz-Trace_File_Anonymization.pdf
http://www.caida.org/tools/taxonomy/anontaxonomy.xml
https://wiki.wireshark.org/Tools#Capture_file_anonymization
https://cseweb.ucsd.edu/~snoeren/papers/slomo-nsdi13.pdf

Regards

On Wed, Jun 13, 2018 at 6:01 PM, Pete Heist <pete at heistp.net> wrote:
>
> On Jun 13, 2018, at 3:24 PM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>
> Pete Heist <pete at eventide.io> writes:
>
> I’m still waiting for the digging / cabling project to happen, which
>
>
> How to improve WiFi? Run cables! :D
>
>
> Yes, and pave the earth right over… :)
>
> Seriously, watching this network evolve over the years has been a 6 year
> lesson in incremental progress, something like:
>
> 1) 4Mbit ADSL + 802.11g
> 2) 4Mbit ADSL/fq_codel + 802.11g
> 3) 4Mbit ADSL/fq_codel + 802.11n
> 4) 40Mbit via P2P WiFi + 802.11n
> 5) 40Mbit via P2P WiFi + 802.11n 2x2
> 6) 40Mbit via P2P WiFi + 802.11n 2x2 / make-wifi-fast ath9k driver
>
> This is not an enterprise, so we’ve never invested in high-end hardware, but
> perhaps life would have been better along the way if the entire WiFi
> industry had focused not on maximum single device throughput but on
> resolving contention, increasing responsiveness and providing fairness
> between multiple users. But then we can’t put “300 Mbps” on the box!
>
> I do appreciate your ath9k driver work for moving beyond that kind of
> thinking, I just need to see if I can fix the other stuff getting in its
> way… :)
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast