Since I upgraded to Fedora 25, I've had terrible network performance, and I'm not sure what's causing it.
Any suggestions for troubleshooting or optimization?
Any known issues with the "Intel Wireless 7265D" card or the "iwlwifi" driver in F25?
Everything worked great in F24, but since F25, I get poor download speeds, and *REALLY* poor upload speeds. I should get a steady 25/25 Mbps down/up. Instead, I get an unsteady 6-20 Mbps down, and only ~1 Mbps up. I've ruled out everything but Fedora 25 (same hardware works fine in F24 and Windows), and it's making me kinda want to go back to F24. :(
Did you checked the lsmod witch driver is gonna loaded under f24, and witch one is under 25?
Z
2017-01-05 6:58 GMT+01:00 Christopher ctubbsii@fedoraproject.org:
Since I upgraded to Fedora 25, I've had terrible network performance, and I'm not sure what's causing it.
Any suggestions for troubleshooting or optimization?
Any known issues with the "Intel Wireless 7265D" card or the "iwlwifi" driver in F25?
Everything worked great in F24, but since F25, I get poor download speeds, and *REALLY* poor upload speeds. I should get a steady 25/25 Mbps down/up. Instead, I get an unsteady 6-20 Mbps down, and only ~1 Mbps up. I've ruled out everything but Fedora 25 (same hardware works fine in F24 and Windows), and it's making me kinda want to go back to F24. :(
-- Christopher
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 01/04/2017 09:58 PM, Christopher wrote:
since F25, I get poor download speeds, and *REALLY* poor upload speeds
It might not be too helpful, but I think I'm seeing the same thing. I haven't looked at it previously, but a very cursory look shows that when uploading the "Invalid misc:" counter increases pretty steadily, at a rate of 20-30/second.
On Thu, Jan 5, 2017 at 10:53 AM Gordon Messmer gordon.messmer@gmail.com wrote:
On 01/04/2017 09:58 PM, Christopher wrote:
since F25, I get poor download speeds, and *REALLY* poor upload speeds
It might not be too helpful, but I think I'm seeing the same thing. I haven't looked at it previously, but a very cursory look shows that when uploading the "Invalid misc:" counter increases pretty steadily, at a rate of 20-30/second.
I'm going to try playing with the module's parameters. A lot of forums seem to indicate that messing with 11n_disable in particular can help.
On Fri, Jan 6, 2017 at 5:29 PM Christopher ctubbsii@fedoraproject.org wrote:
On Thu, Jan 5, 2017 at 10:53 AM Gordon Messmer gordon.messmer@gmail.com wrote:
On 01/04/2017 09:58 PM, Christopher wrote:
since F25, I get poor download speeds, and *REALLY* poor upload speeds
It might not be too helpful, but I think I'm seeing the same thing. I haven't looked at it previously, but a very cursory look shows that when uploading the "Invalid misc:" counter increases pretty steadily, at a rate of 20-30/second.
I'm going to try playing with the module's parameters. A lot of forums seem to indicate that messing with 11n_disable in particular can help.
I wasn't able to find any module parameters that showed any improvement. I also tried forcing the driver to use older firmware, with no effect.
I did see "Invalid misc" counter going up also.
I spent a little while looking at this today, and I'm not able to reproduce the problem. I've definitely had trouble with uploads in the recent past, but I've compared the firmware versions between F24 and F25 and found no difference. I've uploaded files using the F24 kernel and F25 kernel and see no difference. It's possible that the trouble I've seen was environmental. I'll have to wait for it to recur and do more testing then.
I've only had Fedora 25 and Windows 10 on this new HP laptop, so I can't compare to Fedora 24 to see if there's a regression. But I get ~9MB/s transfers with Windows 10, and ~3.2MB/s transfers on Fedora 25. That's a big difference.
The test is done with the laptop in the same location relative to the AP which is an ISP provided box, and the server is an Intel NUC running F25 server with wired ethernet to the ISP provided box; and F25 server is running Samba to host the files I'm copying over.
Ostensibly this is an 802.11n connection, so 9MB/s is consistent with that, where 3MB/s is consistent with half that of 802.11g.
I've used kernel 4.8.15, 4.8.17, 4.9.0, and 4.10-rc3 to test this with all the same results. So it could be firmware related, reported firmware is [ 4.009396] iwlwifi 0000:6c:00.0: loaded firmware version 22.361476.0 op_mode iwlmvm
Chris Murphy
On Tue, Jan 10, 2017 at 12:22 PM, Joe Zeff joe@zeff.us wrote:
On 01/10/2017 11:19 AM, Chris Murphy wrote:
Ostensibly this is an 802.11n connection, so 9MB/s is consistent with that, where 3MB/s is consistent with half that of 802.11g.
No, it's one third of what Windows is getting.
It's both. 802.11g is 54Mbps, I'm getting 24-26Mbps. So it sounds like to me the kernel or firmware being used when using Fedora, is doing some kind of aggressive fallback and thus a much lower rate.
The distance laptop to AP is about 8 feet, and unimpeded line of site.
On 01/10/2017 11:30 AM, Chris Murphy wrote:
On Tue, Jan 10, 2017 at 12:22 PM, Joe Zeff joe@zeff.us wrote:
On 01/10/2017 11:19 AM, Chris Murphy wrote:
Ostensibly this is an 802.11n connection, so 9MB/s is consistent with that, where 3MB/s is consistent with half that of 802.11g.
No, it's one third of what Windows is getting.
It's both. 802.11g is 54Mbps, I'm getting 24-26Mbps. So it sounds like to me the kernel or firmware being used when using Fedora, is doing some kind of aggressive fallback and thus a much lower rate.
The distance laptop to AP is about 8 feet, and unimpeded line of site.
I believe you said the F25 server is running Samba to supply the files. Are you certain it isn't the F25 Samba client that's causing this? Try having the F25 server share the same directory via NFS and use the F25 NFS client for testing. See if that improves things.
I'm only suggesting that since you're using the same firmware across multiple kernels (and on F24). ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - You possess a mind not merely twisted, but actually sprained. - ----------------------------------------------------------------------
On 01/10/2017 11:44 AM, Rick Stevens wrote:
On 01/10/2017 11:30 AM, Chris Murphy wrote:
On Tue, Jan 10, 2017 at 12:22 PM, Joe Zeff joe@zeff.us wrote:
On 01/10/2017 11:19 AM, Chris Murphy wrote:
Ostensibly this is an 802.11n connection, so 9MB/s is consistent with that, where 3MB/s is consistent with half that of 802.11g.
No, it's one third of what Windows is getting.
It's both. 802.11g is 54Mbps, I'm getting 24-26Mbps. So it sounds like to me the kernel or firmware being used when using Fedora, is doing some kind of aggressive fallback and thus a much lower rate.
The distance laptop to AP is about 8 feet, and unimpeded line of site.
I believe you said the F25 server is running Samba to supply the files. Are you certain it isn't the F25 Samba client that's causing this? Try having the F25 server share the same directory via NFS and use the F25 NFS client for testing. See if that improves things.
I'm only suggesting that since you're using the same firmware across multiple kernels (and on F24).
Oh, and you could try "iperf" on both ends to test raw network performance without an intervening file transfer protocol. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Is it progress if a cannibal uses a knife and fork? - - -- Stanislaw J. Lec - ----------------------------------------------------------------------
On Tue, Jan 10, 2017 at 12:44 PM, Rick Stevens ricks@alldigital.com wrote:
On 01/10/2017 11:30 AM, Chris Murphy wrote:
On Tue, Jan 10, 2017 at 12:22 PM, Joe Zeff joe@zeff.us wrote:
On 01/10/2017 11:19 AM, Chris Murphy wrote:
Ostensibly this is an 802.11n connection, so 9MB/s is consistent with that, where 3MB/s is consistent with half that of 802.11g.
No, it's one third of what Windows is getting.
It's both. 802.11g is 54Mbps, I'm getting 24-26Mbps. So it sounds like to me the kernel or firmware being used when using Fedora, is doing some kind of aggressive fallback and thus a much lower rate.
The distance laptop to AP is about 8 feet, and unimpeded line of site.
I believe you said the F25 server is running Samba to supply the files. Are you certain it isn't the F25 Samba client that's causing this?
No.
Try having the F25 server share the same directory via NFS and use the F25 NFS client for testing. See if that improves things.
How about ssh? When I use ssh on Fedora 25 to drag down a file I'm getting slightly different results, 4.4MB/s. So it's faster than the GNOME samba client, whatever that's using, but it's still slower by 2x than the Windows 10 samba client.
On 01/10/2017 01:56 PM, Chris Murphy wrote:
On Tue, Jan 10, 2017 at 12:44 PM, Rick Stevens ricks@alldigital.com wrote:
On 01/10/2017 11:30 AM, Chris Murphy wrote:
On Tue, Jan 10, 2017 at 12:22 PM, Joe Zeff joe@zeff.us wrote:
On 01/10/2017 11:19 AM, Chris Murphy wrote:
Ostensibly this is an 802.11n connection, so 9MB/s is consistent with that, where 3MB/s is consistent with half that of 802.11g.
No, it's one third of what Windows is getting.
It's both. 802.11g is 54Mbps, I'm getting 24-26Mbps. So it sounds like to me the kernel or firmware being used when using Fedora, is doing some kind of aggressive fallback and thus a much lower rate.
The distance laptop to AP is about 8 feet, and unimpeded line of site.
I believe you said the F25 server is running Samba to supply the files. Are you certain it isn't the F25 Samba client that's causing this?
No.
Try having the F25 server share the same directory via NFS and use the F25 NFS client for testing. See if that improves things.
How about ssh? When I use ssh on Fedora 25 to drag down a file I'm getting slightly different results, 4.4MB/s. So it's faster than the GNOME samba client, whatever that's using, but it's still slower by 2x than the Windows 10 samba client.
Have you tried the iperf suggestion? First on the server, open up TCP port 5001 on the firewall (just is just temporarily--iperf defaults to port 5001), then run "iperf -s" on the server.
On the client, run "iperf -c ip-address-of-server" and wait, oh, 15 seconds or so. Both the client and server should show some results. This is from my laptop as the client over a 100Mbps wired link to my server (yes, it's an old laptop with a built-in 100Mbps NIC):
[root@golem4 ~]# iperf -c 192.168.1.50 ------------------------------------------------------------ Client connecting to 192.168.1.50, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.52 port 38964 connected with 192.168.1.50 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 112 MBytes 94.2 Mbits/sec
So, over my 100Mbps wired link, I got 94.2Mbps. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Where there's a will, I want to be in it. - ----------------------------------------------------------------------
On 01/10/2017 03:40 PM, Rick Stevens wrote:
On 01/10/2017 01:56 PM, Chris Murphy wrote:
On Tue, Jan 10, 2017 at 12:44 PM, Rick Stevens ricks@alldigital.com wrote:
On 01/10/2017 11:30 AM, Chris Murphy wrote:
On Tue, Jan 10, 2017 at 12:22 PM, Joe Zeff joe@zeff.us wrote:
On 01/10/2017 11:19 AM, Chris Murphy wrote:
Ostensibly this is an 802.11n connection, so 9MB/s is consistent with that, where 3MB/s is consistent with half that of 802.11g.
No, it's one third of what Windows is getting.
It's both. 802.11g is 54Mbps, I'm getting 24-26Mbps. So it sounds like to me the kernel or firmware being used when using Fedora, is doing some kind of aggressive fallback and thus a much lower rate.
The distance laptop to AP is about 8 feet, and unimpeded line of site.
I believe you said the F25 server is running Samba to supply the files. Are you certain it isn't the F25 Samba client that's causing this?
No.
Try having the F25 server share the same directory via NFS and use the F25 NFS client for testing. See if that improves things.
How about ssh? When I use ssh on Fedora 25 to drag down a file I'm getting slightly different results, 4.4MB/s. So it's faster than the GNOME samba client, whatever that's using, but it's still slower by 2x than the Windows 10 samba client.
Have you tried the iperf suggestion? First on the server, open up TCP port 5001 on the firewall (just is just temporarily--iperf defaults to port 5001), then run "iperf -s" on the server.
On the client, run "iperf -c ip-address-of-server" and wait, oh, 15 seconds or so. Both the client and server should show some results. This is from my laptop as the client over a 100Mbps wired link to my server (yes, it's an old laptop with a built-in 100Mbps NIC):
[root@golem4 ~]# iperf -c 192.168.1.50
Client connecting to 192.168.1.50, TCP port 5001 TCP window size: 85.0 KByte (default)
[ 3] local 192.168.1.52 port 38964 connected with 192.168.1.50 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 112 MBytes 94.2 Mbits/sec
So, over my 100Mbps wired link, I got 94.2Mbps.
I'm just trying to isolate this by getting file I/O, filesystems and network filesystem protocols out of the way. iperf is fairly close to "being on the bare wire" so we're really just checking the hardware, firmware and kernel network stack using iperf.
You can do similar tests using netcat (nc), but that requires filesystem I/O and not just raw bytes as iperf does. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - su -; find / -name someone -exec touch {} ; - - - The UNIX way of touching someone - ----------------------------------------------------------------------
[chris@f25h Downloads]$ iperf -c 10.0.0.3 ------------------------------------------------------------ Client connecting to 10.0.0.3, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.0.0.4 port 52272 connected with 10.0.0.3 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 35.4 MBytes 29.5 Mbits/sec [chris@f25h Downloads]$
[chris@f25s ~]$ iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local 10.0.0.3 port 5001 connected with 10.0.0.4 port 52272 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.4 sec 35.4 MBytes 28.5 Mbits/sec
This is on a 2nd client, wired connection.
[20:43 chris ~ (master *%)]$ iperf -c 10.0.0.3 ------------------------------------------------------------ Client connecting to 10.0.0.3, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.0.0.13 port 48554 connected with 10.0.0.3 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.10 GBytes 942 Mbits/sec
And on the same 2nd client, wireless connection which is firmware limited to 802.11b/g support:
[20:45 chris ~ (master *%)]$ iperf -c 10.0.0.3 ------------------------------------------------------------ Client connecting to 10.0.0.3, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.0.0.7 port 34438 connected with 10.0.0.3 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.2 sec 4.12 MBytes 3.39 Mbits/sec
Egads!
On 01/10/2017 07:30 PM, Chris Murphy wrote:
[chris@f25h Downloads]$ iperf -c 10.0.0.3
Client connecting to 10.0.0.3, TCP port 5001 TCP window size: 85.0 KByte (default)
[ 3] local 10.0.0.4 port 52272 connected with 10.0.0.3 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 35.4 MBytes 29.5 Mbits/sec [chris@f25h Downloads]$
[chris@f25s ~]$ iperf -s
Server listening on TCP port 5001 TCP window size: 85.3 KByte (default)
[ 4] local 10.0.0.3 port 5001 connected with 10.0.0.4 port 52272 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.4 sec 35.4 MBytes 28.5 Mbits/sec
Yeah, OK, that's pretty sucky. So it does look like it's the driver or firmware or some setting on the interface that's limiting the speed. I guess you could try "iw dev wlan0 link" to see what speed it thinks it's running at and "iw dev wlan0 scan dump" to see more details, but I don't know what else to try. Are you using any special hardware drivers (e.g. nVidia binaries, etc.)? They might have an effect. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Reality: A crutch for those who can't handle science fiction - ----------------------------------------------------------------------
On Wed, Jan 11, 2017 at 1:01 PM Rick Stevens ricks@alldigital.com wrote:
On 01/10/2017 07:30 PM, Chris Murphy wrote:
[chris@f25h Downloads]$ iperf -c 10.0.0.3
Client connecting to 10.0.0.3, TCP port 5001 TCP window size: 85.0 KByte (default)
[ 3] local 10.0.0.4 port 52272 connected with 10.0.0.3 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 35.4 MBytes 29.5 Mbits/sec [chris@f25h Downloads]$
[chris@f25s ~]$ iperf -s
Server listening on TCP port 5001 TCP window size: 85.3 KByte (default)
[ 4] local 10.0.0.3 port 5001 connected with 10.0.0.4 port 52272 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.4 sec 35.4 MBytes 28.5 Mbits/sec
Yeah, OK, that's pretty sucky. So it does look like it's the driver or firmware or some setting on the interface that's limiting the speed. I guess you could try "iw dev wlan0 link" to see what speed it thinks it's running at and "iw dev wlan0 scan dump" to see more details, but I don't know what else to try. Are you using any special hardware drivers (e.g. nVidia binaries, etc.)? They might have an effect.
My output from those looks like:
$ iw dev wlp1s0 link Connected to xx:xx:xx:xx:xx:xx (on wlp1s0) SSID: mywifi freq: 2412 RX: 762410485 bytes (555995 packets) TX: 33098952 bytes (236527 packets) signal: -52 dBm tx bitrate: 130.0 MBit/s MCS 15
bss flags: short-preamble short-slot-time dtim period: 1 beacon int: 100 $ iw dev wlp1s0 scan dump BSS xx:xx:xx:xx:xx:xx(on wlp1s0) -- associated TSF: 338136964783 usec (3d, 21:55:36) freq: 2412 beacon interval: 100 TUs capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431) signal: -50.00 dBm last seen: 29084 ms ago Information elements from Probe Response frame: SSID: mywifi Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 DS Parameter set: channel 1 Power constraint: 0 dB RSN: * Version: 1 * Group cipher: CCMP * Pairwise ciphers: CCMP * Authentication suites: PSK * Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000) WPA: * Version: 1 * Group cipher: CCMP * Pairwise ciphers: CCMP * Authentication suites: PSK ERP: <no flags> Extended supported rates: 24.0 36.0 48.0 54.0 WMM: * Parameter version 1 * BE: CW 15-1023, AIFSN 3 * BK: CW 15-1023, AIFSN 7 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec * VO: CW 3-7, AIFSN 2, TXOP 1504 usec HT capabilities: Capabilities: 0x138c HT20 SM Power Save disabled TX STBC RX STBC 3-streams Max AMSDU length: 3839 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 8 usec (0x06) HT RX MCS rate indexes supported: 0-15 HT TX MCS rate indexes are undefined HT operation: * primary channel: 1 * secondary channel offset: no secondary * STA channel width: 20 MHz * RIFS: 1 * HT protection: no * non-GF present: 0 * OBSS non-GF present: 0 * dual beacon: 0 * dual CTS protection: 0 * STBC beacon: 0 * L-SIG TXOP Prot: 0 * PCO active: 0 * PCO phase: 0 Country: US Environment: Indoor/Outdoor Channels [1 - 11] @ 27 dBm
This should be 802.11n (only n, no backwards compatibility for b), WPA2-PSK. I'm not quite sure how to interpret the above, to know if anything stands out.
On 01/11/2017 11:35 AM, Christopher wrote:
On Wed, Jan 11, 2017 at 1:01 PM Rick Stevens <ricks@alldigital.com mailto:ricks@alldigital.com> wrote:
On 01/10/2017 07:30 PM, Chris Murphy wrote: > [chris@f25h Downloads]$ iperf -c 10.0.0.3 > ------------------------------------------------------------ > Client connecting to 10.0.0.3, TCP port 5001 > TCP window size: 85.0 KByte (default) > ------------------------------------------------------------ > [ 3] local 10.0.0.4 port 52272 connected with 10.0.0.3 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.1 sec 35.4 MBytes 29.5 Mbits/sec > [chris@f25h Downloads]$ > > > > [chris@f25s ~]$ iperf -s > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 85.3 KByte (default) > ------------------------------------------------------------ > [ 4] local 10.0.0.3 port 5001 connected with 10.0.0.4 port 52272 > [ ID] Interval Transfer Bandwidth > [ 4] 0.0-10.4 sec 35.4 MBytes 28.5 Mbits/sec Yeah, OK, that's pretty sucky. So it does look like it's the driver or firmware or some setting on the interface that's limiting the speed. I guess you could try "iw dev wlan0 link" to see what speed it thinks it's running at and "iw dev wlan0 scan dump" to see more details, but I don't know what else to try. Are you using any special hardware drivers (e.g. nVidia binaries, etc.)? They might have an effect.
My output from those looks like:
$ iw dev wlp1s0 link Connected to xx:xx:xx:xx:xx:xx (on wlp1s0) SSID: mywifi freq: 2412 RX: 762410485 bytes (555995 packets) TX: 33098952 bytes (236527 packets) signal: -52 dBm tx bitrate: 130.0 MBit/s MCS 15
bss flags:short-preamble short-slot-time dtim period:1 beacon int:100 $ iw dev wlp1s0 scan dump BSS xx:xx:xx:xx:xx:xx(on wlp1s0) -- associated TSF: 338136964783 usec (3d, 21:55:36) freq: 2412 beacon interval: 100 TUs capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431) signal: -50.00 dBm last seen: 29084 ms ago Information elements from Probe Response frame: SSID: mywifi Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 DS Parameter set: channel 1 Power constraint: 0 dB RSN:* Version: 1
- Group cipher: CCMP
- Pairwise ciphers: CCMP
- Authentication suites: PSK
- Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000)
WPA:* Version: 1
- Group cipher: CCMP
- Pairwise ciphers: CCMP
- Authentication suites: PSK
ERP: <no flags> Extended supported rates: 24.0 36.0 48.0 54.0 WMM:* Parameter version 1
- BE: CW 15-1023, AIFSN 3
- BK: CW 15-1023, AIFSN 7
- VI: CW 7-15, AIFSN 2, TXOP 3008 usec
- VO: CW 3-7, AIFSN 2, TXOP 1504 usec
HT capabilities: Capabilities: 0x138c HT20 SM Power Save disabled TX STBC RX STBC 3-streams Max AMSDU length: 3839 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 8 usec (0x06) HT RX MCS rate indexes supported: 0-15 HT TX MCS rate indexes are undefined HT operation:
- primary channel: 1
- secondary channel offset: no secondary
- STA channel width: 20 MHz
- RIFS: 1
- HT protection: no
- non-GF present: 0
- OBSS non-GF present: 0
- dual beacon: 0
- dual CTS protection: 0
- STBC beacon: 0
- L-SIG TXOP Prot: 0
- PCO active: 0
- PCO phase: 0
Country: USEnvironment: Indoor/Outdoor Channels [1 - 11] @ 27 dBm
This should be 802.11n (only n, no backwards compatibility for b), WPA2-PSK. I'm not quite sure how to interpret the above, to know if anything stands out.
It's interesting that your n bitrates show up in the "extended supported rates" rather than the "standard rates". I'm not a wifi guru so I can't interpret a lot of that either. Here's what I have:
[root@golem4 ~]# iw dev wlan0 link Connected to 38:2c:4a:a1:0b:d8 (on wlan0) SSID: AD freq: 2437 RX: 18784014 bytes (126013 packets) TX: 56599 bytes (408 packets) signal: -25 dBm tx bitrate: 57.8 MBit/s MCS 5 short GI
bss flags: short-preamble short-slot-time dtim period: 3 beacon int: 100 You have new mail in /var/spool/mail/root [root@golem4 ~]# iw dev wlan0 scan dump BSS 38:2c:4a:a1:0b:d8(on wlan0) -- associated TSF: 7695565369786 usec (89d, 01:39:25) freq: 2437 beacon interval: 100 TUs capability: ESS Privacy ShortSlotTime RadioMeasure (0x1411) signal: -25.00 dBm last seen: 71897 ms ago Information elements from Probe Response frame: SSID: AD Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 DS Parameter set: channel 6 ERP: <no flags> ERP D4.0: <no flags> RSN: * Version: 1 * Group cipher: CCMP * Pairwise ciphers: CCMP * Authentication suites: PSK * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c) Extended supported rates: 6.0 9.0 12.0 48.0 BSS Load: * station count: 17 * channel utilisation: 55/255 * available admission capacity: 0 [*32us] HT capabilities: Capabilities: 0x19ad RX LDPC HT20 SM Power Save disabled RX HT20 SGI TX STBC RX STBC 1-stream Max AMSDU length: 7935 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 4 usec (0x05) HT RX MCS rate indexes supported: 0-23 HT TX MCS rate indexes are undefined HT operation: * primary channel: 6 * secondary channel offset: no secondary * STA channel width: 20 MHz * RIFS: 1 * HT protection: nonmember * non-GF present: 1 * OBSS non-GF present: 1 * dual beacon: 0 * dual CTS protection: 0 * STBC beacon: 0 * L-SIG TXOP Prot: 0 * PCO active: 0 * PCO phase: 0 Overlapping BSS scan params: * passive dwell: 20 TUs * active dwell: 10 TUs * channel width trigger scan interval: 300 s * scan passive total per channel: 200 TUs * scan active total per channel: 20 TUs * BSS width channel transition delay factor: 5 * OBSS Scan Activity Threshold: 0.25 % Extended capabilities: HT Information Exchange Supported, Extended Channel Switching, BSS Transition, 6 WPS: * Version: 1.0 * Wi-Fi Protected Setup State: 2 (Configured) * Response Type: 3 (AP) * UUID: dcd55186-d913-1df1-3a01-d06461bf5d81 * Manufacturer: ASUSTeK Computer Inc. * Model: Wi-Fi Protected Setup Router * Model Number: RT-AC87U * Serial Number: * Primary Device Type: 6-0050f204-1 * Device name: RT-AC87U * Config methods: Display * RF Bands: 0x1 * Unknown TLV (0x1049, 6 bytes): 00 37 2a 00 01 20 WMM: * Parameter version 1 * u-APSD * BE: CW 15-1023, AIFSN 3 * BK: CW 15-1023, AIFSN 7 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec * VO: CW 3-7, AIFSN 2, TXOP 1504 usec
My link shows a 57.8Mbit transmit rate and my access point (from the "scan dump" shows the n rates in the "supported rates" area. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - LOOK OUT!!! BEHIND YOU!!! - ----------------------------------------------------------------------
On Wed, Jan 11, 2017 at 11:00 AM, Rick Stevens ricks@alldigital.com wrote:
On 01/10/2017 07:30 PM, Chris Murphy wrote:
[chris@f25h Downloads]$ iperf -c 10.0.0.3
Client connecting to 10.0.0.3, TCP port 5001 TCP window size: 85.0 KByte (default)
[ 3] local 10.0.0.4 port 52272 connected with 10.0.0.3 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 35.4 MBytes 29.5 Mbits/sec [chris@f25h Downloads]$
[chris@f25s ~]$ iperf -s
Server listening on TCP port 5001 TCP window size: 85.3 KByte (default)
[ 4] local 10.0.0.3 port 5001 connected with 10.0.0.4 port 52272 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.4 sec 35.4 MBytes 28.5 Mbits/sec
Yeah, OK, that's pretty sucky. So it does look like it's the driver or firmware or some setting on the interface that's limiting the speed. I guess you could try "iw dev wlan0 link" to see what speed it thinks it's running at and "iw dev wlan0 scan dump" to see more details
[chris@f25h ~]$ dmesg | grep wlan0 [ 5.489106] iwlwifi 0000:6c:00.0 wlo1: renamed from wlan0 [chris@f25h ~]$ iw dev wlo1 link Connected to 00:ac:e0:57:33:00 (on wlo1) SSID: HOME-3302 freq: 2462 RX: 2732414 bytes (5093 packets) TX: 853871 bytes (3683 packets) signal: -42 dBm tx bitrate: 144.4 MBit/s MCS 15 short GI
bss flags: short-slot-time dtim period: 1 beacon int: 100 [chris@f25h ~]$ iw dev wlo1 scan dump BSS 00:ac:e0:57:33:00(on wlo1) -- associated TSF: 213169679188 usec (2d, 11:12:49) freq: 2462 beacon interval: 100 TUs capability: ESS Privacy ShortSlotTime (0x0411) signal: -41.00 dBm last seen: 33598 ms ago Information elements from Probe Response frame: SSID: HOME-3302 Supported rates: 1.0* 2.0* 5.5* 11.0* 9.0 18.0 36.0 54.0 DS Parameter set: channel 11 ERP: Barker_Preamble_Mode Extended supported rates: 6.0* 12.0* 24.0* 48.0 HT capabilities: Capabilities: 0x1ec HT20 SM Power Save disabled RX HT20 SGI RX HT40 SGI TX STBC RX STBC 1-stream Max AMSDU length: 3839 bytes No DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 4 usec (0x05) HT RX MCS rate indexes supported: 0-15 HT TX MCS rate indexes are undefined HT operation: * primary channel: 11 * secondary channel offset: no secondary * STA channel width: 20 MHz * RIFS: 0 * HT protection: no * non-GF present: 1 * OBSS non-GF present: 0 * dual beacon: 0 * dual CTS protection: 0 * STBC beacon: 0 * L-SIG TXOP Prot: 0 * PCO active: 0 * PCO phase: 0 Secondary Channel Offset: no secondary (0) WPA: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: TKIP CCMP * Authentication suites: PSK RSN: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: TKIP CCMP * Authentication suites: PSK * Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000) WMM: * Parameter version 1 * BE: CW 15-1023, AIFSN 3 * BK: CW 15-1023, AIFSN 7 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec * VO: CW 3-7, AIFSN 2, TXOP 1504 usec BSS Load: * station count: 1 * channel utilisation: 0/255 * available admission capacity: 31250 [*32us] Extended capabilities: HT Information Exchange Supported Country: US Environment: Indoor/Outdoor Channels [1 - 11] @ 16 dBm WPS: * Version: 1.0 * Wi-Fi Protected Setup State: 2 (Configured) * Response Type: 3 (AP) * UUID: 28802880-2880-1880-a880-00ace0573300 * Manufacturer: ARRIS * Model: TG862G * Model Number: RT2860 * Serial Number: 12345678 * Primary Device Type: 6-0050f204-1 * Device name: ARRIS TG862 Router * Config methods: Keypad * RF Bands: 0x1 * Unknown TLV (0x1049, 6 bytes): 00 37 2a 00 01 20 [chris@f25h ~]$
, but
I don't know what else to try. Are you using any special hardware drivers (e.g. nVidia binaries, etc.)? They might have an effect.
No out of tree modules, this is stock Fedora 25 from a clean installation, not an upgrade. The main differences from default is Btrfs for root and home, and frequently using Rawhide kernels for testing.
On 01/11/2017 11:40 AM, Chris Murphy wrote:
On Wed, Jan 11, 2017 at 11:00 AM, Rick Stevens ricks@alldigital.com wrote:
On 01/10/2017 07:30 PM, Chris Murphy wrote:
[chris@f25h Downloads]$ iperf -c 10.0.0.3
Client connecting to 10.0.0.3, TCP port 5001 TCP window size: 85.0 KByte (default)
[ 3] local 10.0.0.4 port 52272 connected with 10.0.0.3 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 35.4 MBytes 29.5 Mbits/sec [chris@f25h Downloads]$
[chris@f25s ~]$ iperf -s
Server listening on TCP port 5001 TCP window size: 85.3 KByte (default)
[ 4] local 10.0.0.3 port 5001 connected with 10.0.0.4 port 52272 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.4 sec 35.4 MBytes 28.5 Mbits/sec
Yeah, OK, that's pretty sucky. So it does look like it's the driver or firmware or some setting on the interface that's limiting the speed. I guess you could try "iw dev wlan0 link" to see what speed it thinks it's running at and "iw dev wlan0 scan dump" to see more details
[chris@f25h ~]$ dmesg | grep wlan0 [ 5.489106] iwlwifi 0000:6c:00.0 wlo1: renamed from wlan0 [chris@f25h ~]$ iw dev wlo1 link Connected to 00:ac:e0:57:33:00 (on wlo1) SSID: HOME-3302 freq: 2462 RX: 2732414 bytes (5093 packets) TX: 853871 bytes (3683 packets) signal: -42 dBm tx bitrate: 144.4 MBit/s MCS 15 short GI
bss flags: short-slot-time dtim period: 1 beacon int: 100
[chris@f25h ~]$ iw dev wlo1 scan dump BSS 00:ac:e0:57:33:00(on wlo1) -- associated TSF: 213169679188 usec (2d, 11:12:49) freq: 2462 beacon interval: 100 TUs capability: ESS Privacy ShortSlotTime (0x0411) signal: -41.00 dBm last seen: 33598 ms ago Information elements from Probe Response frame: SSID: HOME-3302 Supported rates: 1.0* 2.0* 5.5* 11.0* 9.0 18.0 36.0 54.0 DS Parameter set: channel 11 ERP: Barker_Preamble_Mode Extended supported rates: 6.0* 12.0* 24.0* 48.0 HT capabilities: Capabilities: 0x1ec HT20 SM Power Save disabled RX HT20 SGI RX HT40 SGI TX STBC RX STBC 1-stream Max AMSDU length: 3839 bytes No DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 4 usec (0x05) HT RX MCS rate indexes supported: 0-15 HT TX MCS rate indexes are undefined HT operation: * primary channel: 11 * secondary channel offset: no secondary * STA channel width: 20 MHz * RIFS: 0 * HT protection: no * non-GF present: 1 * OBSS non-GF present: 0 * dual beacon: 0 * dual CTS protection: 0 * STBC beacon: 0 * L-SIG TXOP Prot: 0 * PCO active: 0 * PCO phase: 0 Secondary Channel Offset: no secondary (0) WPA: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: TKIP CCMP * Authentication suites: PSK RSN: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: TKIP CCMP * Authentication suites: PSK * Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000) WMM: * Parameter version 1 * BE: CW 15-1023, AIFSN 3 * BK: CW 15-1023, AIFSN 7 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec * VO: CW 3-7, AIFSN 2, TXOP 1504 usec BSS Load: * station count: 1 * channel utilisation: 0/255 * available admission capacity: 31250 [*32us] Extended capabilities: HT Information Exchange Supported Country: US Environment: Indoor/Outdoor Channels [1 - 11] @ 16 dBm WPS: * Version: 1.0 * Wi-Fi Protected Setup State: 2 (Configured) * Response Type: 3 (AP) * UUID: 28802880-2880-1880-a880-00ace0573300 * Manufacturer: ARRIS * Model: TG862G * Model Number: RT2860 * Serial Number: 12345678 * Primary Device Type: 6-0050f204-1 * Device name: ARRIS TG862 Router * Config methods: Keypad * RF Bands: 0x1 * Unknown TLV (0x1049, 6 bytes): 00 37 2a 00 01 20 [chris@f25h ~]$
, but
I don't know what else to try. Are you using any special hardware drivers (e.g. nVidia binaries, etc.)? They might have an effect.
No out of tree modules, this is stock Fedora 25 from a clean installation, not an upgrade. The main differences from default is Btrfs for root and home, and frequently using Rawhide kernels for testing.
I replied to Chris (ctubbsii@fedoraproject.org) with my iw results. Note that I just tried an iperf over the wireless as well and my results suck as badly as yours:
[root@golem4 ~]# iperf -c 192.168.1.50 ------------------------------------------------------------ Client connecting to 192.168.1.50, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.247 port 36768 connected with 192.168.1.50 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 19.6 MBytes 16.4 Mbits/sec
I'm using:
[root@golem4 ~]# ethtool -i wlan0 driver: iwlwifi version: 4.8.15-300.fc25.x86_64 firmware-version: 18.168.6.1 expansion-rom-version: bus-info: 0000:01:00.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no
laptop->wireless->access point->1000BaseT->switch->1000BaseT->server
The switch in the middle is an Extreme Networks Summit 400-48T. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Never test for an error condition you don't know how to handle. - ----------------------------------------------------------------------
$ ethtool -i wlo1 driver: iwlwifi version: 4.8.17-200.fc24.x86_64 firmware-version: 22.361476.0 expansion-rom-version: bus-info: 0000:6c:00.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no
$ lspci 6c:00.0 Network controller [0280]: Intel Corporation Wireless 8260 [8086:24f3] (rev 3a)
$ dmesg | grep firmware [ 5.036668] iwlwifi 0000:6c:00.0: Direct firmware load for iwlwifi-8000C-24.ucode failed with error -2 [ 5.037902] iwlwifi 0000:6c:00.0: Direct firmware load for iwlwifi-8000C-23.ucode failed with error -2 [ 5.043887] iwlwifi 0000:6c:00.0: loaded firmware version 22.361476.0 op_mode iwlmvm
$ dnf provides /usr/lib/firmware/iwlwifi-8000C-22.ucode Last metadata expiration check: 1:14:21 ago on Wed Jan 11 16:01:02 2017. iwl7260-firmware-1:25.30.13.0-68.fc25.noarch : Firmware for Intel(R) Wireless WiFi Link 7260 Series Adapters
$ rpm -q linux-firmware linux-firmware-20160923-68.git42ad5367.fc25.noarch
In koji, I'm finding the current version of that is linux-firmware-20161205-69.git91ddce49.fc25 from over a month ago, has not been submitted as an update. Inside is iwl7260-firmware-25.30.13.0-69.fc25.noarch.rpm so then I do:
$ koji download-build --arch=noarch 822926 $ sudo dnf update *rpm $ sudo ls -l /lib/firmware | grep 8000C -rw-r--r--. 1 root root 1745176 Dec 5 09:39 iwlwifi-8000C-13.ucode -rw-r--r--. 1 root root 2351636 Dec 5 09:39 iwlwifi-8000C-16.ucode -rw-r--r--. 1 root root 2394060 Dec 5 09:39 iwlwifi-8000C-21.ucode -rw-r--r--. 1 root root 2120860 Dec 5 09:39 iwlwifi-8000C-22.ucode
Those are the same as I had before (different date, same versions and lengths). The kernel either wants -24 or -23 or those are just place holder versions *in-case* they get released; I'm not sure how that works.
Chris Murphy
Try enabling TX aggregation. This setting boosted my iperf results from 21M/s to 78M/s:
# cat /etc/modprobe.d/iwlwifi.conf options iwlwifi 11n_disable=8
On Wed, Jan 11, 2017 at 9:01 PM Gordon Messmer gordon.messmer@gmail.com wrote:
Try enabling TX aggregation. This setting boosted my iperf results from 21M/s to 78M/s:
# cat /etc/modprobe.d/iwlwifi.conf options iwlwifi 11n_disable=8
This had a negligible effect when I tried it.
On 01/11/2017 07:27 PM, Christopher wrote:
On Wed, Jan 11, 2017 at 9:01 PM Gordon Messmer <gordon.messmer@gmail.com mailto:gordon.messmer@gmail.com> wrote:
Try enabling TX aggregation. This setting boosted my iperf results from 21M/s to 78M/s: # cat /etc/modprobe.d/iwlwifi.conf options iwlwifi 11n_disable=8
This had a negligible effect when I tried it.
Christopher
Have you compared it's performance in fedora with that of windoze? If performance in windoze is better, then you might be able to use the windoze driver with a Linux wrapper.
OK so this is bat guano...
Boot off Fedora-Workstation-Live-x86_64-Rawhide-20170110.n.0.iso USB stick and retest:
[root@localhost liveuser]# iperf -c 10.0.0.3 ------------------------------------------------------------ Client connecting to 10.0.0.3, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.0.0.4 port 45208 connected with 10.0.0.3 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 70.8 MBytes 59.2 Mbits/sec
For reference the previous result on Fedora 25 with kernel 4.8.17 was: [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.4 sec 35.4 MBytes 28.5 Mbits/sec
I retested Fedora 25 to match the same kernel used by Rawhide, and I get:
[ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 49.9 MBytes 41.6 Mbits/sec
Firmware versions are the same in all three cases. And the iw outputs are all the same. And the laptop is in the same location. So there is something in the ether affecting the result, but it does seem pretty clear there's something awry with Fedora 25 and it's not the kernel or the firmware. Maybe wpa_supplicant? OK this is weird....
wpa_supplicant-2.5-5.fc24.x86_64
When I check koji, there are newer versions available for some time. wpa_supplicant-2.6-1.fc25 lkundrak 2016-11-23 12:12:48
That's listed as being in updates-testing for 2 months. https://bodhi.fedoraproject.org/updates/?packages=wpa_supplicant
OK so update to that and reboot...
[ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 48.4 MBytes 40.5 Mbits/sec
Nope. Maybe it's a NetworkManager issue? I can't really update that, or at least, I'm not willing to mix Rawhide's Network Manager on F25.
Chris
On 01/11/2017 07:12 PM, Chris Murphy wrote:
I retested Fedora 25 to match the same kernel used by Rawhide, and I get:
[ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 49.9 MBytes 41.6 Mbits/sec
Is that consistent on retries? I get really variable results on WiFi. I'd run the test several times...
# rmmod iwldvm iwlwifi ; modprobe iwlwifi # iperf -c 10.1.10.4 ------------------------------------------------------------ Client connecting to 10.1.10.4, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.1.10.94 port 57528 connected with 10.1.10.4 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 17.8 MBytes 14.9 Mbits/sec ... [ 3] 0.0-10.0 sec 22.1 MBytes 18.5 Mbits/sec ... [ 3] 0.0-10.0 sec 23.4 MBytes 19.5 Mbits/sec ... [ 3] 0.0-10.0 sec 23.1 MBytes 19.3 Mbits/sec ... [ 3] 0.0-10.1 sec 23.0 MBytes 19.2 Mbits/sec
Of course, I get better results with TX aggregation enabled:
# rmmod iwldvm iwlwifi ; modprobe iwlwifi 11n_disable=8 # iperf -c 10.1.10.4 ------------------------------------------------------------ Client connecting to 10.1.10.4, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.1.10.94 port 57554 connected with 10.1.10.4 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 88.6 MBytes 73.7 Mbits/sec ... [ 3] 0.0-10.0 sec 88.2 MBytes 74.0 Mbits/sec
Firmware versions are the same in all three cases. And the iw outputs are all the same. And the laptop is in the same location. So there is something in the ether affecting the result, but it does seem pretty clear there's something awry with Fedora 25 and it's not the kernel or the firmware. Maybe wpa_supplicant? OK this is weird....
If I'm not mistaken, with the rawhide kernel you got better results than you've posted previously in this thread. I don't think it's entirely clear that the problem isn't the kernel.
Damn strange.
The computer is in a static location for all tests. This is still using iperf in all cases, but abbreviated since I'm copying by hand. Each test is about five seconds apart.
Fedora 25 live 58 Mbit/sec 61 41
Fedora 24 live 54 Mbit/sec 46 38 65
Fedora 25 installed 29 42 38 38
There are a total of three wireless devices connected to this AP. All are connected at the same time but only the test client is actively being used when the testing is happening. But it's in an apartment building, with hundreds of units all of which have wireless APs.
On 12 January 2017 at 05:04, Chris Murphy lists@colorremedies.com wrote:
Damn strange.
The computer is in a static location for all tests. This is still using iperf in all cases, but abbreviated since I'm copying by hand. Each test is about five seconds apart.
Fedora 25 live 58 Mbit/sec 61 41
Fedora 24 live 54 Mbit/sec 46 38 65
Fedora 25 installed 29 42 38 38 co There are a total of three wireless devices connected to this AP. All are connected at the same time but only the test client is actively being used when the testing is happening. But it's in an apartment building, with hundreds of units all of which have wireless APs.
Did anyone get to the bottom of this? I installed F25 a couple of weeks ago and network performance is noticeably poorer on this machine. When browsing the internet, or particularly on Ajax based sites like gmail or google search connections seem to just drop. The previous Fedora that was on this machine (23 I think) was fine, and my laptop (still on an older Fedora) and other devices have not experienced any change. Looking in journalctl as root I see frequent renegotiation with the AP, e.g.: Mar 24 00:21:29 atlas wpa_supplicant[864]: wlp2s0: SME: Trying to authenticate with xx:xx:xx:xx:xx:xx (SSID='X' freq=5200 MHz) Mar 24 00:21:29 atlas kernel: wlp2s0: disconnect from AP xx:xx:xx:xx:xx:xx for new auth to 00:a4:23:17:18:e5 Mar 24 00:21:29 atlas kernel: wlp2s0: authenticate with xx:xx:xx:xx:xx:xx Mar 24 00:21:29 atlas kernel: wlp2s0: send auth to xx:xx:xx:xx:xx:xx (try 1/3) Mar 24 00:21:29 atlas kernel: wlp2s0: authenticated Mar 24 00:21:29 atlas kernel: wlp2s0: associate with xx:xx:xx:xx:xx:xx (try 1/3) Mar 24 00:21:29 atlas wpa_supplicant[864]: wlp2s0: Trying to associate with xx:xx:xx:xx:xx:xx (SSID='X' freq=5200 MHz) While the machine is supposedly connected.
There's also this, Mar 24 00:21:29 atlas systemd-udevd[5658]: Process '/usr/sbin/crda' failed with exit code 249. which can't be a good sign.
On Thu, Mar 23, 2017 at 10:05 PM Gordon Messmer gordon.messmer@gmail.com wrote:
On 03/23/2017 05:40 PM, Ian Malone wrote:
Did anyone get to the bottom of this?
I found that enabling aggregated TX provided a tremendous performance boost. It's off by default due to problems in some situations:
$ cat /etc/modprobe.d/iwlwifi.conf options iwlwifi 11n_disable=8
When I tried changing that, it had no effect. I've not been able to figure out what's wrong. I've just been begrudgingly ignoring the poor performance.
_______________________________________________
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 03/23/2017 05:40 PM, Ian Malone wrote:
On 12 January 2017 at 05:04, Chris Murphy lists@colorremedies.com wrote:
Damn strange.
The computer is in a static location for all tests. This is still using iperf in all cases, but abbreviated since I'm copying by hand. Each test is about five seconds apart.
Fedora 25 live 58 Mbit/sec 61 41
Fedora 24 live 54 Mbit/sec 46 38 65
Fedora 25 installed 29 42 38 38 co There are a total of three wireless devices connected to this AP. All are connected at the same time but only the test client is actively being used when the testing is happening. But it's in an apartment building, with hundreds of units all of which have wireless APs.
Did anyone get to the bottom of this? I installed F25 a couple of weeks ago and network performance is noticeably poorer on this machine. When browsing the internet, or particularly on Ajax based sites like gmail or google search connections seem to just drop. The previous Fedora that was on this machine (23 I think) was fine, and my laptop (still on an older Fedora) and other devices have not experienced any change. Looking in journalctl as root I see frequent renegotiation with the AP, e.g.: Mar 24 00:21:29 atlas wpa_supplicant[864]: wlp2s0: SME: Trying to authenticate with xx:xx:xx:xx:xx:xx (SSID='X' freq=5200 MHz) Mar 24 00:21:29 atlas kernel: wlp2s0: disconnect from AP xx:xx:xx:xx:xx:xx for new auth to 00:a4:23:17:18:e5 Mar 24 00:21:29 atlas kernel: wlp2s0: authenticate with xx:xx:xx:xx:xx:xx Mar 24 00:21:29 atlas kernel: wlp2s0: send auth to xx:xx:xx:xx:xx:xx (try 1/3) Mar 24 00:21:29 atlas kernel: wlp2s0: authenticated Mar 24 00:21:29 atlas kernel: wlp2s0: associate with xx:xx:xx:xx:xx:xx (try 1/3) Mar 24 00:21:29 atlas wpa_supplicant[864]: wlp2s0: Trying to associate with xx:xx:xx:xx:xx:xx (SSID='X' freq=5200 MHz) While the machine is supposedly connected.
There's also this, Mar 24 00:21:29 atlas systemd-udevd[5658]: Process '/usr/sbin/crda' failed with exit code 249. which can't be a good sign.
The first things I'd do is see what hardware you actually have:
# lspci | grep -i wireless
Then see which driver your wifi is using via
# ethtool -i wlp2s0
See if perhaps there's another driver or perhaps newer firmware you can use for that chipset. Sometimes the kernel or udev don't necessarily make the right decisions about which driver to use. My F25 machines with wifi are both using the iwlwifi driver (both use Intel wireless chips):
(Desktop) # lspci | grep -i wireless 04:00.0 Network controller: Intel Corporation Wireless 3165 (rev 81)
#ethtool -i wlp4s0 driver: iwlwifi version: 4.9.13-201.fc25.x86_64 firmware-version: 22.361476.0 ...
(Laptop) # lspci | grep -i wireless 01:00.0 Network controller: Intel Corporation Centrino Wireless-N 1030 [Rainbow Peak] (rev 34)
# ethtool -i wlan0 driver: iwlwifi version: 4.9.14-200.fc25.x86_64 firmware-version: 18.168.6.1 ...
I've had no issues with performance or the ability to stay connected and the laptop goes LOTS of places with me. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Duct Tape + Magic Marker = Label Maker! - ----------------------------------------------------------------------
On 24 March 2017 at 16:46, Rick Stevens ricks@alldigital.com wrote:
On 03/23/2017 05:40 PM, Ian Malone wrote:
On 12 January 2017 at 05:04, Chris Murphy lists@colorremedies.com wrote:
Damn strange.
The computer is in a static location for all tests. This is still using iperf in all cases, but abbreviated since I'm copying by hand. Each test is about five seconds apart.
Fedora 25 live 58 Mbit/sec 61 41
Fedora 24 live 54 Mbit/sec 46 38 65
Fedora 25 installed 29 42 38 38 co There are a total of three wireless devices connected to this AP. All are connected at the same time but only the test client is actively being used when the testing is happening. But it's in an apartment building, with hundreds of units all of which have wireless APs.
Did anyone get to the bottom of this? I installed F25 a couple of weeks ago and network performance is noticeably poorer on this machine. When browsing the internet, or particularly on Ajax based sites like gmail or google search connections seem to just drop. The previous Fedora that was on this machine (23 I think) was fine, and my laptop (still on an older Fedora) and other devices have not experienced any change. Looking in journalctl as root I see frequent renegotiation with the AP, e.g.: Mar 24 00:21:29 atlas wpa_supplicant[864]: wlp2s0: SME: Trying to authenticate with xx:xx:xx:xx:xx:xx (SSID='X' freq=5200 MHz) Mar 24 00:21:29 atlas kernel: wlp2s0: disconnect from AP xx:xx:xx:xx:xx:xx for new auth to 00:a4:23:17:18:e5 Mar 24 00:21:29 atlas kernel: wlp2s0: authenticate with xx:xx:xx:xx:xx:xx Mar 24 00:21:29 atlas kernel: wlp2s0: send auth to xx:xx:xx:xx:xx:xx (try 1/3) Mar 24 00:21:29 atlas kernel: wlp2s0: authenticated Mar 24 00:21:29 atlas kernel: wlp2s0: associate with xx:xx:xx:xx:xx:xx (try 1/3) Mar 24 00:21:29 atlas wpa_supplicant[864]: wlp2s0: Trying to associate with xx:xx:xx:xx:xx:xx (SSID='X' freq=5200 MHz) While the machine is supposedly connected.
There's also this, Mar 24 00:21:29 atlas systemd-udevd[5658]: Process '/usr/sbin/crda' failed with exit code 249. which can't be a good sign.
The first things I'd do is see what hardware you actually have:
# lspci | grep -i wireless
Then see which driver your wifi is using via
# ethtool -i wlp2s0
See if perhaps there's another driver or perhaps newer firmware you can use for that chipset. Sometimes the kernel or udev don't necessarily make the right decisions about which driver to use. My F25 machines with wifi are both using the iwlwifi driver (both use Intel wireless chips):
(Desktop) # lspci | grep -i wireless 04:00.0 Network controller: Intel Corporation Wireless 3165 (rev 81) #ethtool -i wlp4s0 driver: iwlwifi version: 4.9.13-201.fc25.x86_64 firmware-version: 22.361476.0 ... (Laptop) # lspci | grep -i wireless 01:00.0 Network controller: Intel Corporation Centrino Wireless-N 1030
[Rainbow Peak] (rev 34)
# ethtool -i wlan0 driver: iwlwifi version: 4.9.14-200.fc25.x86_64 firmware-version: 18.168.6.1 ...
I've had no issues with performance or the ability to stay connected and the laptop goes LOTS of places with me.
The hardware hasn't changed, and was picked specifically because it has good (and long standing) linux support:
02:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network Adapter (rev 01)
driver: ath9k version: 4.9.14-200.fc25.x86_64 firmware-version: N/A expansion-rom-version: bus-info: 0000:02:00.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no
Which is the correct driver, unless there's been a regression. It seems like key rotation or something is not taking place smoothly. I see quite a lot of this while it's connected (journactl output, lines may be truncated):
Mar 24 22:46:13 atlas wpa_supplicant[898]: wlp2s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD Mar 24 22:46:13 atlas kde5-nm-connection-editor[2310]: networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(co Mar 24 22:46:13 atlas wpa_supplicant[898]: wlp2s0: Associated with xx:xx:xx:xx:xx:xx Mar 24 22:46:13 atlas kdeinit5[1192]: networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, con Mar 24 22:46:13 atlas wpa_supplicant[898]: wlp2s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 Mar 24 22:46:13 atlas kdeinit5[1192]: networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, con Mar 24 22:46:13 atlas wpa_supplicant[898]: wlp2s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=GB
In my case might be related to https://bugs.mageia.org/show_bug.cgi?id=18935 going to try with regdomain set to GB for a while and see if it helps.
networking like molasses - I am not as sophisticated about this as you all are (do not know where to look for what causing the problem), just know even in Fedora 13 things moved far faster...will watch this thread for updated info, thanks for posting re: slow wi-fi (Note: not just slow wi-fi, even cabled connections speeds seem way slow). cheers
Allegedly, on or about 08 January 2017, mgolterhere@yahoo.com sent:
Note: not just slow wi-fi, even cabled connections speeds seem way slow
Traditionally, *everything* going slowly in a network often pointed the finger at a couple of things:
MTU
A misconfigured firewall that blocks everything, including the things that networks use to manage themselves. For instance, blocking all ICMP traffic is bad.
the line starting with "A misconfigured firewall" lit up a red flash in my mind. Not only is my box just slow slow slow but I am now unable to connect to a secure server (one that requires a CA certificate) whereas with fedora 13 this was possible. How would I test for a firewall problem (have done nothing/no changes since the simple install). Any info would be appreceiated
Note re: mail to your inbox = was that message meant for me (in particular? Have been unable to post to ask.fedora (won't accept my -password when posting) so tried this email list. Many pardons if I am doint this incorrectly...argh, hope not! Thanks for any help.
Allegedly, on or about 12 January 2017, mgolterhere@yahoo.com sent:
the line starting with "A misconfigured firewall" lit up a red flash in my mind. Not only is my box just slow slow slow but I am now unable to connect to a secure server (one that requires a CA certificate) whereas with fedora 13 this was possible. How would I test for a firewall problem (have done nothing/no changes since the simple install).
I would have thought that the default settings were okay, unless you were in a special situation (unusual network).
You're going to have to say more about what you mean by connecting to a secure server. VPN, SSH, HTTPS, something else?
Note re: mail to your inbox = was that message meant for me (in particular? Have been unable to post to ask.fedora (won't accept my -password when posting) so tried this email list. Many pardons if I am doint this incorrectly...argh, hope not! Thanks for any help.
Nah, that's my boilerplate. Years of massive amount of spam from participation in mailing lists mean that I have the server auto-delete all mail sent to the address I post to the mailing lists with. And I read the list from another address. It kills the spam, and I don't really want private messages from people I don't really know.
Your message came through here fine, I've never used, or even looked at, ask.fedora, so I can't say anything about its requirements. Though I seem to recall some thread about it a few weeks back saying you needed to post using an address that would have been verified by that external service. i.e. If gmail or facebook verify you before they let you use their service, which they do, that's considered good enough for other people to let you use their service. Not quite sure that I agree with the methodology.