On Wed, Mar 31, 2021 at 11:24:19AM +0000, Mikolaj Kucharski wrote: > On Tue, Mar 23, 2021 at 07:47:08PM +0000, Mikolaj Kucharski wrote: > > On Tue, Mar 23, 2021 at 07:06:33PM +0000, Mikolaj Kucharski wrote: > > > On Tue, Mar 23, 2021 at 06:01:27PM +0100, Stefan Sperling wrote: > > > > This switches athn(4) to the new RA Tx rate adaptation module. > > > > Tests on athn(4) PCI devices are welcome. > > > > USB devices don't need to be tested in this case Tx rate adaptation > > > > is taken care of by firmware. > > > > > > > > I could only test on AR9285 so far, but the result looks promising. > > > > > > > > diff c6a6a64b49f2287751632205d64f594eb6c1ee42 > > > > 636e9964c6e5313bb1c75823249d483597a0e93a > > > ... > > > > > > > > > Tested on athn(4) in `mediaopt hostap` mode. Uptime 1hr, so not a lot of > > > testing yet. So far no issues. I have two systems like that (in hostap) > > > and in `dmesg | grep athn` only difference is mac address between them. > > > I can send full dmesg from second system as well if you want. > > > > > > > I also have third system, with the same athn(4) card (only mac address > > is different in `dmesg | grep athn` output), but it acts as a Wi-Fi > > client and is connected to OpenBSD athn(4)-based access point from > > my previous email (full dmesg output in an earlier email). > > > > After week of running this I have similar observations like Scott > Bennett. > > I will focus on one location, as I have 2 access points running on > athn(4) with the diff from this thread, but I'm only present at one of > those locations. All athn(4) machines have the diff applied. > > OpenBSD, athn(4), hostap > OpenBSD, athn(4), wi-fi client to above access point > OpenBSD, iwm(4), wi-fi client to above access point > > I do see some packets dropped with RA patch: > > # mtr -rwb -c 1000 192.168.220.76 > Start: 2021-03-31T08:17:57+0000 > HOST: pce-0041.home.lan Loss% Snt Last Avg Best Wrst StDev > 1.|-- 192.168.220.76 9.2% 1000 2.2 2.6 1.2 82.9 3.4 > > Above is from hostap machine to athn(4) client. Below is the other way > around. Client to hostap. Measurments with mtr on both ends were not > executed at the same time, but one after the other, with couple of > mintues gap. > > # mtr -rwb -c 1000 192.168.220.1 > Start: 2021-03-31T10:38:07+0000 > HOST: pce-0067.home.local Loss% Snt Last Avg Best Wrst StDev > 1.|-- 192.168.220.1 10.5% 1000 3.1 2.5 1.5 43.7 2.2 > > The loss is big, but I didn't notice this too much over short > interactive ssh sessions. However I do notice problem havily when I'm on > a laptop with iwm(4) ssh'ing to athn(4) client. Then ssh stalls are > sigificant that I need to wait until TCP recovers and I can type again. > I'm often using scp(1) between athn(4) client and iwm(4) laptop and that > amplifies the problem during simultaneous interactive ssh session. > SSH stalls are more prominient, longer. > > I need to say it's still better than I think without this RA diff, as > communitcating with athn(4) client from iwm(4) laptop before was worse > as that very often triggered those famous athn device timeouts and > recovering from them took way longer than from the packet loss and RA. > Packet loss revovery with RA is in tens of seconds, recovery from athn > device timeout was in minutes, because usually timeouts occured one > after another, like 3 or 4 in a row. With RA I don't see this happening > any more. > > So, all in all I prefer RA, but I do see packet losses. >
I did also from athn client to athn hostap: # ping -g -c1000 192.168.220.1 PING 192.168.220.1 (192.168.220.1): 56 data bytes !!!!.!!!!!!!!!!!!!!!!!!!!!.!.!.!!!!!!.!!.!!!.!.!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!. ..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!.!.!!!!!!!!!!!!!.!.!!!!!!!!!!!!!!!!!!.!.!!!!!!!!!!!!!!!!! !!!!!!.!.!..!!!!!!!!!!!!..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!.!!!!!!!!.!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!.!.!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!.....!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!.!.!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!! !!!!!!!!.!...!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!.!!!!!!!!!!!!!.!.!!! !.!.....!!!!!!!!!!!!!!!!!!!!!!!.!.!.!!!!!!!!!!!!!!!!!!!.!.!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!.!.!!!!!.!..!!!!!.!.!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!.!!!!!!!!!!!.!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!! --- 192.168.220.1 ping statistics --- 1000 packets transmitted, 925 packets received, 7.5% packet loss round-trip min/avg/max/std-dev = 1.026/2.818/34.711/1.993 ms Maybe that would help to visualise dropped packets. Both machines are on: # dmesg | grep athn athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 int 16 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:45:6a:c2 -- Regards, Mikolaj
