BCM43456 (Pi 400) WiFi feedback thread

[PhilE]

This thread is for feedback on the performance of the BCM43456 WiFi interface found in the PI 400. It's specifically created after the release of new test firmware and "clm_blob" file - more details can be found here: viewtopic.php?f=117&t=291688

[sup]

So I installed this and now I can gat ac/80 Mhz connection. It is also much more stable and way faster than before (around 4MB/s) (I was getting 1> MB speeds and long pings previously without direct visibility to the router). When I place the Pi about 1.5 m from the router and turn off all the other devices on the network, I can get around 7-8 MB/s. Previously, I was able to get that speed with setting my country to US but it would be unstable (fast bursts interrupted by 10-30s long periods of silence and lost pings).

So from brief testing, this is a huge improvement.

Also, is it expected that I get grade C from the Bufferfloat test on Dslreports?

Screenshot from 2020-11-23 15-02-03.png (52.87 KiB) Viewed 6530 times

(those two last slow tests are due to me moving the Pi around the apartment fartehr from the router)

[PhilE]

From what I've read, Bufferbloat is a measure of latency - larger/fuller buffers leads to more latency (but potentially higher throughput). I couldn't see an explanation of what a "C" grade corresponds to.

Try a simple "ping 8.8.8.8" to see what the round-trip time is - I get 8.3ms from a Pi4 over Ethernet and an average of 10.2ms over WiFi (although WiFi is more variable). If you can connect to your router over Ethernet it will help to show the contribution to latency made by the WiFi link.

[cleverca22]

From what I've read, Bufferbloat is a measure of latency - larger/fuller buffers leads to more latency (but potentially higher throughput). I couldn't see an explanation of what a "C" grade corresponds to.

bufferbloat is also related to how things fail horribly when you do get packet loss

under normal conditions, the tcp stack in your OS will detect packet loss, and dynamically throttle itself to avoid the packet loss
but if the buffers are too big, you may have 10 seconds worth of packets stuck in a buffer, and then you have 10 seconds of delay, both in ping, and in the whole loop as tcp tries to throttle itself and find the right bandwidth to limit itself to

tcp could have even given up, and retransmitted the same packet, and then you have duplicates in the buffer, if the buffers (in the router) are too big, compared to your actual upload speed

[PhilE]

So in your opinion does a grade of C indicate a problem in this case?

[cleverca22]

So in your opinion does a grade of C indicate a problem in this case?

i also have no idea what scale they are attaching to each letter, and its much more of a router problem then a driver problem (typically)

[sup]

Well, I get grade A on my laptop (Thinkpad 530 with a four-core CPU, so much beefier) connected to the same router (I have an OpenWRT router that does away with this latency normally). When I run a speedtest (lots of downloading) and I ping the PI from the laptop, when the download starts, latency goes from single to triple digits (see attachment). That should not ideally happen. I am not sure if it is a wifi-related problem or the CPU on the Pi is just two weak, I am no expert on this.

Screenshot from 2020-11-24 12-19-09.png (172.8 KiB) Viewed 6404 times

More information is here: https://www.bufferbloat.net/projects/

Following this guide: https://evuraan.info/evuraan/stuff/bufferbloat.html, one should only need to run something like (on a recent Raspbian):

Code: Select all

#!/bin/bash

modprobe sch_cake
modprobe act_mirred
tc qdisc add dev wlan0 root cake bandwidth 30mbit

Where "wlan0" and "30mbit" needs to be filled in appropriately by the network device used to connect to the internet and a speed that is slightly bellow the maximum real rate. However, on my device, it does not seem to make a difference in the test (moving the device around and getting a better signal does make a difference). Might be that I already run the shapers on my router.

[sup]

But, to clarify, this does not have to do so much with the firmware in question, that is definitely an improvement.

[cleverca22]

That should not ideally happen. I am not sure if it is a wifi-related problem or the CPU on the Pi is just two weak, I am no expert on this.

you could check the cpu usage under "top" and see if one of the cores (hit 1 to toggle between average and per-core), is getting maxed out

[sup]

