RPi 3 - Very poor wifi performance

[toadstool]

A fresh Raspbian Lite install on a brand new official Samsung Class 10 SD card installed in a new RPi 3.

Apt-get update and upgrade direct from the Pi (using screen and keyboard) works well - no apparent network issues.

However, ping and SSH from another host on the network to the RPi 3 shows abysmal results. Ping shows latency varying from 4.56 ms to almost 3000ms. SSH'ing in results in input latency with up to 5 seconds delay.

On the same network with RPi Zero and official RPi Broadcom USB wifi dongle there are no issues.

Router is a Buffalo N with current OpenWrt. No other hosts (including multiple various wifi devices) on the network have issues.

Could this be related to wifi chipset firmware, dynamic clocking frequency scaling or due to built in wifi being connected via SDIO?

I understand the Broadcom chipset for the built in wifi on the RPi 3 is different than the chipset in the Official USB dongle (BCM43438 cf. BCM43143) and it looks like each uses a different version of the Broadcom wifi firmware:

On RPi Zero with Official USB dongle:

Code: Select all

dmesg | grep brcm
[   12.284912] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr  3 2014 04:43:32 version 6.10.198.66 (r467479) FWID 01-32bd010e
[   12.320500] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[   12.327803] usbcore: registered new interface driver brcmfmac
[   13.896199] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[   16.746526] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
[   16.746555] brcmfmac: brcmf_add_if: ignore IF event

On RPi 3 with built-in wifi:

Code: Select all

dmesg | grep brcm
[   6.218470] brcmfmac: brcmf_sdio_drivestrengththinit: No SDIO Drive strength init done for chip 43430 rev 1 pmurev 24
[   6.219523] usbcore: registered new interface driver brcmfmac
[   6.380984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Dec  15 2015 18:10:45 version 7.45.41.23 (r606571) FWID 01-cc4eda9c
[   6.405090] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[   6.519407] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[   7.117588] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
[   7.117619] brcmfmac: brcmf_add_if: ignore IF event

Edit: I see others suffering the same issues: viewtopic.php?p=917689#p917689

Any ideas anyone?

[jamesh]

Could this be related to wifi chipset firmware, dynamic clocking frequency scaling or due to built in wifi being connected via SDIO?

Possible but very unlikely. More likely is a simple driver issue. Foundation are looking in to it.

[DougieLawson]

Is this likely to explain why I can't get connected to an access point where I'm sure of the password and my Win10 system connects OK?

[rurwin]

Is this likely to explain why I can't get connected to an access point where I'm sure of the password and my Win10 system connects OK?

Check which channel your WiFi is on. In my experience it is not correctly allowing channels 12 and 13, even if the internationalisation is set correctly in raspi-config.

[alexsh1]

I am having exactly the same issue with WiFi and currently using wired network until this is resolved.

[nroff-man]

Hi there.

In my own tests the Pi3 is unusable when connecting the an Atheros based
router but is passable when connecting to a Broadcom based router :-)

As for the channel availability, only channels 1-11 are available on the Pi3.

I also have a Broadcom usb hub Wifi widget and strangely enough channels
1-13 are available on an Intel desktop PC but only 1-11 on the ARM based Pi.

Bye bye

[lb]

FYI, checking out the 'next' branch of firmware/kernel apparently fixed channels 12/13 for me. I'm posting this from a Pi 3 happily connected over channel 13.

Use

Code: Select all

sudo BRANCH=next rpi-update

to check out the new kernel and firmware.

Disclaimer: it may have been something else, I also did a dist-upgrade. However no suspicious packages were upgraded.

[nroff-man]

Hi :-)

Sorry for the omission of the relevant info, my desktop kernel is

Linux beethoven 4.3.0-0.bpo.1-amd64 #1 SMP Debian 4.3.3-7~bpo8+1 (2016-01-19) x86_64 GNU/Linux

Bye.

[toadstool]

Could this be related to wifi chipset firmware, dynamic clocking frequency scaling or due to built in wifi being connected via SDIO?

Possible but very unlikely. More likely is a simple driver issue. Foundation are looking in to it.

Thanks for the reply and I'm glad it is being investigated.

Hi there.

In my own tests the Pi3 is unusable when connecting the an Atheros based
router but is passable when connecting to a Broadcom based router

As for the channel availability, only channels 1-11 are available on the Pi3.

I also have a Broadcom usb hub Wifi widget and strangely enough channels
1-13 are available on an Intel desktop PC but only 1-11 on the ARM based Pi.

Bye bye

