Re: athn(4): switch Tx rate control to RA
On Sat, Apr 03, 2021 at 08:30:14PM +, Mikolaj Kucharski wrote: > 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. Thank you for following up on this. The athn driver does have known issues which are unrelated to this patch. Such issues can be irritating during testing but I am not going to try to track down unrelated issues right now. So far, I've only got one report (aside from yours) which suggests that RA introduces a regression for a particular device, where this device apparently worked much better without the patch. Still, this diff is an improvement for the majority of people who reported back, and that's a good start.
Re: athn(4): switch Tx rate control to RA
On Wed, Mar 31, 2021 at 11:31:19AM +, Mikolaj Kucharski wrote: > On Wed, Mar 31, 2021 at 11:24:19AM +, Mikolaj Kucharski wrote: > > On Tue, Mar 23, 2021 at 07:47:08PM +, Mikolaj Kucharski wrote: > > > On Tue, Mar 23, 2021 at 07:06:33PM +, 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+ > > HOST: pce-0041.home.lan Loss% Snt Last Avg Best Wrst StDev > > 1.|-- 192.168.220.76 9.2% 10002.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+ > > HOST: pce-0067.home.local Loss% Snt Last Avg Best Wrst StDev > > 1.|-- 192.168.220.1 10.5% 10003.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,
Re: athn(4): switch Tx rate control to RA
On 23 Mar 18:01, 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. > Hi Stefan, I tested between my laptop with iwm: iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi iwm0: hw rev 0x230, fw ver 34.0.1, address xx:xx:xx:xx:xx:xx:xx and my APU1 with: athn0 at pci4 dev 0 function 0 "Atheros AR5418" rev 0x01: apic 2 int 19 athn0: MAC AR5418 rev 2, RF AR5133 (2T3R), ROM rev 8, address xx:xx:xx:xx:xx:xx:xx With patch laptop -> apu: Conn: 1 Mbps: 19.021 Peak Mbps: 19.021 Avg Mbps: 19.021 30042287840 18.284 100.00% With patch apu -> laptop: Conn: 1 Mbps: 27.987 Peak Mbps: 30.027 Avg Mbps: 27.987 50033528776 28.202 100.00% Without patch laptop -> apu: Conn: 1 Mbps:7.900 Peak Mbps: 13.750 Avg Mbps:7.900 7015 9281687.388 100.00% Without patch apu -> laptop: Conn: 1 Mbps:4.247 Peak Mbps:7.231 Avg Mbps:4.247 6055 4898043.868 100.00% So notable performance improvements! Thank you very much for your hard work! -- wq: ~uw
Re: athn(4): switch Tx rate control to RA
On Wed, Mar 31, 2021 at 11:24:19AM +, Mikolaj Kucharski wrote: > On Tue, Mar 23, 2021 at 07:47:08PM +, Mikolaj Kucharski wrote: > > On Tue, Mar 23, 2021 at 07:06:33PM +, 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+ > HOST: pce-0041.home.lan Loss% Snt Last Avg Best Wrst StDev > 1.|-- 192.168.220.76 9.2% 10002.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+ > HOST: pce-0067.home.local Loss% Snt Last Avg Best Wrst StDev > 1.|-- 192.168.220.1 10.5% 10003.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
Re: athn(4): switch Tx rate control to RA
On Tue, Mar 23, 2021 at 07:47:08PM +, Mikolaj Kucharski wrote: > On Tue, Mar 23, 2021 at 07:06:33PM +, 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+ HOST: pce-0041.home.lan Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.220.76 9.2% 10002.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+ HOST: pce-0067.home.local Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.220.1 10.5% 10003.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
Re: athn(4): switch Tx rate control to RA
On Tue, Mar 30, 2021 at 11:06:43PM -0400, Scott Bennett wrote: > However, my laptop with AR9287 was noticeably worse with this diff (dropped > pings, stuttering keystrokes in interactive ssh session, estimated 20 > minutes to scp(1) a 20M file...). The combination of apu2 with diff and my > laptop sans diff is giving me good results though :) > > athn0 at pci2 dev 0 function 0 "Atheros AR9287" rev 0x01: apic 2 int 17 > athn0: AR9287 rev 2 (2T2R), ROM rev 4, address 74:de:2b:xx:xx:xx This device (AR9287) has known issues in 11n mode already: https://marc.info/?t=15899228758=1=2 Granted, that is a sample size of one, and unlike the person who filed that bug report you didn't have problems before the RA patch. But perhaps these issues are somehow related? I don't have this hardware, and I cannot tell what's wrong with it. My best guess is that this device doesn't report retries in the same way as the 9280 does, so RA ends up picking a rate that's too high. But that's just a wild guess. Can you please try the following: Set a fixed Tx rate and figure out the loss/throughput characteristics of each, while the laptop stays put at the same place relative to the AP. The supported Tx rates for this device are grouped into two groups: Group1 : MCS 0 (low) to MCS 7 (high) Group2 : MCS 8 (low) to MCS 15 (high) Start with a fixed Tx rate of MCS 0: ifconfig athn0 media HT-MCS0 mode 11n Now do you see dropped pings, stuttering keystrokes, slow transfers? Ideally you'd show ping packet loss at the default size and at ping -s 1500, plus the transfer rate when sending a big file from the laptop towards the AP. Note that scp isn't a good tool for measuring Tx performance; rsync or a benchmarking tool such as tcpbench or iperf are suited better for this. Then go up and repeat the test at each rate: ifconfig athn0 media HT-MCS1 mode 11n ... ifconfig athn0 media HT-MCS7 mode 11n Once you've reached MCS 7, move on the next group: ifconfig athn0 media HT-MCS8 mode 11n ... ifconfig athn0 media HT-MCS15 mode 11n It's a bit tedious, but if you could give me a test result for all the 16 supported MCS we might be able to find a fix. Thanks!
Re: athn(4): switch Tx rate control to RA
On Tue, 23 Mar 2021 18:01:27 +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. This seems to be working well on my apu2 in hostap mode: 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:xx:xx:xx However, my laptop with AR9287 was noticeably worse with this diff (dropped pings, stuttering keystrokes in interactive ssh session, estimated 20 minutes to scp(1) a 20M file...). The combination of apu2 with diff and my laptop sans diff is giving me good results though :) athn0 at pci2 dev 0 function 0 "Atheros AR9287" rev 0x01: apic 2 int 17 athn0: AR9287 rev 2 (2T2R), ROM rev 4, address 74:de:2b:xx:xx:xx On this laptop, I use a trunk(4) interface and I connect to the apu2 via authpf(8). Some configs and dmesg below. Let me know how I can be of further assistance. $ cat /etc/hostname.athn0 join myap wpakey xxx powersave up $ cat /etc/hostname.em0 up $ cat /etc/hostname.trunk0 trunkproto failover trunkport em0 trunkport athn0 dhcp up $ ifconfig athn0 athn0: flags=8943 mtu 1500 lladdr d4:be:d9:xx:xx:xx index 2 priority 4 llprio 3 trunk: trunkdev trunk0 groups: wlan media: IEEE802.11 autoselect (HT-MCS2 mode 11n) status: active ieee80211: join myap chan 7 bssid xx:xx:xx:xx:xx:xx -36dBm wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp powersave on (100ms sleep) OpenBSD 6.9-beta (GENERIC.MP) #437: Tue Mar 30 14:45:23 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17064501248 (16273MB) avail mem = 16531947520 (15766MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebf20 (98 entries) bios0: vendor Dell Inc. version "A13" date 06/20/2014 bios0: Dell Inc. Latitude E6430s acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT DMAR ASF! SLIC BGRT acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB5(S3) USB6(S3) USB7(S3) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2592.04 MHz, 06-3a-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2591.60 MHz, 06-3a-09 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus 2 (RP02) acpiprt4 at acpi0: bus -1 (RP05) acpiprt5 at acpi0: bus 11 (RP06) acpiprt6 at acpi0: bus -1 (RP07) acpiprt7 at acpi0: bus -1 (RP08) acpiprt8 at acpi0: bus -1 (PEG0) acpiprt9 at acpi0: bus -1 (PEG1) acpiprt10 at acpi0: bus -1 (PEG2) acpiprt11 at acpi0: bus -1 (PEG3) acpiprt12 at acpi0: bus 3 (RP03) acpiprt13 at acpi0: bus 7 (RP04) acpiec0 at acpi0 acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001 acpicmos0 at acpi0 "SMO8810" at acpi0 not configured "*pnp0c14" at acpi0 not configured acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PBTN acpibtn2 at acpi0: SBTN acpiac0 at acpi0: AC unit offline acpibat0 at acpi0: BAT0 model "DELL YJNKK18" serial 1 type LION oem "DP-SDI56" acpibat1 at acpi0: BAT1 not present acpibat2 at acpi0: BAT2 not present "DELLABCE" at acpi0 not configured acpicpu0 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at
Re: athn(4): switch Tx rate control to RA
On Tue, Mar 23 2021 18:01:27 +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. Some numbers from quick tests on: athn0 at pci1 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 int 0 athn0: AR9280 rev 2 (2T2R), ROM rev 16, address in hostap mode (11n), sending data to a laptop on iwn(4). tcpbench (tcp), 10sec: - before: Mbps varied between 0.677 and 15.187, avg 4.647 - after: Mbps varied between 10.345 and 10.623, avg 10.588 tcpbench (udp), 10sec: - before: Rx PPS between 1444 and 1461, about 17 Mbps athn(4) sent: 495668032 bytes sent over 10.999 seconds - after: Rx PPS between 1021 and 1056, about 12 Mbps athn(4) sent: 462994048 bytes sent over 10.999 seconds (I failed to record bytes received on iwn(4) for this test, sorry) ping -f -c 1 from athn(4) hostap to iwn(4): before: 1 packets transmitted, 9982 packets received, 0.2% packet loss round-trip min/avg/max/std-dev = 0.397/1.029/100.599/1.400 ms after: 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.402/1.191/10.510/0.463 ms Subjectively, the reduced loss & more predictable latency feels much better with eg. interactive ssh sessions. -- Lauri Tirkkonen | lotheac @ IRCnet
Re: athn(4): switch Tx rate control to RA
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. Hi Stefan, I tested on ar9285 as well: athn0 at pci2 dev 0 function 0 "Atheros AR9285" rev 0x01: apic 1 int 17 athn0: AR9285 rev 2 (1T1R), ROM rev 14, address 74:2f:68:xx:xx:xx This patch works well for me and increased throughput notable. Nice work! :)
Re: athn(4): switch Tx rate control to RA
On Tue, Mar 23, 2021 at 08:52:12PM +0100, Stefan Sperling wrote: > On Tue, Mar 23, 2021 at 07:47:08PM +, Mikolaj Kucharski wrote: > > 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). > > In case it wasn't clear, this patch affects both client and hostap modes > so you'll want to patch both ends. Yes, sorry I should mention this too. All three systems run kernel with your patch applied. -- Regards, Mikolaj
Re: athn(4): switch Tx rate control to RA
On Tue, Mar 23, 2021 at 07:47:08PM +, Mikolaj Kucharski wrote: > 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). In case it wasn't clear, this patch affects both client and hostap modes so you'll want to patch both ends.
Re: athn(4): switch Tx rate control to RA
On Tue, Mar 23, 2021 at 07:06:33PM +, 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). -- Regards, Mikolaj
Re: athn(4): switch Tx rate control to RA
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. OpenBSD 6.9-beta (GENERIC.MP) #5: Tue Mar 23 17:36:03 UTC 2021 r...@pc1.home.local:/home/mkucharski/openbsd/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4259872768 (4062MB) avail mem = 4115365888 (3924MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xcfe8b020 (13 entries) bios0: vendor coreboot version "v4.12.0.3" date 07/30/2020 bios0: PC Engines apu3 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT DRTM HPET acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-64 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD GX-412TC SOC, 998.28 MHz, 16-30-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD GX-412TC SOC, 998.33 MHz, 16-30-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PBR4) acpiprt2 at acpi0: bus 1 (PBR5) acpiprt3 at acpi0: bus 2 (PBR6) acpiprt4 at acpi0: bus 3 (PBR7) acpiprt5 at acpi0: bus 4 (PBR8) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 amdgpio0 at acpi0 GPIO uid 0 addr
Re: athn(4): switch Tx rate control to RA
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. Working fine so far on athn0 at pci2 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 17 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address xx:xx:xx:xx:xx:xx
