athn(4): switch Tx rate control to RA

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

athn(4): switch Tx rate control to RA

Stefan Sperling-5
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
blob - 43169fcccf130b28c5b2e0a95e1b7689244e43d5
blob + 2a8e9aacae52a047979890b95c2880a004b2495b
--- sys/dev/cardbus/if_athn_cardbus.c
+++ sys/dev/cardbus/if_athn_cardbus.c
@@ -43,7 +43,7 @@
 
 #include <net80211/ieee80211_var.h>
 #include <net80211/ieee80211_amrr.h>
-#include <net80211/ieee80211_mira.h>
+#include <net80211/ieee80211_ra.h>
 #include <net80211/ieee80211_radiotap.h>
 
 #include <dev/ic/athnreg.h>
blob - 3c11b4c004b4dd5fb12e7789f74bfb3e346b7acf
blob + bbe145570c10ef1466c23ae70f626634bd8d354d
--- sys/dev/ic/ar5008.c
+++ sys/dev/ic/ar5008.c
@@ -51,7 +51,7 @@
 
 #include <net80211/ieee80211_var.h>
 #include <net80211/ieee80211_amrr.h>
-#include <net80211/ieee80211_mira.h>
+#include <net80211/ieee80211_ra.h>
 #include <net80211/ieee80211_radiotap.h>
 
 #include <dev/ic/athnreg.h>
@@ -1064,7 +1064,7 @@ ar5008_tx_process(struct athn_softc *sc, int qid)
  struct athn_tx_buf *bf;
  struct ar_tx_desc *ds;
  uint8_t failcnt;
- int txfail;
+ int txfail = 0, rtscts;
 
  bf = SIMPLEQ_FIRST(&txq->head);
  if (bf == NULL)
@@ -1079,13 +1079,15 @@ ar5008_tx_process(struct athn_softc *sc, int qid)
 
  sc->sc_tx_timer = 0;
 
- txfail = (ds->ds_status1 & AR_TXS1_EXCESSIVE_RETRIES);
- if (txfail)
- ifp->if_oerrors++;
+ /* These status bits are valid if “FRM_XMIT_OK” is clear. */
+ if ((ds->ds_status1 & AR_TXS1_FRM_XMIT_OK) == 0) {
+ txfail = (ds->ds_status1 & AR_TXS1_EXCESSIVE_RETRIES);
+ if (txfail)
+ ifp->if_oerrors++;
+ if (ds->ds_status1 & AR_TXS1_UNDERRUN)
+ athn_inc_tx_trigger_level(sc);
+ }
 
- if (ds->ds_status1 & AR_TXS1_UNDERRUN)
- athn_inc_tx_trigger_level(sc);
-
  an = (struct athn_node *)bf->bf_ni;
  ni = (struct ieee80211_node *)bf->bf_ni;
 
@@ -1094,33 +1096,51 @@ ar5008_tx_process(struct athn_softc *sc, int qid)
  * for the final series used.  We must add the number of tries for
  * each series that was fully processed to punish transmit rates in
  * the earlier series which did not perform well.
- * If RTS/CTS was used, each series used the same transmit rate.
- * Ignore the series count in this case, since each series had
- * the same chance of success.
  */
  failcnt  = MS(ds->ds_status1, AR_TXS1_DATA_FAIL_CNT);
- if (!(ds->ds_ctl0 & (AR_TXC0_RTS_ENABLE | AR_TXC0_CTS_ENABLE))) {
- /* NB: Assume two tries per series. */
- failcnt += MS(ds->ds_status9, AR_TXS9_FINAL_IDX) * 2;
- }
+ /* Assume two tries per series, as per AR_TXC2_XMIT_DATA_TRIESx. */
+ failcnt += MS(ds->ds_status9, AR_TXS9_FINAL_IDX) * 2;
 
+ rtscts = (ds->ds_ctl0 & (AR_TXC0_RTS_ENABLE | AR_TXC0_CTS_ENABLE));
+
  /* Update rate control statistics. */
