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. -- Regards, Mikolaj