Ah, that old chesnut! My router is indeed Atheros chipset based but I don't have a Broadcom based one to test further unfortunately.

The incompatibility between WiFi client and WiFi host AP chipsets (and their drivers...) has reared its ugly head several times before in my experience. In fact, it still goes on in some offices that I'm aware of. I seem to remember similar issues in the past with versions of the iPhone and certain routers not made by Apple. I am no expert and wouldn't know where to start programming a Linux kernel module; I am sure it is not an easy task but I do wonder whether drivers/firmware for different chipsets deviate from the IEEE 802.11 specifications to such a large degree as to adversely affect performance and interoperability.

Btw, my router is set up for 2.4GHz 802.11n +40MHz width on channel 1.

Edit: Unfortunately the "next" branch of the kernel/firmware has not solved the high latency issues I am experiencing.

[asandford]

I can connect, but it's not reliable:

Code: Select all

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Windows\system32>ping 192.168.0.122

Pinging 192.168.0.122 with 32 bytes of data:
Reply from 192.168.0.122: bytes=32 time<1ms TTL=64
Reply from 192.168.0.122: bytes=32 time<1ms TTL=64
Request timed out.
Request timed out.

Ping statistics for 192.168.0.122:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Windows\system32>ping 192.168.0.122

Pinging 192.168.0.122 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.0.30: Destination host unreachable.

Ping statistics for 192.168.0.122:
    Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),

C:\Windows\system32>ping 192.168.0.122

Pinging 192.168.0.122 with 32 bytes of data:
Reply from 192.168.0.30: Destination host unreachable.
Reply from 192.168.0.30: Destination host unreachable.
Reply from 192.168.0.122: bytes=32 time=3ms TTL=64
Reply from 192.168.0.122: bytes=32 time=55ms TTL=64

Ping statistics for 192.168.0.122:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 55ms, Average = 29ms

C:\Windows\system32>

[davehardy20]

I got my RPi 3 yesterday and I downloaded and setup a brand new SD card with the latest Jessie build and updated it.
The wifi worked and detected the various wifi networks from my neighbours houses, what it failed to do was detect my wifi network.
They are a 5ghz AC1750 and 2.4ghz N using TrendNet Access Points.
I'm guessing there is an issue with the wifi setup of the RPI 3 as it works fine with a usb dongle and can detect all of my wifi networks.

Everything else seems to be fine, even the 7" touchscreen I thought might be a problem.

Waiting for an update patiently

Dave

[rurwin]

The Pi3 does not do 5GHz, although the power levels for it are listed in syslog/dmesg. That's not a bug; that's a limitation of the hardware.

[r3d4]

The Pi3 does not do 5GHz

It was a surprise to find this in the spec!

[davehardy20]

The Pi3 does not do 5GHz, although the power levels for it are listed in syslog/dmesg. That's not a bug; that's a limitation of the hardware.

I can live with the fact that it doesn't do 5ghz,(I included the 5ghz for completeness) it should however have picked up the 2.4ghz network.

[jahboater]

The Pi3 does not do 5GHz, although the power levels for it are listed in syslog/dmesg. That's not a bug; that's a limitation of the hardware.

Just for interest, the on-board antenna does support 5GHz

[shusheer]

Just to add my verification of the problem - as pointed out, with Pi3 connecting to wifi (channel 11, TP-Link WDR3600 router with dd-wrt running) I get ping times up to 3000ms. This makes SSH rather less responsive, but not impossible to use. wget gives me about 4MByte/sec downloads from another machine on my network.

Oddly, if I plug in the ethernet to the same network, ping-times suddenly drop to sub-msec as they should be (even though I am pinging the IP address associated with wlan0), and wget gives me 11MByte/sec. However, dd-wrt shows me that the traffic is not actually going over wifi, so that download speed is probably just the ethernet 100MBit speed.

Even more odd, if I plug the ethernet into a different network than the wifi is on, the wifi IP address becomes entirely unresponsive, which is not what I would have expected.

This could all be an artefact of my network configuration, but the Pi3 is directly out of the box, with Jessie Lite image from 26-02-16, so hopefully this problem description helps whomever is working on this problem.

In the meantime I'll just use it as a faster Pi2 and turn off the wifi

[nroff-man]

Hi

For the record, as per the other threads, disabling power
management solves the connection issues for me.

You can add something like this in your interfaces file:

Code: Select all

 pre-up iw dev $IFACE set power_save off
 post-down iw dev $IFACE set power_save on

Good luck

[shearn89]