- if (ni->ni_flags & IEEE80211_NODE_HT) {
- an->mn.frames++;
- an->mn.ampdu_size = bf->bf_m->m_pkthdr.len + IEEE80211_CRC_LEN;
- an->mn.agglen = 1; /* XXX We do not yet support Tx agg. */
- if (failcnt > 0)
- an->mn.retries += failcnt;
- if (txfail)
- an->mn.txfail++;
+ if ((ni->ni_flags & IEEE80211_NODE_HT) && ic->ic_fixed_mcs == -1) {
+ const struct ieee80211_ht_rateset *rs =
+    ieee80211_ra_get_ht_rateset(bf->bf_txmcs,
+    ieee80211_node_supports_ht_sgi20(ni));
+ unsigned int retries = 0, i;
+ int mcs = bf->bf_txmcs;
+
+ /* With RTS/CTS each Tx series used the same MCS. */
+ if (rtscts) {
+ retries = failcnt;
+ } else {
+ for (i = 0; i < failcnt; i++) {
+ if (mcs > rs->min_mcs) {
+ ieee80211_ra_add_stats_ht(&an->rn,
+    ic, ni, mcs, 1, 1);
+ if (i % 2) /* two tries per series */
+ mcs--;
+ } else
+ retries++;
+ }
+ }
+
+ if (txfail && retries == 0) {
+ ieee80211_ra_add_stats_ht(&an->rn, ic, ni,
+    mcs, 1, 1);
+ } else {
+ ieee80211_ra_add_stats_ht(&an->rn, ic, ni,
+    mcs, retries + 1, retries);
+ }
  if (ic->ic_state == IEEE80211_S_RUN) {
 #ifndef IEEE80211_STA_ONLY
  if (ic->ic_opmode != IEEE80211_M_HOSTAP ||
     ni->ni_state == IEEE80211_STA_ASSOC)
 #endif
- ieee80211_mira_choose(&an->mn, ic, ni);
+ ieee80211_ra_choose(&an->rn, ic, ni);
  }
- } else {
+ } else if (ic->ic_fixed_rate == -1) {
  an->amn.amn_txcnt++;
  if (failcnt > 0)
  an->amn.amn_retrycnt++;
@@ -1492,11 +1512,6 @@ ar5008_tx(struct athn_softc *sc, struct mbuf *m, struc
  /* Use same fixed rate for all tries. */
  ridx[0] = ridx[1] = ridx[2] = ridx[3] =
     sc->fixed_ridx;
- } else if ((ni->ni_flags & IEEE80211_NODE_HT) &&
-    ieee80211_mira_is_probing(&an->mn)) {
- /* Use same fixed rate for all tries. */
- ridx[0] = ridx[1] = ridx[2] = ridx[3] =
-    ATHN_RIDX_MCS0 + ni->ni_txmcs;
  } else {
  /* Use fallback table of the node. */
  int txrate;
@@ -1562,6 +1577,7 @@ ar5008_tx(struct athn_softc *sc, struct mbuf *m, struc
  }
  bf->bf_m = m;
  bf->bf_ni = ni;
+ bf->bf_txmcs = ni->ni_txmcs;
  bf->bf_txflags = txflags;
 
  wh = mtod(m, struct ieee80211_frame *);
@@ -1607,16 +1623,12 @@ ar5008_tx(struct athn_softc *sc, struct mbuf *m, struc
  if (!IEEE80211_IS_MULTICAST(wh->i_addr1) &&
     (wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK) ==
     IEEE80211_FC0_TYPE_DATA) {
- int rtsthres = ic->ic_rtsthreshold;
  enum ieee80211_htprot htprot;
 
- if (ni->ni_flags & IEEE80211_NODE_HT)
- rtsthres = ieee80211_mira_get_rts_threshold(&an->mn,
-    ic, ni, totlen);
  htprot = (ic->ic_bss->ni_htop1 & IEEE80211_HTOP1_PROT_MASK);
 
  /* NB: Group frames are sent using CCK in 802.11b/g. */
- if (totlen > rtsthres) {
+ if (totlen > ic->ic_rtsthreshold) {
  ds->ds_ctl0 |= AR_TXC0_RTS_ENABLE;
  } else if (((ic->ic_flags & IEEE80211_F_USEPROT) &&
     athn_rates[ridx[0]].phy == IEEE80211_T_OFDM) ||
blob - c2b0d05b3fe2f8b721790c3a0955028c7d36e923
blob + 830f460f211fb2f0c84b482cdada36cdec4cbc4c
--- sys/dev/ic/ar5416.c
+++ sys/dev/ic/ar5416.c
@@ -51,7 +51,7 @@
 
 #include <net80211/ieee80211_var.h>
 #include <net80211/ieee80211_amrr.h>
-#include <net80211/ieee80211_mira.h>
+#include <net80211/ieee80211_ra.h>
 #include <net80211/ieee80211_radiotap.h>
 
 #include <dev/ic/athnreg.h>
blob - 14a7f15c8a72ad9d97c59433cfd811f6de4d2214
blob + 0db7b5f5520a3d4e1ebf0039157bbe55ead103a1
--- sys/dev/ic/ar9003.c
+++ sys/dev/ic/ar9003.c
@@ -51,7 +51,7 @@
 
 #include <net80211/ieee80211_var.h>
 #include <net80211/ieee80211_amrr.h>
-#include <net80211/ieee80211_mira.h>
+#include <net80211/ieee80211_ra.h>
 #include <net80211/ieee80211_radiotap.h>
 
 #include <dev/ic/athnreg.h>
blob - acb00c62ed242d348010edb679bcc289a0c9cd7f
blob + 91071ffff1e0408b552cb2d60ac4888c4d5edbc6
--- sys/dev/ic/ar9280.c
+++ sys/dev/ic/ar9280.c
@@ -51,7 +51,7 @@
 
 #include <net80211/ieee80211_var.h>
 #include <net80211/ieee80211_amrr.h>
-#include <net80211/ieee80211_mira.h>
+#include <net80211/ieee80211_ra.h>
 #include <net80211/ieee80211_radiotap.h>
 
 #include <dev/ic/athnreg.h>
blob - 057ea48e06ba07e29d1d055a29231cab2cef5616
blob + e4aaa701edc2d5bf1d3ec7a219ed097d8278fdd2
--- sys/dev/ic/ar9285.c
+++ sys/dev/ic/ar9285.c
@@ -52,7 +52,7 @@
 
 #include <net80211/ieee80211_var.h>
 #include <net80211/ieee80211_amrr.h>
-#include <net80211/ieee80211_mira.h>
+#include <net80211/ieee80211_ra.h>
 #include <net80211/ieee80211_radiotap.h>
 
 #include <dev/ic/athnreg.h>
blob - df89bf7d767b94c6089fee763c21c0dece84f4b9
blob + d46441f4677ed3962867068828b2ff88e56e0d7d
--- sys/dev/ic/ar9287.c
+++ sys/dev/ic/ar9287.c
@@ -51,7 +51,7 @@
 
 #include <net80211/ieee80211_var.h>
 #include <net80211/ieee80211_amrr.h>
-#include <net80211/ieee80211_mira.h>
+#include <net80211/ieee80211_ra.h>
 #include <net80211/ieee80211_radiotap.h>
 
 #include <dev/ic/athnreg.h>
blob - 34cead5782df98ee5b8ae5b0ca3d0beefc9b5864
blob + 7fc464067a5b8780137a01091e0b0eba9e443099
--- sys/dev/ic/ar9380.c
+++ sys/dev/ic/ar9380.c
@@ -49,7 +49,7 @@
 
 #include <net80211/ieee80211_var.h>
 #include <net80211/ieee80211_amrr.h>
-#include <net80211/ieee80211_mira.h>
+#include <net80211/ieee80211_ra.h>
 #include <net80211/ieee80211_radiotap.h>
 
 #include <dev/ic/athnreg.h>
blob - d20bb5615c20f30c2d7bc1bc4bfc66370dfeb232
blob + f410a488af23f47eb7900394a5e23e27924d033b
--- sys/dev/ic/athn.c
+++ sys/dev/ic/athn.c
@@ -53,7 +53,7 @@
 
 #include <net80211/ieee80211_var.h>
 #include <net80211/ieee80211_amrr.h>
-#include <net80211/ieee80211_mira.h>
+#include <net80211/ieee80211_ra.h>
 #include <net80211/ieee80211_radiotap.h>
 
 #include <dev/ic/athnreg.h>
@@ -127,11 +127,8 @@ int athn_hw_reset(struct athn_softc *, struct ieee802
 struct ieee80211_node *athn_node_alloc(struct ieee80211com *);
 void athn_newassoc(struct ieee80211com *, struct ieee80211_node *,
     int);
-void athn_node_leave(struct ieee80211com *, struct ieee80211_node *);
 int athn_media_change(struct ifnet *);
 void athn_next_scan(void *);
-void athn_iter_mira_delete(void *, struct ieee80211_node *);
-void athn_delete_mira_nodes(struct athn_softc *);
 int athn_newstate(struct ieee80211com *, enum ieee80211_state,
     int);
 void athn_updateedca(struct ieee80211com *);
@@ -379,9 +376,6 @@ athn_attach(struct athn_softc *sc)
  if_attach(ifp);
  ieee80211_ifattach(ifp);
  ic->ic_node_alloc = athn_node_alloc;
-#ifndef IEEE80211_STA_ONLY
- ic->ic_node_leave = athn_node_leave;
-#endif
  ic->ic_newassoc = athn_newassoc;
  ic->ic_updateslot = athn_updateslot;
  ic->ic_updateedca = athn_updateedca;
@@ -404,13 +398,10 @@ void
 athn_detach(struct athn_softc *sc)
 {
  struct ifnet *ifp = &sc->sc_ic.ic_if;
- struct ieee80211com *ic = &sc->sc_ic;
  int qid;
 
  timeout_del(&sc->scan_to);
  timeout_del(&sc->calib_to);
- if (ic->ic_flags & IEEE80211_F_HTON)
- athn_delete_mira_nodes(sc);
 
  if (!(sc->flags & ATHN_FLAG_USB)) {
  for (qid = 0; qid < ATHN_QID_COUNT; qid++)
@@ -2479,7 +2470,7 @@ athn_node_alloc(struct ieee80211com *ic)
 
  an = malloc(sizeof(struct athn_node), M_DEVBUF, M_NOWAIT | M_ZERO);
  if (an && (ic->ic_flags & IEEE80211_F_HTON))
- ieee80211_mira_node_init(&an->mn);
+ ieee80211_ra_node_init(&an->rn);
  return (struct ieee80211_node *)an;
 }
 
@@ -2495,7 +2486,7 @@ athn_newassoc(struct ieee80211com *ic, struct ieee8021
  if ((ni->ni_flags & IEEE80211_NODE_HT) == 0)
  ieee80211_amrr_node_init(&sc->amrr, &an->amn);
  else if (ic->ic_opmode == IEEE80211_M_STA)
- ieee80211_mira_node_init(&an->mn);
+ ieee80211_ra_node_init(&an->rn);
 
  /* Start at lowest available bit-rate, AMRR will raise. */
  ni->ni_txrate = 0;
@@ -2552,16 +2543,6 @@ athn_newassoc(struct ieee80211com *ic, struct ieee8021
  }
 }
 
-#ifndef IEEE80211_STA_ONLY
-void
-athn_node_leave(struct ieee80211com *ic, struct ieee80211_node *ni)
-{
- struct athn_node *an = (void *)ni;
- if (ic->ic_flags & IEEE80211_F_HTON)
- ieee80211_mira_cancel_timeouts(&an->mn);
-}
-#endif
-
 int
 athn_media_change(struct ifnet *ifp)
 {
@@ -2604,26 +2585,6 @@ athn_next_scan(void *arg)
  splx(s);
 }
 
-void
-athn_iter_mira_delete(void *arg, struct ieee80211_node *ni)
-{
- struct athn_node *an = (struct athn_node *)ni;
- ieee80211_mira_cancel_timeouts(&an->mn);
-}
-
-/* Delete pending timeouts managed by MiRA. */
-void
-athn_delete_mira_nodes(struct athn_softc *sc)
-{
- struct ieee80211com *ic = &sc->sc_ic;
-
- if (ic->ic_opmode == IEEE80211_M_STA) {
- struct athn_node *an = (struct athn_node *)ic->ic_bss;
- ieee80211_mira_cancel_timeouts(&an->mn);
- } else
- ieee80211_iterate_nodes(ic, athn_iter_mira_delete, sc);
-}
-
 int
 athn_newstate(struct ieee80211com *ic, enum ieee80211_state nstate, int arg)
 {
@@ -2634,10 +2595,6 @@ athn_newstate(struct ieee80211com *ic, enum ieee80211_
 
  timeout_del(&sc->calib_to);
 
- if ((ic->ic_flags & IEEE80211_F_HTON) &&
-    ic->ic_state == IEEE80211_S_RUN && nstate != IEEE80211_S_RUN)
- athn_delete_mira_nodes(sc);
-
  switch (nstate) {
  case IEEE80211_S_INIT:
  athn_set_led(sc, 0);
blob - c21c69794415adb83a18fc08809ff718d85af409
blob + da86bf73ce43f3278abd049a08e15b73d8a74e33
--- sys/dev/ic/athnvar.h
+++ sys/dev/ic/athnvar.h
@@ -79,6 +79,7 @@ struct athn_tx_buf {
 
  struct mbuf *bf_m;
  struct ieee80211_node *bf_ni;
+ int bf_txmcs;
  int bf_txflags;
 #define ATHN_TXFLAG_PAPRD (1 << 0)
 #define ATHN_TXFLAG_CAB (1 << 1)
@@ -295,7 +296,7 @@ static const uint16_t ar_mcs_ndbps[][2] = {
 struct athn_node {
  struct ieee80211_node ni;
  struct ieee80211_amrr_node amn;
- struct ieee80211_mira_node mn;
+ struct ieee80211_ra_node rn;
  uint8_t ridx[ATHN_NUM_RATES];
  uint8_t fallback[ATHN_NUM_RATES];
  uint8_t sta_index;
blob - 874f3523b5eff7240135126401c71d3a34395317
blob + b7c75ef72cdd787b4bda3264ba603e86061c1985
--- sys/dev/pci/if_athn_pci.c
+++ sys/dev/pci/if_athn_pci.c
@@ -43,7 +43,7 @@
 
 #include <net80211/ieee80211_var.h>
 #include <net80211/ieee80211_amrr.h>
-#include <net80211/ieee80211_mira.h>
+#include <net80211/ieee80211_ra.h>
 #include <net80211/ieee80211_radiotap.h>
 
 #include <dev/ic/athnreg.h>
blob - 771baafcdac926e3752111a37d6963447775c8ab
blob + 3655df8bade95c8e7d42cf9216412470913c08c5
--- sys/dev/usb/if_athn_usb.c
+++ sys/dev/usb/if_athn_usb.c
@@ -49,7 +49,7 @@
 
 #include <net80211/ieee80211_var.h>
 #include <net80211/ieee80211_amrr.h>
-#include <net80211/ieee80211_mira.h>
+#include <net80211/ieee80211_ra.h>
 #include <net80211/ieee80211_radiotap.h>
 
 #include <dev/ic/athnreg.h>

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): switch Tx rate control to RA

Klemens Nanni-2
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

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): switch Tx rate control to RA

Mikolaj Kucharski-3
In reply to this post by Stefan Sperling-5
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
    [hidden email]:/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 0xf8000000, bus 0-64
acpimadt0 at acpi0 addr 0xfee00000: 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 0xfec00000, version 21, 24 pins
ioapic1 at mainbus0: apid 5 pa 0xfec20000, 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: 0x00000000 0x00000011 0x00000001
acpicmos0 at acpi0
amdgpio0 at acpi0 GPIO uid 0 addr 0xfed81500/0x300 irq 7, 184 pins
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
"BOOT0000" at acpi0 not configured
acpicpu0 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu1 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu2 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu3 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 115 degC
cpu0: 998 MHz: speeds: 1000 800 600 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD 16h Root Complex" rev 0x00
vendor "AMD", unknown product 0x1567 (class system subclass IOMMU, rev 0x00) at pci0 dev 0 function 2 not configured
pchb1 at pci0 dev 2 function 0 "AMD 16h Host" rev 0x00
ppb0 at pci0 dev 2 function 2 "AMD 16h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel I211" rev 0x03: msi, address 00:0d:b9:4a:40:88
ppb1 at pci0 dev 2 function 3 "AMD 16h PCIE" rev 0x00: msi
pci2 at ppb1 bus 2
em1 at pci2 dev 0 function 0 "Intel I211" rev 0x03: msi, address 00:0d:b9:4a:40:89
ppb2 at pci0 dev 2 function 4 "AMD 16h PCIE" rev 0x00: msi
pci3 at ppb2 bus 3
em2 at pci3 dev 0 function 0 "Intel I211" rev 0x03: msi, address 00:0d:b9:4a:40:8a
ppb3 at pci0 dev 2 function 5 "AMD 16h PCIE" rev 0x00: msi
pci4 at ppb3 bus 4
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:34:e4:23
ccp0 at pci0 dev 8 function 0 "AMD 16h Crypto" rev 0x00
xhci0 at pci0 dev 16 function 0 "AMD Bolton xHCI" rev 0x11: msi, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1
ahci0 at pci0 dev 17 function 0 "AMD Hudson-2 SATA" rev 0x40: apic 4 int 19, AHCI 1.3
ahci0: port 0: 6.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, KINGSTON SMS200S, 60AA> naa.50026b727603c6f0
sd0: 114473MB, 512 bytes/sector, 234441648 sectors, thin
ehci0 at pci0 dev 19 function 0 "AMD Hudson-2 USB2" rev 0x39: apic 4 int 18
usb1 at ehci0: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
piixpm0 at pci0 dev 20 function 0 "AMD Hudson-2 SMBus" rev 0x42: SMI
iic0 at piixpm0
iic1 at piixpm0
iic1: addr 0x4c 3e=00 48=00 4a=00 4e=00 fc=00 fe=00 words 00=ffff 01=ffff 02=ffff 03=ffff 04=ffff 05=ffff 06=ffff 07=ffff
pcib0 at pci0 dev 20 function 3 "AMD Hudson-2 LPC" rev 0x11
sdhc0 at pci0 dev 20 function 7 "AMD Bolton SD/MMC" rev 0x01: apic 4 int 16
sdhc0: SDHC 2.0, 50 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed, dma
pchb2 at pci0 dev 24 function 0 "AMD 16h Link Cfg" rev 0x00
pchb3 at pci0 dev 24 function 1 "AMD 16h Address Map" rev 0x00
pchb4 at pci0 dev 24 function 2 "AMD 16h DRAM Cfg" rev 0x00
km0 at pci0 dev 24 function 3 "AMD 16h Misc Cfg" rev 0x00
pchb5 at pci0 dev 24 function 4 "AMD 16h CPU Power" rev 0x00
pchb6 at pci0 dev 24 function 5 "AMD 16h Misc Cfg" rev 0x00
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
intr_establish: pic ioapic0 pin 7: can't share type 3 with 2
wbsio0 at isa0 port 0x2e/2: NCT5104D rev 0x53
vmm0 at mainbus0: SVM/RVI
uslcom0 at uhub0 port 4 configuration 1 interface 0 "Silicon Labs CP2102 USB to UART Bridge Controller" rev 1.10/1.00 addr 2
ucom0 at uslcom0 portno 0
uhub2 at uhub1 port 1 configuration 1 interface 0 "Advanced Micro Devices Hub" rev 2.00/0.18 addr 2
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (dd930612ce0c6e49.a) swap on sd0b dump on sd0b

--
Regards,
 Mikolaj

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): switch Tx rate control to RA

Mikolaj Kucharski-3
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).

--
Regards,
 Mikolaj

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): switch Tx rate control to RA

Stefan Sperling-5
On Tue, Mar 23, 2021 at 07:47:08PM +0000, 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.

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): switch Tx rate control to RA

Mikolaj Kucharski-3
On Tue, Mar 23, 2021 at 08:52:12PM +0100, Stefan Sperling wrote:
> On Tue, Mar 23, 2021 at 07:47:08PM +0000, 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

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): switch Tx rate control to RA

Kevin Lo
In reply to this post by Stefan Sperling-5
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! :)

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): switch Tx rate control to RA

Lauri Tirkkonen-3
In reply to this post by Stefan Sperling-5
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 <omitted>

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 10000 from athn(4) hostap to iwn(4):
before:
        10000 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:
        10000 packets transmitted, 10000 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

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): switch Tx rate control to RA

Scott Bennett
In reply to this post by Stefan Sperling-5
On Tue, 23 Mar 2021 18:01:27 +0100, Stefan Sperling <[hidden email]> 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<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> 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
    [hidden email]:/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 0xfee00000: 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 0xfec00000, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf8000000, 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: 0x00000004 0x00000011 0x00000001
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 acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpitz0 at acpi0: critical temperature is 107 degC
acpivideo0 at acpi0: VID_
acpivout0 at acpivideo0: LCD_
cpu0: using VERW MDS workaround (except on vmm entry)
cpu0: Enhanced SpeedStep 2592 MHz: speeds: 2601, 2600, 2500, 2400, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09
drm0 at inteldrm0
inteldrm0: msi, IVYBRIDGE, gen 7
xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
"Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address d4:be:d9:xx:xx:xx
ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 16
usb1 at ehci0: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 7 Series HD Audio" rev 0x04: msi
azalia0: codecs: IDT/0x76df, Intel/0x2806, using IDT/0x76df
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 7 Series PCIE" rev 0xc4: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel 7 Series PCIE" rev 0xc4: msi
pci2 at ppb1 bus 2
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
ppb2 at pci0 dev 28 function 2 "Intel 7 Series PCIE" rev 0xc4: msi
pci3 at ppb2 bus 3
ppb3 at pci0 dev 28 function 3 "Intel 7 Series PCIE" rev 0xc4: msi
pci4 at ppb3 bus 7
ppb4 at pci0 dev 28 function 5 "Intel 7 Series PCIE" rev 0xc4: msi
pci5 at ppb4 bus 11
sdhc0 at pci5 dev 0 function 0 vendor "O2 Micro", unknown product 0x8221 rev 0x05: apic 2 int 17
sdhc0: SDHC 2.0, 50 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed, dma
ehci1 at pci0 dev 29 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 21
usb2 at ehci1: USB revision 2.0
uhub2 at usb2 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
pcib0 at pci0 dev 31 function 0 "Intel QM77 LPC" rev 0x04
ahci0 at pci0 dev 31 function 2 "Intel 7 Series AHCI" rev 0x04: msi, AHCI 1.3
ahci0: port 0: 6.0Gb/s
ahci0: port 1: 1.5Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, CLOVER CN-M750M, 2BA3> naa.0000000000000000
sd0: 715404MB, 512 bytes/sector, 1465149168 sectors
cd0 at scsibus1 targ 1 lun 0: <MATSHITA, DVD+-RW UJ8B2, 1.01> removable
ichiic0 at pci0 dev 31 function 3 "Intel 7 Series SMBus" rev 0x04: apic 2 int 18
iic0 at ichiic0
iic0: addr 0x29 07=ff 0f=33 10=8c 11=33 12=10 13=65 14=a5 15=21 16=1a 17=1b 18=1d 19=a0 1a=60 1b=74 1c=c0 1e=20 20=7f 22=40 27=ff 29=fb 2b=0f 2d=3f 2f=20 30=95 31=29 32=0e 33=16 87=ff 8f=33 90=8c 91=33 92=10 93=65 94=a5 95=21 96=1a 97=1b 98=1d 99=a0 9a=60 9b=74 9c=c0 9e=20 a0=7f a2=40 a7=ff a9=fc ab=0d ad=40 af=20 b0=95 b1=29 b2=0e b3=16 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=ffff
spdmem0 at iic0 addr 0x50: 8GB DDR3 SDRAM PC3-10600 SO-DIMM
spdmem1 at iic0 addr 0x52: 8GB DDR3 SDRAM PC3-10600 SO-DIMM
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm0 at mainbus0: VMX/EPT
uhub3 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
uhub4 at uhub2 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
sd1 at scsibus3 targ 1 lun 0: <OPENBSD, SR CRYPTO, 006>
sd1: 715402MB, 512 bytes/sector, 1465143473 sectors
root on sd1a (69636c59313db511.a) swap on sd1b dump on sd1b
inteldrm0: 1366x768, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
wsdisplay0: screen 1-5 added (std, vt100 emulation)

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): switch Tx rate control to RA

Stefan Sperling-5
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=158992287500008&r=1&w=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!

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): switch Tx rate control to RA

Mikolaj Kucharski-3
In reply to this post by Mikolaj Kucharski-3
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

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): switch Tx rate control to RA

Mikolaj Kucharski-3
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

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): switch Tx rate control to RA

Uwe Werler-4
In reply to this post by Stefan Sperling-5
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
3004        2287840       18.284  100.00%

With patch apu -> laptop:

Conn:   1 Mbps:       27.987 Peak Mbps:       30.027 Avg Mbps:       27.987
5003        3528776       28.202  100.00%                            

Without patch laptop -> apu:

Conn:   1 Mbps:        7.900 Peak Mbps:       13.750 Avg Mbps:        7.900
7015         928168        7.388  100.00%

Without patch apu -> laptop:

Conn:   1 Mbps:        4.247 Peak Mbps:        7.231 Avg Mbps:        4.247
6055         489804        3.868  100.00%

So notable performance improvements!

Thank you very much for your hard work!

-- wq: ~uw

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): switch Tx rate control to RA

Mikolaj Kucharski-3
In reply to this post by Mikolaj Kucharski-3
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

Reply | Threaded
Open this post in threaded view
|

Re: athn(4): switch Tx rate control to RA

Stefan Sperling-5
On Sat, Apr 03, 2021 at 08:30:14PM +0000, 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.