On Wed, Mar 31, 2021 at 11:31:19AM +0000, Mikolaj Kucharski wrote: > 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 >
This athn(4) client is probably a red herring. Even after reverting the patch I still get significant packet loss. So far I see network issues only on that one box. I tested one after the other above athn(4) client and urtwn(4) Pinebook from the same room and Pinebook had zero packet loss, when athn(4) client has repeated packet loss 10% - 20% for 1000 pkts. # mtr -rwb -c 1000 192.168.220.1 Start: 2021-04-01T05:03:59+0000 HOST: pinebook-0011.home.local Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.220.1 0.0% 1000 7.0 9.7 2.7 125.2 8.8 As in recent weeks my spare time for OpenBSD is drained to almost zero, I guess you can ignore me for now, as I cannot fall through with proper reporting on this diff. -- Regards, Mikolaj