As per this thread: viewtopic.php?f=28&t=44044&start=425

Turning off power management seems to have massively improved the situation for me!

[jamesh]

Just to spice the post up, I have a Lenovo 440T laptop that had a similar problem, wireless keeps disconnecting. turns out that the inbuilt Intel Wifi adapter and it's driver are unbelievably bad. All sorts of settings tried, including power management, in the end used a Nano USB wifi dongle from the Pi, worked first time.

Latest driver has helped on board stuff, still a bit rubbish though.

So it's not just the pi wifi! Even Intel have problems.

[markr74]

I am also experiencing poor performance with the WiFi on pi 3

I have tried power, Branch etc, but to no avail.

Hopefully the foundation will shed some light on this issue.

Many thanks
Mark

[shusheer]

Just dropping a note to confirm that my Pi3 wifi issues (long ping-time, drop-outs) were fixed by adjusting power management.

Doing this

Code: Select all

sudo iwconfig wlan0 power off

on the Pi3 whilst pinging it from another machine on the network completely solved the problem:

Code: Select all

64 bytes from 192.168.1.135: icmp_seq=93 ttl=64 time=1879 ms
64 bytes from 192.168.1.135: icmp_seq=94 ttl=64 time=872 ms
64 bytes from 192.168.1.135: icmp_seq=95 ttl=64 time=4.30 ms
64 bytes from 192.168.1.135: icmp_seq=96 ttl=64 time=363 ms
64 bytes from 192.168.1.135: icmp_seq=97 ttl=64 time=1965 ms
64 bytes from 192.168.1.135: icmp_seq=98 ttl=64 time=966 ms
64 bytes from 192.168.1.135: icmp_seq=99 ttl=64 time=4.16 ms
64 bytes from 192.168.1.135: icmp_seq=100 ttl=64 time=361 ms
64 bytes from 192.168.1.135: icmp_seq=101 ttl=64 time=368 ms
64 bytes from 192.168.1.135: icmp_seq=102 ttl=64 time=1878 ms
64 bytes from 192.168.1.135: icmp_seq=103 ttl=64 time=871 ms

then becomes this:

Code: Select all

64 bytes from 192.168.1.135: icmp_seq=104 ttl=64 time=4.21 ms
64 bytes from 192.168.1.135: icmp_seq=105 ttl=64 time=5.34 ms
64 bytes from 192.168.1.135: icmp_seq=106 ttl=64 time=4.42 ms
64 bytes from 192.168.1.135: icmp_seq=107 ttl=64 time=5.08 ms
64 bytes from 192.168.1.135: icmp_seq=108 ttl=64 time=4.24 ms
64 bytes from 192.168.1.135: icmp_seq=109 ttl=64 time=4.75 ms
64 bytes from 192.168.1.135: icmp_seq=110 ttl=64 time=5.69 ms
64 bytes from 192.168.1.135: icmp_seq=111 ttl=64 time=4.57 ms

There is a nice description on how to make this (plus a few other changes) survive reset, which is important as several people have reported that without doing this, some Pi3s will no longer accept any wifi connections after a few minutes.

viewtopic.php?f=28&t=44044&start=455

[dchao99]

My problem was temporarily solved by disabling power management as well. But as soon as I connect an external SSD to the USB port, the long ping delay comes back again. (The same setup is working on RPi2 with the a WiFi dongle)
PS: I am running on a 12W Apple USB power supply with a very short 30cm USB cord between it and the RPi3.

[dom]

The latest rpi-update kernel now disables power saving by default. If you have had issues, the please remove any current workarounds and try the rpi-update firmware/kernel and report if it works for you.

Usual caveats apply - rpi-update firmware/kernel is for testers and new bugs are possible.

[jahboater]

The latest rpi-update kernel now disables power saving by default. If you have had issues, the please remove any current workarounds and try the rpi-update firmware/kernel and report if it works for you.

Hi Dom, I applied the update and it works for me.
I had longish and erratic ping times (say 60-90ms) which drop to a steady 4-5ms with power management off.
I did see that iwconfig still reports "Power Management:on".
Thanks

[jbeale]

Is this a fundamental problem with the chipset not properly supporting power management, or a driver issue, or compatibility specific to the AP on the other end of the link? I'm not sure what wifi power management does, but if it reduces the amount of 2.4 GHz RF transmitted or the electrical energy used (without affecting normal function, of course) that seems a worthy goal. When the Pi is powered up but doesn't need network bandwidth, it would be nice to reduce un-needed interference in the often crowded wifi airspace.