On Sat, Apr 22, 2017 at 03:49:35PM -0500, Colton Lewis wrote:
> I applied the patch and compiled a new kernel using the stable branch.
> 11n and 11g both work now,
> but with significantly worse performance than 11b. Downloads are about
> 40% slower.
>
> $ curl http://download.thinkbroadband.com/200MB.zip -O
> was my test.
Thanks for testing this fix. I will commit it shortly.
The performance issues with athn are known and unrelated to my diff.
Performance with athn is worse than what e.g. iwm(4) clients get with
commercial APs. Obviously there is a lot of work left to do and
very many things to fix.
My own priority right now is that 11n support with athn is stable,
i.e. does not crash and does not drop out entirely for no good reason.
So far, this seems to be the case.
It is already fast enough for my own needs inspite of some issues.
E.g. my athn AP never transmits with rates higher than MCS 12. I don't
know why it never goes up to MCS 15. It sucks pretty badly on 2 GHz but
works fine on 5. There are many networks on 2 GHz around here which are
very active at times. I have gotten reports from people living out
in the country where they can use 2 GHz just fine, though.
It's not entirely clear to me where issues other people are reporting are
coming from. Do they see what I see or is it actually worse for them?
I have no way of knowing.
So far nobody who complained about performance has provided pcap files
of their traffic that are actually useful for debugging. Before I can do
anything to improve performance, you must capture some interesting pcap data.
Your other option is to stop reading now, forget about athn for now,
and use some other AP.
To capture a pcap file, you need an iwn interface.
Associate your client and figure out the channel of your AP.
Below I will use channel 5 as an example.
On your iwn device, prepare monitor mode (assuming unconfigured default state):
ifconfig iwn0 mediaopt monitor
ifconfig iwn0 chan 5
ifconfig iwn0 up
Verify that iwn is receiving on channel 5:
tcpdump -n -i iwn0 -y IEEE802_11_RADIO
The last part of each line should show the channel:
<radiotap v0, chan 5, 11g, sig -81dBm, noise -89dBm>
I have seen a quirk every now and then where the channel is not
set up correctly the first time through. If it's not listening
on the right channel yet, try again with:
ifconfig iwn0 down
ifconfig iwn0 chan 5
ifconfig iwn0 up
tcpdump -n -i iwn0 -y IEEE802_11_RADIO
Once the channel is OK, you can run this to capture any frames the
hardware can receive:
tcpdump -n -i iwn0 -y IEEE802_11_RADIO -s 4096 -w /tmp/iwn.pcap
Now do whatever on the client to provoke the low performance situation.
Leave the monitor running during this time. Ideally, give the monitor
30 seconds of margin around your experiments so we can see what's
going on while your client is idle.
Now zip the pcap file and send it to me, and tell me the MAC addresses
of your AP and your client involved in the speed test.
I will run wireshark (as non-root) to view the pcap file:
wireshark /tmp/iwn.pcap
The interesting bits of information can be seen in the lower pane in the
'802.11 radio information' section and the '802.11 ... frame' section.
The 'Wireless' -> 'WLAN Traffic' statistics menu is also useful.
Things I will be looking for include:
What transmit rates are reported for packets sent from/to your client?
Are there beacons, RTS and/or data frames from other networks?
How many frames are marked as retries?
What is the ratio of RTS vs data frames?
Is the client doing power saving and how does the AP handle this?
Ideally, we'll be able to figure out what kind of traffic the available
air time on your channel is spent on, and whether the AP is actually
misbehaving in some way.
