I gathered a bunch of stats from the Scale conference this year http://lang.hm/scale/2015/stats/ this includes very frequent dumps of transmission speed data per MAC address per AP David Lang On Fri, 27 Mar 2015, Isaac Konikoff wrote: > Thanks for pointing out horst. > > I've been trying wireshark io graphs such as: > retry comparison: wlan.fc.retry==0 (line) to wlan.fc.retry==1 (impulse) > beacon delays: wlan.fc.type_subtype==0x08 AVG frame.time_delta_displayed > > I've uploaded my pcap files, netperf-wrapper results and lanforge script > reports which have some aggregate graphs below all of the pie charts. The > pcap files with 64sta in the name correspond to the script reports. > > candelatech.com/downloads/wifi-reports/trial1 > > I'll upload more once I try the qdisc suggestions and I'll generate > comparison plots. > > Isaac > > On 03/27/2015 10:21 AM, Aaron Wood wrote: >> >> >> On Fri, Mar 27, 2015 at 8:08 AM, Richard Smith > > wrote: >> >> Using horst I've discovered that the major reason our WiFi network >> sucks is because 90% of the packets are sent at the 6mbit rate. >> Most of the rest show up in the 12 and 24mbit zone with a tiny >> fraction of them using the higher MCS rates. >> >> Trying to couple the radiotap info with the packet decryption to >> discover the sources of those low-bit rate packets is where I've >> been running into difficulty. I can see the what but I haven't >> had much luck on the why. >> >> I totally agree with you that tools other than wireshark for >> analyzing this seem to be non-existent. >> >> >> Using the following filter in Wireshark should get you all that 6Mbps >> traffic: >> >> radiotap.datarate == 6 >> >> Then it's pretty easy to dig into what those are (by wifi frame-type, at >> least). At my network, that's mostly broadcast traffic (AP beacons and >> whatnot), as the corporate wifi has been set to use that rate as the >> broadcast rate. >> >> without capturing the WPA exchange, the contents of the data frames can't >> be seen, of course. >> >> -Aaron > > >