That should not ideally happen. I am not sure if it is a wifi-related problem or the CPU on the Pi is just two weak, I am no expert on this.

you could check the cpu usage under "top" and see if one of the cores (hit 1 to toggle between average and per-core), is getting maxed out

The highest I saw was 90 % on one core. Does it mean it is maxed out?

[Inglenook]

Hi.

I just upgraded my Pi 400 Raspbian install to these new drivers.

The effect is immediate and major.

With a MacBook as client and the Pi 400 as server, both using 5G Wifi and basically sitting next to each other on a desktop, iPerf3 numbers change as follows:

Old drivers: 9.02Mbps
New drivers: 148Mbps

That's a 15x improvement in speed. Dramatic!
That makes my Pi 400 more like my other devices when interacting with my 5G WiFi.

If Synaptics have got any other improvements like that up their sleeves, tell them to bring them on!

I notice that the channel width has gone from 40Mhz to 80Mhz with the new drivers.

Are there any other tweaks I should consider making?

Mike

[PhilE]

Was that with the new firmware as well as the clm_blob? Others have seen a regression with the new firmware, so we're going to roll out clm_blob to all but hold back on the firmware.

In terms of improving your throughput further you are probably limited by the SDIO interface. "sudo cat /sys/kernel/debug/mmc1/ios" shows the state of that link. The bus clock has to be an even integer divisor of the emmc clock, which is currently fixed at 250MHz, hence the 41.67MHz. Tweaking the EMMC clock ought to make 50MHz attainable, but for clock synchronisation reasons that would also require changing the core clock. Although not trivial, I think there are potential gains to be made here.

[Inglenook]

I installed both the new drivers and the new firmware - the figures I quoted were with both installed.

I shall try backing out the firmware when I get time tomorrow and see what effect that has on the WiFi speeds.

Yours, Mike.

[Inglenook]

I have backed out the firmware driver and it seems to make very little difference to performance. The new drivers seem to make all the difference.

Many thanks,

Mike.

[PhilE]

Do you mean the new clm_blob (which is a configuration file)? That is what I would expect to be most significant.

[Inglenook]

Yes, I mean the new clm_blob file - sorry for using the vague "drivers" term.

I am a bit surprised that there has not been more comment about the slow WiFi speeds on Pi 400. Without that new file, the WiFi is really unacceptably slow and it affects even browsing performance. Are other folk simply installing the new file without saying anything, or are they not using WiFi? I'm curious.

Mike.

[PhilE]

I think your experience is an outlier - although not connecting at/to 80MHz, I've not seen anything like the poor speeds that you have.

[sup]

I was getting 200KB/s when transferring over Samba before the blob. SSH and VNC worked perfectly, I only noticed the issue when I started to transfer files though.

[shawaj]

New firmware works nicely for me. Haven't speed tested yet but ac/80mhz is working.

Bit of a side note question, does this firmware / config fall under the Broadcom license still, even though it's now owned/produced by Synaptics?

[PhilE]

Bit of a side note question, does this firmware / config fall under the Broadcom license still, even though it's now owned/produced by Synaptics?

I'll be shocked if the licence terms are more restrictive, but it's a good question that I've put to Synaptics.

[shawaj]

Bit of a side note question, does this firmware / config fall under the Broadcom license still, even though it's now owned/produced by Synaptics?

I'll be shocked if the licence terms are more restrictive, but it's a good question that I've put to Synaptics.

Thought you would probably say that. But was updating the yocto meta-raspberrypi to include the new WiFi drivers and noticed there wasn't a synaptics specific one.

[PhilE]

FYI they did respond fairly quickly, but with the wrong kind of licence. I think they're now looking down the back of the sofa...

[pasdechance]

Hi all,

Just a quick question that I feel like I already read the answer to somewhere.

RE: The early-December update

If I have already modified and changed my blob, do I need to modify it again post-update? And, further to that, is the WiFi update included in the December update?

[PhilE]

The blobs in the early December release are the ones you should be using now. We didn't bump the firmware this time, after some failure reports. Once this update has been out for a while we'll revisit the firmware update.

[jpalus]

On a related note -- any chance on upstreaming this firmware to linux-firmware?