On Thu, Feb 09, 2023 at 08:39:50AM -0300, Crystal Kolipe wrote: > On Thu, Feb 09, 2023 at 06:51:54AM +0100, Martin Kjr Jrgensen wrote: > > That's what I gathered so far, but I could have been wrong or not > > up-to-date. There have been some work on the ieee80211(9) lately. > > I've just done a quick test using: > > athn0 at pci1 dev 0 function 0 "Atheros AR9287" rev 0x01: apic 2 int 16 > athn0: AR9287 rev 2 (2T2R), ROM rev 4, address xx:xx:xx:xx:xx:xx > > ... in hostap mode. > > I've used this particular card with OpenBSD since 6.1, and other athn > cards before it during the 5.* days. One long standing issue has been > that the transmission rate always seemed to drop to DS1 as soon as any > data was transferred, and stay there (*). > > At least in this casual test this morning, I was able to transfer 1.5 Gb > of data at about 24 Mbps. > > So maybe one of the many issues has been resolved, or at least seen some > improvement. > > But this was a casual test with a single client, so it ignores many of > the other problems that plagued hostap mode on OpenBSD. More testing is > definitely required. > > (*) Actually it was a bit more complicated than that, from what I > remember the transmission rate on the host seemed to stay low when > the flow of data was mostly from client to host. Running a ping with > a very low latency, but not enough to flood the connection bandwidth, > E.G. ping -i 0.1 from the server to the client, caused the > transmission rate to increase.
This was likely because of the AMRR algorithm use in 11a/11g modes, which only counts Tx retries. And this hardware is very prone to reporting retries under high Tx load, likely because our driver is getting some details wrong. In 11n modes drivers are now using a better algorithm where actual throughput is measured and the Tx rate is adjusted based on that, so these retries don't carry as much weight anymore. There are several issues which remain. In particular, some athn devices tend to run into "device timeout" problems, meaning they fail to Tx for some reason. And the driver lacks 11n Tx aggregation and 40MHz channel support. In theory the hardware should be able to provide 100 Mbit/s or more to clients once those features get added. And the code we have for 3-antenna variants of this hardware doesn't work and is currently disabled at run-time, though still compiled into the kernel. So, yes, there is a lot of work left to be done in this driver which is up for grabs if someone seriously wants to clench their teeth into this. There is working code in Linux and FreeBSD which can be used as a reference. I have already spent more time on this than I ever really wanted to. You could also try to find a card supported by bwfm(4). This bypasses the entire OpenBSD wifi stack and runs everything in firmware. But it should provide proper 11n or even 11ac speeds towards clients.
