Re: iwm performance (was: Re: how would you troubleshoot your wifi?)

[David Dahlberg]

Am Freitag, den 22.07.2016, 11:36 +0200 schrieb Stefan Sperling:

> I've already been told about iwm performance regressions compared to
> 5.9,
> so I'd like to make a statement (not just directed at you, Andreas,
> but
> at everyone).

JFYI: A temporary workaround which works for me (on a X1C3) is disabling
802.11n with "ifconfig mode".

iwm performance (was: Re: how would you troubleshoot your wifi?)

[Stefan Sperling]

On Thu, Jul 21, 2016 at 08:25:11PM +0200, Andreas Bartelt wrote:
> sorry, my response was not precise - the "fatal" error is gone now but the
> observed performance problems are still there.

I've already been told about iwm performance regressions compared to 5.9,
so I'd like to make a statement (not just directed at you, Andreas, but
at everyone).

Recently, I've been focusing on improving wireless stability after many
reports of lag, dropped links, and similar problems ever since 11n support
was introduced. This effort is still on-going, since I am still unable to
reproduce some of the reported issues. If such fixes end up decreasing
performance in some use cases then I'm entirely fine with that.

One possibility is that perceived performance drops are a side effect of
frame protection we've enabled. This may show up as a performance drop for
users which are alone with their AP and never see interference (so frame
protection doesn't buy them anything, it just adds overhead).
Many users are not alone with their AP but share a channel with a dozen
other APs or so and frame protection _really_ helps them. In the most
extreme cases (which I've reproduced with help from phessler@) these
users cannot use wifi at all without frame protection (TCP stalls).
To get an idea about the overhead added by RTS/CTS, see
http://www.testequipmentdepot.com/flukenetworks/pdf/802.11n-compatibility.pdf
(When reading this, keep in mind we send at MCS 7 max, without aggregation.)

In the best iwm performance regression report I've received so far, the
reporter tracked the regression down to a particular commit (r1.86 if_iwm.c).
Backing out that commit restores performance to 5.9 levels for this user.
But this commit fixed an unrelated problem, which was that IPv6 autoconf and
ARP briefly stopped working in -current after we upgraded iwm's firmware.
I don't understand how this relates. It may involve invisible details handled
within the magic firmware, or it may be a driver bug, or prior performance
levels may have been a side effect of a real stability problem. In any case,
I won't back out this commit to restore performance for one user if backing
out that commit means that other known bugs will come back.

More generally speaking, given that our 11n implementation is still in its
infancy, and doesn't yet use any of the new features which are supposed to
vastly increase throughput, it is premature to complain about performance.
For now, stability gets priority.

Re: how would you troubleshoot your wifi?

[Miles Keaton]

Worked! Thanks Stefan!

On Thu, Jul 21, 2016 at 8:34 PM, Stefan Sperling  wrote:

>
> On Thu, Jul 14, 2016 at 01:13:21PM +0800, Miles Keaton wrote:
> > iwm0: hw rev 0x140, fw ver 25.228 (API ver 9), address 5b:51:4f:a1:16:d9
> > iwm0: fatal firmware error
>
> You got some answers already but they were all misleading.
> I believe I've already fixed this bug. Please verify my assumption by
> upgrading to -current now and letting me know if the problem persists.
> (Run fw_update iwm before upgrading or iwm won't work during the upgrade!)

Re: how would you troubleshoot your wifi?

[Andreas Bartelt]

sorry, my response was not precise - the "fatal" error is gone now but 
the observed performance problems are still there.

Re: how would you troubleshoot your wifi?

[Andreas Bartelt]

On 07/21/16 10:34, Stefan Sperling wrote:
> On Thu, Jul 14, 2016 at 01:13:21PM +0800, Miles Keaton wrote:
>> iwm0: hw rev 0x140, fw ver 25.228 (API ver 9), address 5b:51:4f:a1:16:d9
>> iwm0: fatal firmware error
>
> You got some answers already but they were all misleading.
> I believe I've already fixed this bug. Please verify my assumption by
> upgrading to -current now and letting me know if the problem persists.
> (Run fw_update iwm before upgrading or iwm won't work during the upgrade!)
>
>

I'm also observing this error and I'm experiencing massive problems with 
regard to wireless performance on current (compared to 5.9 at some 
point) - unfortunately, I've been observing these for some time now. My 
guess would be that its related to iwm(4) but it could potentially also 
be related to the ral(4) side which runs in 802.11g hostap mode on 
current. I didn't have any time in order to look into this deeper yet -- 
I also made some changes with regard to the position of my access point 
but this (at least now) seems to be completely unrelated to the observed 
problems.

Sorry for being of no help atm with regard to reporting observed 
problems with current in a timely manner.

Best regards
Andreas
OpenBSD 6.0 (GENERIC.MP) #0: Thu Jul 21 04:55:30 CEST 2016
a...@obsd.bartelt.name:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8277159936 (7893MB)
avail mem = 8021778432 (7650MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (64 entries)
bios0: vendor LENOVO version "N10ET38W (1.17 )" date 08/20/2015
bios0: LENOVO 20CMCTO1WW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT SSDT PCCT SSDT UEFI MSDM BATB FPDT UEFI DMAR
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.28 MHz
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
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.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.15 MHz
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.15 MHz
cpu2: 
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.15 MHz
cpu3: 
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpicpu0 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 

Re: how would you troubleshoot your wifi?

[Stefan Sperling]

On Thu, Jul 14, 2016 at 01:13:21PM +0800, Miles Keaton wrote:
> iwm0: hw rev 0x140, fw ver 25.228 (API ver 9), address 5b:51:4f:a1:16:d9
> iwm0: fatal firmware error

You got some answers already but they were all misleading.
I believe I've already fixed this bug. Please verify my assumption by
upgrading to -current now and letting me know if the problem persists.
(Run fw_update iwm before upgrading or iwm won't work during the upgrade!)

Re: how would you troubleshoot your wifi?

[uma]

El 2016-07-14 00:13, Miles Keaton escribió:

I'm an intermediate OpenBSD user since 2001, but never needed my wifi
before.

When I connect to an open (no password) nwid it works fine, but when 
I try
to connect to one with a WPA2 password, it just fails with no clues I 
can

see.  I'm using the correct password - (works fine on my phone, etc).

Any tips on how else you would troubleshoot this?  Thiis is all I've 
got:


# ifconfig iwm0 scan
nwid SINGTEL-1D14 chan 2 bssid 00:25:75:af:1d:15 97% 54M
privacy,short_slottime,wpa2

# cat /etc/hostname.iwm0
nwid SINGTEL-1D14
wpakey "00114764294"   # (NOTE: tried it with & without quotes. no 
help)

dhcp

# dmesg | grep iwm0
iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 
0x83,

msi
iwm0: hw rev 0x140, fw ver 25.228 (API ver 9), address 
5b:51:4f:a1:16:d9

iwm0: fatal firmware error

I'd believe the "fatal firmware error" except, like I said above, 
this same

iwm0 wifi connected fine yesterday to an open (no password) nwid.

Thank you.


Hi,

I think you miss a word, "wpa", just before the key declaration:

wpa wpakey 00114764294

Did you update your firmware?, i.e.

# fw_update
--
Ulises M. Alvarez
http://sophie.unam.mx/

Re: how would you troubleshoot your wifi?

[Peter N. M. Hansteen]

On Thu, Jul 14, 2016 at 01:13:21PM +0800, Miles Keaton wrote:
> Any tips on how else you would troubleshoot this?  Thiis is all I've got:
> 
> # ifconfig iwm0 scan
> nwid SINGTEL-1D14 chan 2 bssid 00:25:75:af:1d:15 97% 54M
> privacy,short_slottime,wpa2
> 
> # cat /etc/hostname.iwm0
> nwid SINGTEL-1D14
> wpakey "00114764294"   # (NOTE: tried it with & without quotes. no help)
> dhcp
> 
> # dmesg | grep iwm0
> iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0x83,
> msi
> iwm0: hw rev 0x140, fw ver 25.228 (API ver 9), address 5b:51:4f:a1:16:d9
> iwm0: fatal firmware error
> 
> I'd believe the "fatal firmware error" except, like I said above, this same
> iwm0 wifi connected fine yesterday to an open (no password) nwid.

ifconfig iwm0 debug (or debug in your hostname.iwm0 file for a more permanent 
presence)
should produce more verbose reporting, at least. And of course, a full dmesg
along with ifconfig -a output would likely be useful.

Running tcpdump to capture whatever passes through the interface while you're
trying to connect is another main source of information about what fail and how,
of course. 

Some access points are just plain weird - in some cases I've had to play with 
of all things mtu sizes (setting them to various values lower than the 1500 
byte default) in order to successfully connect. Any quirks like those will
turn up as the hints tcpdump will show you.

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: how would you troubleshoot your wifi?

[Mihai Popescu]

Do not trim your dmesg or config file to whatever you think is
necessary to show.
The OpenBSD version is a critical information for any serious
troubleshooting operation.