Re: 11n Tx aggregation for iwm(4)

2020-06-29 Thread Sebastian Benoit
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)

2020-06-29 Thread Sebastian Benoit
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)

2020-06-29 Thread Uwe Werler
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 *, 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 

Re: 11n Tx aggregation for iwm(4)

2020-06-29 Thread Uwe Werler
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_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 *,
>   

Re: 11n Tx aggregation for iwm(4)

2020-06-27 Thread Jesper Wallin
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)

2020-06-27 Thread Denis Fondras
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)

2020-06-27 Thread Tracey Emery
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)

2020-06-27 Thread Johan Huldtgren
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)

2020-06-27 Thread Tobias Heider
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)

2020-06-27 Thread Landry Breuil
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)

2020-06-26 Thread Mike Larkin
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: 
> 

Re: 11n Tx aggregation for iwm(4)

2020-06-26 Thread Mike Larkin
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: 

Re: 11n Tx aggregation for iwm(4)

2020-06-26 Thread Johan Huldtgren
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)

2020-06-26 Thread Todd Carson


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)

2020-06-26 Thread Landry Breuil
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)

2020-06-26 Thread Florian Obser
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.