Re: iwm performance
On Sun, Jul 24, 2016 at 05:54:21PM +0200, Andreas Bartelt wrote: > On 07/24/16 15:28, Stefan Sperling wrote: > >On Sun, Jul 24, 2016 at 01:09:26PM +0200, Andreas Bartelt wrote: > >>However, the wireless link via iwm(4) is currently almost unusable. > >>Overall throughput for multiple tcp connections typically between 0 and > >>1 Mbit/s but mostly on the lower end, i.e., 0. > > > >Looking at the wifi environment you're testing this in is very important. > > > >Does this happen consistently, and everywhere? > >Or only at your home, with something like 20 other wifi networks on > >the same channel? > > > > I've attached some scans regarding WiFi networks at my vicinity. I also did > some measurements for iwn(4) regarding throughput at different locations. > Performance was particularly bad after suspend/resume -- do you think this > might be related? Assuming there is a suspend/resume bug where the HW doesn't get initialized properly after resume, then yes, that could explain the problem. I haven't noticed such a problem myself yet, nor gotten any such reports. Can you gather more evidence somehow? > nwid mywlan chan 8 bssid 74:de:2b:3b:02:65 79% 54M > privacy,short_preamble,short_slottime,wpa2 > nwid aa chan 11 bssid 08:95:2a:87:f0:75 25% HT-MCS15 > privacy,short_slottime,radio_measurement,wpa2 > nwid bb chan 11 bssid 0a:95:2a:87:f0:77 22% HT-MCS15 > privacy,short_slottime,radio_measurement,wpa2,802.1x > nwid cc chan 11 bssid 8c:04:ff:b9:29:02 22% HT-MCS15 > privacy,short_slottime,radio_measurement,wpa2 > nwid dd chan 11 bssid 00:03:c9:8b:ee:10 17% 54M > privacy,short_slottime,wep Channels 8 and 11 do have some overlap, see https://en.wikipedia.org/wiki/File:2.4_GHz_Wi-Fi_channels_%28802.11b,g_WLAN%29.svg But not enough to qualify as a primary reason for your problem, I guess. You might also have to take actual load of on these other networks into account. An iwn(4) device in monitor mode in combination with tcpdump will show you what's going on in the air (including control frames like RTS/CTS frames): ifconfig iwn0 down ifconfig iwn0 -nwid -bssid -wpakey -nwkey -chan ifconfig iwn0 mediaopt monitor ifconfig iwn0 chan 8 ifconfig iwn0 up tcpdump -n -i iwn0 -y IEEE802_11_RADIO Earlier in this thread, you mentioned that your AP is running OpenBSD with the ral(4) driver. The RTS threshold fix I committed last week will likely affect its behaviour. Did you upgrade your AP to -current? I'd be very interested to know how this AP behaves after an upgrade.
Re: iwm performance
On 07/24/16 15:28, Stefan Sperling wrote: > On Sun, Jul 24, 2016 at 01:09:26PM +0200, Andreas Bartelt wrote: >> However, the wireless link via iwm(4) is currently almost unusable. >> Overall throughput for multiple tcp connections typically between 0 and >> 1 Mbit/s but mostly on the lower end, i.e., 0. > > Looking at the wifi environment you're testing this in is very important. > > Does this happen consistently, and everywhere? > Or only at your home, with something like 20 other wifi networks on > the same channel? > I've attached some scans regarding WiFi networks at my vicinity. I also did some measurements for iwn(4) regarding throughput at different locations. Performance was particularly bad after suspend/resume -- do you think this might be related? Best regards Andreas WiFi networks from scans very near at my access point (nwid's sanitized) [iwm(4) with observed througput between 1-11 Mbit/s; after suspend/resume, performance was only between 1-5 Mbits/s]: nwid mywlan chan 8 bssid 74:de:2b:3b:02:65 79% 54M privacy,short_preamble,short_slottime,wpa2 nwid aa chan 11 bssid 08:95:2a:87:f0:75 25% HT-MCS15 privacy,short_slottime,radio_measurement,wpa2 nwid bb chan 11 bssid 0a:95:2a:87:f0:77 22% HT-MCS15 privacy,short_slottime,radio_measurement,wpa2,802.1x nwid cc chan 11 bssid 8c:04:ff:b9:29:02 22% HT-MCS15 privacy,short_slottime,radio_measurement,wpa2 nwid dd chan 11 bssid 00:03:c9:8b:ee:10 17% 54M privacy,short_slottime,wep nwid ee chan 2 bssid 00:12:bf:6d:51:3c 16% 54M privacy,short_preamble,short_slottime,wpa2 nwid ff chan 4 bssid 90:f6:52:2b:4a:54 14% HT-MCS15 privacy,short_preamble,short_slottime,wpa2 nwid gg chan 11 bssid f4:06:8d:84:8a:31 13% HT-MCS7 privacy,short_slottime,wpa2 nwid hh chan 1 bssid 88:03:55:be:42:2e 11% HT-MCS32 privacy,short_preamble,short_slottime,wpa2 nwid ii chan 1 bssid 2c:59:e5:ef:f3:fa 11% 54M privacy,short_preamble,short_slottime,wpa2 nwid jj chan 2 bssid 18:83:bf:7d:61:4b 10% HT-MCS32 privacy,short_slottime,wpa2 nwid kk chan 11 bssid 24:65:11:2b:35:e6 10% HT-MCS15 privacy,short_preamble,short_slottime,wpa2 nwid oo chan 1 bssid 84:9c:a6:3a:e2:46 10% HT-MCS15 privacy,short_slottime,wpa2 nwid ll chan 1 bssid 24:65:11:04:68:62 7% HT-MCS15 privacy,short_preamble,short_slottime,wpa2 nwid mm chan 6 bssid 7c:4f:b5:97:0f:22 5% HT-MCS32 privacy,short_slottime,wpa2 nwid nn chan 6 bssid 54:67:51:03:45:df 5% HT-MCS15 privacy,short_slottime,wpa2 >From the room where I typically observe the reported througput problems: [best case I've observed relatively stable througput around 9 Mbits; after suspend/resume, performance was only between 0-1 Mbits/s] nwid mywlan chan 8 bssid 74:de:2b:3b:02:65 46% 54M privacy,short_preamble,short_slottime,wpa2 nwid aa chan 11 bssid 08:95:2a:87:f0:75 41% HT-MCS15 privacy,short_slottime,radio_measurement,wpa2 nwid bb chan 11 bssid 0a:95:2a:87:f0:77 38% HT-MCS15 privacy,short_slottime,radio_measurement,wpa2,802.1x nwid ee chan 2 bssid 00:12:bf:6d:51:3c 23% 54M privacy,short_preamble,short_slottime,wpa2
Re: iwm performance
On Sun, Jul 24, 2016 at 01:09:26PM +0200, Andreas Bartelt wrote: > However, the wireless link via iwm(4) is currently almost unusable. > Overall throughput for multiple tcp connections typically between 0 and > 1 Mbit/s but mostly on the lower end, i.e., 0. Looking at the wifi environment you're testing this in is very important. Does this happen consistently, and everywhere? Or only at your home, with something like 20 other wifi networks on the same channel?
Re: iwm performance
On 07/22/16 11:36, Stefan Sperling wrote: > 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. > ... > 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. > Please don't get me wrong, my mail was not meant to be a complaint at all. While tracking current (I think it was shortly before or after 5.9 had been released) I've been observing some serious stability problems with regard to wireless for some time -- not only regarding iwm(4) on a Lenovo x250 as wireless client but also on the hostap side (ral(4) obviously in 11g mode and also running on current). The hostap box crashed multiple times a day and had to be rebooted. These problems are gone now, i.e., both sides don't crash anymore. However, the wireless link via iwm(4) is currently almost unusable. Overall throughput for multiple tcp connections typically between 0 and 1 Mbit/s but mostly on the lower end, i.e., 0. The "fatal firmware error" problem doesn't seem to be resolved - it just doesn't occur at every boot (see attached dmesg from yesterday's current). The bad throughput seems to be independent from this error message. I could verify that an old x61s with wpi(4) currently performs considerably better (throughput in the same setting is more stable at about 175 Kbits/s). Consequently, the ral(4) interface in 11g hostap mode at least doesn't seem to be the primary problem. Nevertheless, I've also observed that the presence of the x250 laptop sometimes also kills throughput of other wireless clients (iphone, ipad etc) - so I'm not 100% sure, i.e., the problems could at least be partially related to ral(4) in 11g hostap mode. Btw, can you recommend a (commercial or open source) wireless access point which is known to work well with iwm(4) in 11n mode on current? Best regards Andreas OpenBSD 6.0 (GENERIC.MP) #0: Sat Jul 23 09:03:23 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:
Re: iwm performance (was: Re: how would you troubleshoot your wifi?)
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".
