Re: 11n Tx aggregation for iwm(4)
Sebastian Benoit(be...@openbsd.org) on 2020.06.29 16:18:03 +0200: > Stefan Sperling(s...@stsp.name) on 2020.06.26 14:45:53 +0200: > > This patch adds support for 11n Tx aggregation to iwm(4). > > > > Please help with testing if you can by running the patch and using wifi > > as usual. Nothing should change, except that Tx speed may potentially > > improve. If you have time to run before/after performance measurements with > > tcpbench or such, that would be nice. But it's not required for testing. > > > > If Tx aggregation is active then netstat will show a non-zero output block > > ack > > agreement counter: > > > > $ netstat -W iwm0 | grep 'output block' > > 3 new output block ack agreements > > 0 output block ack agreements timed out > > 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 9c:da:3e:6f:51:a4 > > With intel firmware updated: intel-firmware-20200520v0->20200609v0: ok He, i meant to say with "iwm-firmware-20191022p1" as before, but copied the wrong line and then wrote the correct thing for it :)
Re: 11n Tx aggregation for iwm(4)
Stefan Sperling(s...@stsp.name) on 2020.06.26 14:45:53 +0200: > This patch adds support for 11n Tx aggregation to iwm(4). > > Please help with testing if you can by running the patch and using wifi > as usual. Nothing should change, except that Tx speed may potentially > improve. If you have time to run before/after performance measurements with > tcpbench or such, that would be nice. But it's not required for testing. > > If Tx aggregation is active then netstat will show a non-zero output block ack > agreement counter: > > $ netstat -W iwm0 | grep 'output block' > 3 new output block ack agreements > 0 output block ack agreements timed out 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 9c:da:3e:6f:51:a4 With intel firmware updated: intel-firmware-20200520v0->20200609v0: ok With the patch i get a speedup from ca 25 MBit/s to ca. 35 MBit/s. However i do not see any 'new output block ack agreements'. 0 new output block ack agreements 0 output block ack agreements timed out This is with two TP-Link APs (Archer A7 or something like that). /Benno
Re: 11n Tx aggregation for iwm(4)
Woahhh, was also trying 5GHz (and tcpbench against one of our bsd servers in DMZ): 469651560 bytes sent over 85.291 seconds bandwidth min/avg/max/std-dev = 3.475/43.927/87.071/29.809 Mbps 6 new output block ack agreements 0 output block ack agreements timed out (Tomorrow @work I will test against our new APs. My AP @home is a Technicolor MediaAccess TG789vac). mbk Uwe On 29 Jun 09:48, Uwe Werler wrote: > Hi Stefan, > > for me the patch works in mode 11n: > > before (OpenBSD 6.7-current (GENERIC.MP) #304: Fri Jun 26 02:08:50 MDT 2020) > bandwidth min/avg/max/std-dev = 2.354/12.319/15.391/3.850 Mbps > > with patch (OpenBSD 6.7-current (GENERIC.MP) #0: Mon Jun 29 09:35:24 GMT 2020) > bandwidth min/avg/max/std-dev = 12.174/31.411/57.746/15.154 Mbps > > 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 60:f6:77:bc:3a:04 > > (mode 11g: bandwidth min/avg/max/std-dev = 0.620/0.844/1.101/0.153 Mbps) > > mbk Uwe > > > On 26 Jun 14:45, Stefan Sperling wrote: > > This patch adds support for 11n Tx aggregation to iwm(4). > > > > Please help with testing if you can by running the patch and using wifi > > as usual. Nothing should change, except that Tx speed may potentially > > improve. If you have time to run before/after performance measurements with > > tcpbench or such, that would be nice. But it's not required for testing. > > > > If Tx aggregation is active then netstat will show a non-zero output block > > ack > > agreement counter: > > > > $ netstat -W iwm0 | grep 'output block' > > 3 new output block ack agreements > > 0 output block ack agreements timed out > > > > It would be great to get at least one test for all the chipsets the driver > > supports: 7260, 7265, 3160, 3165, 3168, 8260, 8265, 9260, 9560 > > The behaviour of the access point also matters a great deal. It won't > > hurt to test the same chipset against several different access points. > > > > I have tested this version on 8265 only so far. I've run older revisions > > of this patch on 7265 so I'm confident that this chip will work, too. > > So far, the APs I have tested against are athn(4) in 11a mode and in 11n > > mode with the 'nomimo' nwflag, and a Sagemcom 11ac AP. All on 5Ghz channels. > > > > diff refs/heads/master refs/heads/txagg > > blob - 3a75d07a60a7eb4c66540474e47aeffd7a85250a > > blob + 853bdd1290ad509f5fce7b5bf20550f458a2b460 > > --- sys/dev/pci/if_iwm.c > > +++ sys/dev/pci/if_iwm.c > > @@ -144,6 +144,8 @@ > > #include > > #include > > #include > > +#include /* for SEQ_LT */ > > +#undef DPRINTF /* defined in ieee80211_priv.h */ > > > > #define DEVNAME(_s)((_s)->sc_dev.dv_xname) > > > > @@ -299,7 +301,8 @@ int iwm_nic_rx_mq_init(struct iwm_softc *); > > intiwm_nic_tx_init(struct iwm_softc *); > > intiwm_nic_init(struct iwm_softc *); > > intiwm_enable_ac_txq(struct iwm_softc *, int, int); > > -intiwm_enable_txq(struct iwm_softc *, int, int, int); > > +intiwm_enable_txq(struct iwm_softc *, int, int, int, int, uint8_t, > > + uint16_t); > > intiwm_post_alive(struct iwm_softc *); > > struct iwm_phy_db_entry *iwm_phy_db_get_section(struct iwm_softc *, > > uint16_t, > > uint16_t); > > @@ -334,12 +337,12 @@ void iwm_ampdu_rx_stop(struct ieee80211com *, struct > > i > > uint8_t); > > void iwm_sta_rx_agg(struct iwm_softc *, struct ieee80211_node *, > > uint8_t, > > uint16_t, uint16_t, int); > > -#ifdef notyet > > +void iwm_sta_tx_agg(struct iwm_softc *, struct ieee80211_node *, > > uint8_t, > > + uint16_t, uint16_t, int); > > intiwm_ampdu_tx_start(struct ieee80211com *, struct ieee80211_node > > *, > > uint8_t); > > void iwm_ampdu_tx_stop(struct ieee80211com *, struct ieee80211_node > > *, > > uint8_t); > > -#endif > > void iwm_ba_task(void *); > > > > intiwm_parse_nvm_data(struct iwm_softc *, const uint16_t *, > > @@ -372,14 +375,25 @@ int iwm_rxmq_get_signal_strength(struct iwm_softc > > *, s > > void iwm_rx_rx_phy_cmd(struct iwm_softc *, struct iwm_rx_packet *, > > struct iwm_rx_data *); > > intiwm_get_noise(const struct iwm_statistics_rx_non_phy *); > > +void iwm_txq_advance(struct iwm_softc *, struct iwm_tx_ring *, int); > > +void iwm_ampdu_tx_done(struct iwm_softc
Re: 11n Tx aggregation for iwm(4)
Hi Stefan, for me the patch works in mode 11n: before (OpenBSD 6.7-current (GENERIC.MP) #304: Fri Jun 26 02:08:50 MDT 2020) bandwidth min/avg/max/std-dev = 2.354/12.319/15.391/3.850 Mbps with patch (OpenBSD 6.7-current (GENERIC.MP) #0: Mon Jun 29 09:35:24 GMT 2020) bandwidth min/avg/max/std-dev = 12.174/31.411/57.746/15.154 Mbps 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 60:f6:77:bc:3a:04 (mode 11g: bandwidth min/avg/max/std-dev = 0.620/0.844/1.101/0.153 Mbps) mbk Uwe On 26 Jun 14:45, Stefan Sperling wrote: > This patch adds support for 11n Tx aggregation to iwm(4). > > Please help with testing if you can by running the patch and using wifi > as usual. Nothing should change, except that Tx speed may potentially > improve. If you have time to run before/after performance measurements with > tcpbench or such, that would be nice. But it's not required for testing. > > If Tx aggregation is active then netstat will show a non-zero output block ack > agreement counter: > > $ netstat -W iwm0 | grep 'output block' > 3 new output block ack agreements > 0 output block ack agreements timed out > > It would be great to get at least one test for all the chipsets the driver > supports: 7260, 7265, 3160, 3165, 3168, 8260, 8265, 9260, 9560 > The behaviour of the access point also matters a great deal. It won't > hurt to test the same chipset against several different access points. > > I have tested this version on 8265 only so far. I've run older revisions > of this patch on 7265 so I'm confident that this chip will work, too. > So far, the APs I have tested against are athn(4) in 11a mode and in 11n > mode with the 'nomimo' nwflag, and a Sagemcom 11ac AP. All on 5Ghz channels. > > diff refs/heads/master refs/heads/txagg > blob - 3a75d07a60a7eb4c66540474e47aeffd7a85250a > blob + 853bdd1290ad509f5fce7b5bf20550f458a2b460 > --- sys/dev/pci/if_iwm.c > +++ sys/dev/pci/if_iwm.c > @@ -144,6 +144,8 @@ > #include > #include > #include > +#include /* for SEQ_LT */ > +#undef DPRINTF /* defined in ieee80211_priv.h */ > > #define DEVNAME(_s) ((_s)->sc_dev.dv_xname) > > @@ -299,7 +301,8 @@ int iwm_nic_rx_mq_init(struct iwm_softc *); > int iwm_nic_tx_init(struct iwm_softc *); > int iwm_nic_init(struct iwm_softc *); > int iwm_enable_ac_txq(struct iwm_softc *, int, int); > -int iwm_enable_txq(struct iwm_softc *, int, int, int); > +int iwm_enable_txq(struct iwm_softc *, int, int, int, int, uint8_t, > + uint16_t); > int iwm_post_alive(struct iwm_softc *); > struct iwm_phy_db_entry *iwm_phy_db_get_section(struct iwm_softc *, uint16_t, > uint16_t); > @@ -334,12 +337,12 @@ voidiwm_ampdu_rx_stop(struct ieee80211com *, struct > i > uint8_t); > void iwm_sta_rx_agg(struct iwm_softc *, struct ieee80211_node *, uint8_t, > uint16_t, uint16_t, int); > -#ifdef notyet > +void iwm_sta_tx_agg(struct iwm_softc *, struct ieee80211_node *, uint8_t, > + uint16_t, uint16_t, int); > int iwm_ampdu_tx_start(struct ieee80211com *, struct ieee80211_node *, > uint8_t); > void iwm_ampdu_tx_stop(struct ieee80211com *, struct ieee80211_node *, > uint8_t); > -#endif > void iwm_ba_task(void *); > > int iwm_parse_nvm_data(struct iwm_softc *, const uint16_t *, > @@ -372,14 +375,25 @@ int iwm_rxmq_get_signal_strength(struct iwm_softc > *, s > void iwm_rx_rx_phy_cmd(struct iwm_softc *, struct iwm_rx_packet *, > struct iwm_rx_data *); > int iwm_get_noise(const struct iwm_statistics_rx_non_phy *); > +void iwm_txq_advance(struct iwm_softc *, struct iwm_tx_ring *, int); > +void iwm_ampdu_tx_done(struct iwm_softc *, struct iwm_cmd_header *, > + struct iwm_node *, struct iwm_tx_ring *, uint32_t, uint8_t, > + uint8_t, uint16_t, int, struct iwm_agg_tx_status *); > int iwm_ccmp_decap(struct iwm_softc *, struct mbuf *, > struct ieee80211_node *); > void iwm_rx_frame(struct iwm_softc *, struct mbuf *, int, uint32_t, int, int, > uint32_t, struct ieee80211_rxinfo *, struct mbuf_list *); > -void iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_rx_packet *, > - struct iwm_node *, int, int); > +void iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_tx_resp *, > + struct iwm_node *, int, int, int); > +void iwm_txd_done(struct iwm_softc *, struct iwm_tx_data *); > void iwm_rx_tx_cmd(struct iwm_softc *, struct iwm_rx_packet *, > struct iwm_rx_data *); > +void iwm_clear_oactive(struct iwm_softc *, struct iwm_tx_ring *); > +void iwm_mira_choose(struct iwm_softc *, struct ieee80211_node *); > +void iwm_ampdu_ra
Re: 11n Tx aggregation for iwm(4)
Tested on a "Intel Dual Band Wireless-AC 9260" rev 0x29, msix (hw rev 0x320, fw ver 34.3125811985.0) I seem to be getting "iwm0: fatal firmware error" a few seconds after the 4-way handshake. I can send a few packets, so it sure connects and all, but then it fails shortly after. iwm0: begin active scan iwm0: INIT -> SCAN iwm0: end active scan iwm0: + 70:73:cb:cb:c3:86 40 +45 54M ess privacy rsn "FRA" iwm0: SCAN -> AUTH iwm0: sending auth to 70:73:cb:cb:c3:86 on channel 40 mode 11a iwm0: AUTH -> ASSOC iwm0: sending assoc_req to 70:73:cb:cb:c3:86 on channel 40 mode 11a iwm0: ASSOC -> RUN iwm0: associated with 70:73:cb:cb:c3:86 ssid "FRA" channel 40 start MCS 0 long preamble short slot time HT enabled iwm0: missed beacon threshold set to 30 beacons, beacon interval is 100 TU iwm0: received msg 1/4 of the 4-way handshake from 70:73:cb:cb:c3:86 iwm0: sending msg 2/4 of the 4-way handshake to 70:73:cb:cb:c3:86 iwm0: received msg 3/4 of the 4-way handshake from 70:73:cb:cb:c3:86 iwm0: sending msg 4/4 of the 4-way handshake to 70:73:cb:cb:c3:86 iwm0: sending action to 70:73:cb:cb:c3:86 on channel 40 mode 11n iwm0: fatal firmware error
Re: 11n Tx aggregation for iwm(4)
On Fri, Jun 26, 2020 at 02:45:53PM +0200, Stefan Sperling wrote: > This patch adds support for 11n Tx aggregation to iwm(4). iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0x73, msi AP is Zyxel USG40W Before : bandwidth min/avg/max/std-dev = 9.800/14.000/14.214/0.606 Mbps After : bandwidth min/avg/max/std-dev = 8.124/47.270/57.076/8.906 Mbps
Re: 11n Tx aggregation for iwm(4)
On Fri, Jun 26, 2020 at 02:45:53PM +0200, Stefan Sperling wrote: > This patch adds support for 11n Tx aggregation to iwm(4). > > Please help with testing if you can by running the patch and using wifi > as usual. Nothing should change, except that Tx speed may potentially > improve. If you have time to run before/after performance measurements with > tcpbench or such, that would be nice. But it's not required for testing. > > If Tx aggregation is active then netstat will show a non-zero output block ack > agreement counter: > > $ netstat -W iwm0 | grep 'output block' > 3 new output block ack agreements > 0 output block ack agreements timed out > > It would be great to get at least one test for all the chipsets the driver > supports: 7260, 7265, 3160, 3165, 3168, 8260, 8265, 9260, 9560 > The behaviour of the access point also matters a great deal. It won't > hurt to test the same chipset against several different access points. > > I have tested this version on 8265 only so far. I've run older revisions > of this patch on 7265 so I'm confident that this chip will work, too. > So far, the APs I have tested against are athn(4) in 11a mode and in 11n > mode with the 'nomimo' nwflag, and a Sagemcom 11ac AP. All on 5Ghz channels. > Sure you've got plenty of 8265 tests, but the diff tripled my speed against my apple airport extreme. iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi -- Tracey Emery
Re: 11n Tx aggregation for iwm(4)
On 2020-06-26 20:11, Johan Huldtgren wrote: > hello, > > On 2020-06-26 14:45, Stefan Sperling wrote: > > It would be great to get at least one test for all the chipsets the driver > > supports: 7260, 7265, 3160, 3165, 3168, 8260, 8265, 9260, 9560 > > The behaviour of the access point also matters a great deal. It won't > > hurt to test the same chipset against several different access points. > > tested on: > > iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi > > AP is a Ruckus 7363. > > $ netstat -W iwm0 | grep "output block" > > > 6 new output block ack agreements > 0 output block ack agreements timed out > > Before: > > bandwidth min/avg/max/std-dev = 16.780/18.325/19.939/1.235 Mbps > > After: > > bandwidth min/avg/max/std-dev = 0.000/15.559/51.631/19.548 Mbps Testing against a slightly different AP (Ruckus 7372): before patch: bandwidth min/avg/max/std-dev = 0.092/14.665/22.589/9.992 Mbps after patch: bandwidth min/avg/max/std-dev = 7.020/24.596/41.121/11.300 Mbps This is the reported mode: media: IEEE802.11 autoselect (HT-MCS13 mode 11n) .jh
Re: 11n Tx aggregation for iwm(4)
Works for me on a 7260. [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 108 MBytes 90.1 Mbits/sec
Re: 11n Tx aggregation for iwm(4)
On Fri, Jun 26, 2020 at 06:14:48PM +0200, Landry Breuil wrote: > On Fri, Jun 26, 2020 at 02:45:53PM +0200, Stefan Sperling wrote: > > This patch adds support for 11n Tx aggregation to iwm(4). > > > > Please help with testing if you can by running the patch and using wifi > > as usual. Nothing should change, except that Tx speed may potentially > > improve. If you have time to run before/after performance measurements with > > tcpbench or such, that would be nice. But it's not required for testing. > > > > If Tx aggregation is active then netstat will show a non-zero output block > > ack > > agreement counter: > > > > $ netstat -W iwm0 | grep 'output block' > > 3 new output block ack agreements > > 0 output block ack agreements timed out > > > > It would be great to get at least one test for all the chipsets the driver > > supports: 7260, 7265, 3160, 3165, 3168, 8260, 8265, 9260, 9560 > > The behaviour of the access point also matters a great deal. It won't > > hurt to test the same chipset against several different access points. > > > > I have tested this version on 8265 only so far. I've run older revisions > > of this patch on 7265 so I'm confident that this chip will work, too. > > So far, the APs I have tested against are athn(4) in 11a mode and in 11n > > mode with the 'nomimo' nwflag, and a Sagemcom 11ac AP. All on 5Ghz channels. > > no difference on X1c3 w/ > iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, msi > iwm0: hw rev 0x210, fw ver 17.3216344376.0, > > using a crappy old fonera as AP, serving as a bridge to gw w/ tcpbench. > > bandwidth min/avg/max/std-dev = 22.519/22.704/22.995/0.162 Mbps > > same bw both ways it seems. so no change against this old AP, which selects: media: IEEE802.11 autoselect (OFDM48 mode 11g) or sometimes media: IEEE802.11 autoselect (OFDM12 mode 11g) or media: IEEE802.11 autoselect (OFDM6 mode 11g) but if i connect to the ISP's box wifi, which selects: media: IEEE802.11 autoselect (HT-MCS8 mode 11n) the performance is horrible, i have a lot of lag, and tcpbench says: bandwidth min/avg/max/std-dev = 0.000/1.576/10.069/2.781 Mbps i have some iwm firmware errors in dmesg. without the patch, its a bit the same: bandwidth min/avg/max/std-dev = 0.000/1.836/9.846/2.292 Mbps but no firmware errors afaict. so dunno if the patch itself changes something, but the perf with the ISP AP is awful. Cant remember if it was the case before as i seldomly use it with OpenBSD as a client.. Landry
Re: 11n Tx aggregation for iwm(4)
On Fri, Jun 26, 2020 at 09:01:03PM -0700, Mike Larkin wrote: > On Fri, Jun 26, 2020 at 02:45:53PM +0200, Stefan Sperling wrote: > > This patch adds support for 11n Tx aggregation to iwm(4). > > > > Please help with testing if you can by running the patch and using wifi > > as usual. Nothing should change, except that Tx speed may potentially > > improve. If you have time to run before/after performance measurements with > > tcpbench or such, that would be nice. But it's not required for testing. > > > > If Tx aggregation is active then netstat will show a non-zero output block > > ack > > agreement counter: > > > > $ netstat -W iwm0 | grep 'output block' > > 3 new output block ack agreements > > 0 output block ack agreements timed out > > > > It would be great to get at least one test for all the chipsets the driver > > supports: 7260, 7265, 3160, 3165, 3168, 8260, 8265, 9260, 9560 > > The behaviour of the access point also matters a great deal. It won't > > hurt to test the same chipset against several different access points. > > > > I have tested this version on 8265 only so far. I've run older revisions > > of this patch on 7265 so I'm confident that this chip will work, too. > > So far, the APs I have tested against are athn(4) in 11a mode and in 11n > > mode with the 'nomimo' nwflag, and a Sagemcom 11ac AP. All on 5Ghz channels. > > I tested this on my T490 Thinkpad: > > iwm0 at pci0 dev 20 function 3 "Intel Dual Band Wireless AC 9560" rev 0x30, > msix > iwm0: hw rev 0x310, fw ver 34.3125811985.0 > > It ended up having a heck of a time connecting to anything, most/all > connections ended up timing out or just taking a really long time to complete. > > I looked in dmesg, and found a stream of fatal firmware errors and other > errors (see end of this email). > > My iwm-firmware was updated before I tried the new kernel: > > -innsmouth- ~> pkg_info iwm-firmware > Information for inst:iwm-firmware-20191022p1 > > Comment: > firmware binary images for iwm(4) driver > > Description: > Firmware binary images for use with the iwm(4) driver. > > Maintainer: The OpenBSD ports mailing-list > > WWW: https://wireless.wiki.kernel.org/en/users/Drivers/iwlwifi > PS, I did see 5 new output block ack agreements when I was running the diff, so apparently at least it is doing ... something? -ml > > > I still have the kernel around if you want me to test something else. There > is nothing in this tree except this Txagg diff. LMK if you need any more > info. > > OpenBSD 6.7-current (GENERIC.MP) #1: Fri Jun 26 14:01:06 PDT 2020 > > mlar...@innsmouth.int.azathoth.net:/u/bin/src/OpenBSD/openbsd/sys/arch/amd64/compile/GENERIC.MP > real mem = 51260506112 (48885MB) > avail mem = 49691906048 (47389MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.1 @ 0x604f5000 (67 entries) > bios0: vendor LENOVO version "N2IET61W (1.39 )" date 05/16/2019 > bios0: LENOVO 20N20046US > acpi0 at bios0: ACPI 6.1 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT UEFI SSDT HPET APIC MCFG ECDT > SSDT SSDT BOOT SLIC SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB DMAR NHLT ASF! > FPDT UEFI > acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) > RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) > RP06(S4) PXSX(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 2399 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz, 1586.72 MHz, 06-8e-0c > 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > 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 24MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz, 1333.05 MHz, 06-8e-0c > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,
Re: 11n Tx aggregation for iwm(4)
On Fri, Jun 26, 2020 at 02:45:53PM +0200, Stefan Sperling wrote: > This patch adds support for 11n Tx aggregation to iwm(4). > > Please help with testing if you can by running the patch and using wifi > as usual. Nothing should change, except that Tx speed may potentially > improve. If you have time to run before/after performance measurements with > tcpbench or such, that would be nice. But it's not required for testing. > > If Tx aggregation is active then netstat will show a non-zero output block ack > agreement counter: > > $ netstat -W iwm0 | grep 'output block' > 3 new output block ack agreements > 0 output block ack agreements timed out > > It would be great to get at least one test for all the chipsets the driver > supports: 7260, 7265, 3160, 3165, 3168, 8260, 8265, 9260, 9560 > The behaviour of the access point also matters a great deal. It won't > hurt to test the same chipset against several different access points. > > I have tested this version on 8265 only so far. I've run older revisions > of this patch on 7265 so I'm confident that this chip will work, too. > So far, the APs I have tested against are athn(4) in 11a mode and in 11n > mode with the 'nomimo' nwflag, and a Sagemcom 11ac AP. All on 5Ghz channels. I tested this on my T490 Thinkpad: iwm0 at pci0 dev 20 function 3 "Intel Dual Band Wireless AC 9560" rev 0x30, msix iwm0: hw rev 0x310, fw ver 34.3125811985.0 It ended up having a heck of a time connecting to anything, most/all connections ended up timing out or just taking a really long time to complete. I looked in dmesg, and found a stream of fatal firmware errors and other errors (see end of this email). My iwm-firmware was updated before I tried the new kernel: -innsmouth- ~> pkg_info iwm-firmware Information for inst:iwm-firmware-20191022p1 Comment: firmware binary images for iwm(4) driver Description: Firmware binary images for use with the iwm(4) driver. Maintainer: The OpenBSD ports mailing-list WWW: https://wireless.wiki.kernel.org/en/users/Drivers/iwlwifi I still have the kernel around if you want me to test something else. There is nothing in this tree except this Txagg diff. LMK if you need any more info. OpenBSD 6.7-current (GENERIC.MP) #1: Fri Jun 26 14:01:06 PDT 2020 mlar...@innsmouth.int.azathoth.net:/u/bin/src/OpenBSD/openbsd/sys/arch/amd64/compile/GENERIC.MP real mem = 51260506112 (48885MB) avail mem = 49691906048 (47389MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0x604f5000 (67 entries) bios0: vendor LENOVO version "N2IET61W (1.39 )" date 05/16/2019 bios0: LENOVO 20N20046US acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT UEFI SSDT HPET APIC MCFG ECDT SSDT SSDT BOOT SLIC SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB DMAR NHLT ASF! FPDT UEFI acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz, 1586.72 MHz, 06-8e-0c 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES 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 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz, 1333.05 MHz, 06-8e-0c 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz, 1125.81 MHz, 06-8e-0c cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C
Re: 11n Tx aggregation for iwm(4)
hello, On 2020-06-26 14:45, Stefan Sperling wrote: > It would be great to get at least one test for all the chipsets the driver > supports: 7260, 7265, 3160, 3165, 3168, 8260, 8265, 9260, 9560 > The behaviour of the access point also matters a great deal. It won't > hurt to test the same chipset against several different access points. tested on: iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi AP is a Ruckus 7363. $ netstat -W iwm0 | grep "output block" 6 new output block ack agreements 0 output block ack agreements timed out Before: bandwidth min/avg/max/std-dev = 16.780/18.325/19.939/1.235 Mbps After: bandwidth min/avg/max/std-dev = 0.000/15.559/51.631/19.548 Mbps .jh
Re: 11n Tx aggregation for iwm(4)
This is from an 8265: iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x88, msi iwm0: hw rev 0x230, fw ver 34.0.1, Associated to an Apple AirPort AP on a 5 GHz channel. Before: bandwidth min/avg/max/std-dev = 11.402/17.410/36.190/4.079 Mbps After: bandwidth min/avg/max/std-dev = 5.147/25.039/54.066/8.489 Mbps $ netstat -W iwm0 | grep "output block" 1 new output block ack agreement 0 output block ack agreements timed out
Re: 11n Tx aggregation for iwm(4)
On Fri, Jun 26, 2020 at 02:45:53PM +0200, Stefan Sperling wrote: > This patch adds support for 11n Tx aggregation to iwm(4). > > Please help with testing if you can by running the patch and using wifi > as usual. Nothing should change, except that Tx speed may potentially > improve. If you have time to run before/after performance measurements with > tcpbench or such, that would be nice. But it's not required for testing. > > If Tx aggregation is active then netstat will show a non-zero output block ack > agreement counter: > > $ netstat -W iwm0 | grep 'output block' > 3 new output block ack agreements > 0 output block ack agreements timed out > > It would be great to get at least one test for all the chipsets the driver > supports: 7260, 7265, 3160, 3165, 3168, 8260, 8265, 9260, 9560 > The behaviour of the access point also matters a great deal. It won't > hurt to test the same chipset against several different access points. > > I have tested this version on 8265 only so far. I've run older revisions > of this patch on 7265 so I'm confident that this chip will work, too. > So far, the APs I have tested against are athn(4) in 11a mode and in 11n > mode with the 'nomimo' nwflag, and a Sagemcom 11ac AP. All on 5Ghz channels. no difference on X1c3 w/ iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, msi iwm0: hw rev 0x210, fw ver 17.3216344376.0, using a crappy old fonera as AP, serving as a bridge to gw w/ tcpbench. bandwidth min/avg/max/std-dev = 22.519/22.704/22.995/0.162 Mbps same bw both ways it seems. Landry
Re: 11n Tx aggregation for iwm(4)
Seems to be working on a X1 gen2 using iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0x83, msi against a Unifi AP-SHD. Before: bandwidth min/avg/max/std-dev = 7.344/9.077/11.514/0.803 Mbps after: bandwidth min/avg/max/std-dev = 12.551/65.407/82.835/14.169 Mbps -- I'm not entirely sure you are real.
11n Tx aggregation for iwm(4)
This patch adds support for 11n Tx aggregation to iwm(4). Please help with testing if you can by running the patch and using wifi as usual. Nothing should change, except that Tx speed may potentially improve. If you have time to run before/after performance measurements with tcpbench or such, that would be nice. But it's not required for testing. If Tx aggregation is active then netstat will show a non-zero output block ack agreement counter: $ netstat -W iwm0 | grep 'output block' 3 new output block ack agreements 0 output block ack agreements timed out It would be great to get at least one test for all the chipsets the driver supports: 7260, 7265, 3160, 3165, 3168, 8260, 8265, 9260, 9560 The behaviour of the access point also matters a great deal. It won't hurt to test the same chipset against several different access points. I have tested this version on 8265 only so far. I've run older revisions of this patch on 7265 so I'm confident that this chip will work, too. So far, the APs I have tested against are athn(4) in 11a mode and in 11n mode with the 'nomimo' nwflag, and a Sagemcom 11ac AP. All on 5Ghz channels. diff refs/heads/master refs/heads/txagg blob - 3a75d07a60a7eb4c66540474e47aeffd7a85250a blob + 853bdd1290ad509f5fce7b5bf20550f458a2b460 --- sys/dev/pci/if_iwm.c +++ sys/dev/pci/if_iwm.c @@ -144,6 +144,8 @@ #include #include #include +#include /* for SEQ_LT */ +#undef DPRINTF /* defined in ieee80211_priv.h */ #define DEVNAME(_s)((_s)->sc_dev.dv_xname) @@ -299,7 +301,8 @@ int iwm_nic_rx_mq_init(struct iwm_softc *); intiwm_nic_tx_init(struct iwm_softc *); intiwm_nic_init(struct iwm_softc *); intiwm_enable_ac_txq(struct iwm_softc *, int, int); -intiwm_enable_txq(struct iwm_softc *, int, int, int); +intiwm_enable_txq(struct iwm_softc *, int, int, int, int, uint8_t, + uint16_t); intiwm_post_alive(struct iwm_softc *); struct iwm_phy_db_entry *iwm_phy_db_get_section(struct iwm_softc *, uint16_t, uint16_t); @@ -334,12 +337,12 @@ void iwm_ampdu_rx_stop(struct ieee80211com *, struct i uint8_t); void iwm_sta_rx_agg(struct iwm_softc *, struct ieee80211_node *, uint8_t, uint16_t, uint16_t, int); -#ifdef notyet +void iwm_sta_tx_agg(struct iwm_softc *, struct ieee80211_node *, uint8_t, + uint16_t, uint16_t, int); intiwm_ampdu_tx_start(struct ieee80211com *, struct ieee80211_node *, uint8_t); void iwm_ampdu_tx_stop(struct ieee80211com *, struct ieee80211_node *, uint8_t); -#endif void iwm_ba_task(void *); intiwm_parse_nvm_data(struct iwm_softc *, const uint16_t *, @@ -372,14 +375,25 @@ int iwm_rxmq_get_signal_strength(struct iwm_softc *, s void iwm_rx_rx_phy_cmd(struct iwm_softc *, struct iwm_rx_packet *, struct iwm_rx_data *); intiwm_get_noise(const struct iwm_statistics_rx_non_phy *); +void iwm_txq_advance(struct iwm_softc *, struct iwm_tx_ring *, int); +void iwm_ampdu_tx_done(struct iwm_softc *, struct iwm_cmd_header *, + struct iwm_node *, struct iwm_tx_ring *, uint32_t, uint8_t, + uint8_t, uint16_t, int, struct iwm_agg_tx_status *); intiwm_ccmp_decap(struct iwm_softc *, struct mbuf *, struct ieee80211_node *); void iwm_rx_frame(struct iwm_softc *, struct mbuf *, int, uint32_t, int, int, uint32_t, struct ieee80211_rxinfo *, struct mbuf_list *); -void iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_rx_packet *, - struct iwm_node *, int, int); +void iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_tx_resp *, + struct iwm_node *, int, int, int); +void iwm_txd_done(struct iwm_softc *, struct iwm_tx_data *); void iwm_rx_tx_cmd(struct iwm_softc *, struct iwm_rx_packet *, struct iwm_rx_data *); +void iwm_clear_oactive(struct iwm_softc *, struct iwm_tx_ring *); +void iwm_mira_choose(struct iwm_softc *, struct ieee80211_node *); +void iwm_ampdu_rate_control(struct iwm_softc *, struct ieee80211_node *, + struct iwm_tx_ring *, int, uint16_t, uint16_t); +void iwm_rx_ba(struct iwm_softc *, struct iwm_rx_packet *, + struct iwm_rx_data *); void iwm_rx_bmiss(struct iwm_softc *, struct iwm_rx_packet *, struct iwm_rx_data *); intiwm_binding_cmd(struct iwm_softc *, struct iwm_node *, uint32_t); @@ -399,6 +413,7 @@ int iwm_send_cmd_pdu_status(struct iwm_softc *, uint32 void iwm_free_resp(struct iwm_softc *, struct iwm_host_cmd *); void iwm_cmd_done(struct iwm_softc *, int, int, int); void iwm_update_sched(struct iwm_softc *, int, int, uint8_t, uint16_t); +void iwm_reset_sched(struct iwm_softc *, int, int, uint8_t); const struct iwm_rate *iwm_tx_fill_cmd(struct iwm_softc *, struct iwm_node *, struct ieee80211_frame *, struct iwm_tx_cmd *); intiwm_tx(struct iwm_softc *, struct mbuf *, struct ieee80211_node *, int); @@ -1306,17 +1321
