Forgot to mention that the speed tests were performed using https://speedtest.net from a mobile client connected to the AP.
But yeah, the uploads can be pretty damn good on channels with less interference. Thanks for letting me know about the key issue in my logs. Luckily, it was just a temporary password/key for testing purposes. I will try the patch later and do a quick test and provide just the best result! On Sat, Mar 04, 2017 at 11:16:28PM -0500, tec...@protonmail.com wrote: > Hi, > > I have performed some speed tests with my AP (AR9287) using both 11g and 11n. > I am on the latest 6.1 snapshot from yestrerday. Thanks for taking the time to test! > For comparison sake, I have included tests on different channels. Reporting just the best results is good enough for me. Channels are occupied differently everywhere and occupation patterns change constantly. So this comparison is mostly useful for yourself, since it tells you which channel is working best at your location (until some AP in your area decides that this channel is so good that it is going to use it, too). > I have approx 70mbps download speed on my ethernet connection, and an upload > of under 20mbps. > > A pattern can be observed in these results. > > Upload speed is way above the download speed, infact in many of the > results the upload speed is hitting the same speeds as my ethernet > connection. What is down, and what is up? Is traffic going from the client to the AP what you call "upstream"? There is a known issue where an A won't transmit reliably at higher data rates with our athn(4) driver. I have no idea yet what is causing this problem. > Generally 11n upload speed is better, but on one of the channels - 5 - > both down and upload were pretty dire. Not sure if it is interference, > or wether the card is handling that particulary well. Most likely there is another busy network on channel 5. > Upper channels seem to provide the best performance. > > Hope these tests help in some way. Your numbers are in the ranges as the ones I get. This patch (not committed yet, and not in snaps) might make things a bit faster: https://marc.info/?l=openbsd-tech&m=148866151017854&q=raw
