What’s Wrong with the Raspberry Pi

The Raspberry Pi is an incredibly popular device that has a well deserved fame for its affordability, versatility, possibilities and vibrant community. It is easy to find fan projects and publications praising it, but most people are not aware of its weak points until they suffer them and come across the information on the forums.

I will try to explain some of the personal problems that I have with the Pi, as well as some of the issues people have all the time, most often without realizing it, and finally why I do not recommend it for some applications, specifically NAS kind of services such as NextCloudPi and Open Media Vault. Hopefully this will save me time in order to avoid repeating myself all over the forums.

I have had many Raspberry Pis and I have been using them for many years. When the first model came up in 2012, it was a huge milestone for the hobbyist SBC market. Even though there were already some nice boards around, such as the Beagleboard and the Odroid, these were quite pricey and only hardcore hobbyists could understand what they could offer and justify the investment.

The Pi though, came with a very affordable price tag. It was not that powerful compared to what we already had, but it was so cheap that it exploded in popularity. Blogs, shields and extensions, people sharing their projects, tons of libraries… the Raspberry Pi was the first one to achieve all that and to this day a thriving community is the biggest reason why I would understand people getting a Pi over other boards.

But this is 2019 now, so we can have another look around. In my opinion there is better quality and more open alternatives for the same price. I will try to explain.

Performance

The Raspberry managed to be that affordable by cutting some corners. The result is a board that is underpowered for some tasks compared to its competition. In particular, it performs poorly in terms of both network and USB functionality.

The device uses a SMSC LAN9514 chip that connects to the SoC via a single USB channel, acting as a USB-to-Ethernet adaptor and USB hub at the same time. This implies that Ethernet and USB are shared and are competing with each other, which ruins the typical NAS use case of uploading something over the network and storing it to a USB drive, let alone adding RAID to the mix.

For this same reason, even when last year they finally provided a model with Gigabit Ethernet, the real network performance of the device is nowhere close to real Gigabit performance, but around 40MB/s maximum in sheer networking speed, 20MB/s maximum if we are transfering to a USB device . There have been affordable boards with real Gigabit Ethernet for a while.

Actually Wi-Fi doesn’t go through the SMSC , but is connected to the BCM4343 chip through SDIO instead, so this bottleneck could somehow be avoided by using Wi-Fi. In any the wireless chip is not great either and would have to compete with other interfering devices in the surroundings for airtime anyway so it’s not a great alternative.

For the reasons stated above I would not recommend the pi to be used in a NAS kind of scenario, be it Open Media Vault or Nextcloud.

The real brain of the Pi is not open source

If you have been around software freedom discussions, the number one concern in our Linux systems is the presence of closed source binary blobs. I won’t go into details here but the concern is that those parts of your system can’t be audited and have access to everything that is going on in our devices. This has led to great efforts by the community, such as the Android Replicant to free our systems from any binary blobs, which is a painful, tedious and slow process.

We are in a similar situation with the Raspberry Pi. The CPU and the GPU are embedded in the same BCM2837B0 chip . The CPU is a 1400 MHz 64-bit quad core ARM A53 (in the Pi3B), and the GPU is a dual core 32-bit VideoCore IV running at 400MHz. This is common in the mobile device SoC world as saves cost and power and everything is embedded in the same chip. Freescale IMX and Allwinner are competitors using a similar approach.

So we have six cores in the latest Pi, but only four of them are ARM. Linux runs on that ARM CPU, we know that, but we might be surprised to learn that Linux on this device is only a second class citizen. The GPU cores run a real time operating system called ThreadX . This operating system is closed source and rules the system without the open source Linux Kernel being aware of it.

When the Raspberry Pi starts booting the CPU is completely disconnected (technically in reset state) and the GPU is the one that starts the system. You can have a look at the /boot folder and you will see some of the binary blobs used by the GPU to both start the CPU and run its own ThreadX OS ( bootcode.bin and start.elf ). You can learn more details about the boot process here .

It is the GPU who mounts the SDcard, gets those blobs and reads the configuration from that config.txt text file that we have to edit to configure video settings or overclocking the GPU. Linux is not involved in any of that.

After the GPU has the CPU load the Linux Kernel, it doesn’t just stay there waiting to act as a graphics-processing-unit . The GPU is still in charge. Have you ever thought about who is printing those logos when the Pi boots connected to HDMI? or those lightning or temperature symbols when there is throttling going on? Exactly, it is ThreadX on the GPU doing that. Linux is just not aware of this.

We cannot know everything the GPU is doing, but we do know some things that it is in charge of. The most relevant one for this discussion is that ThreadX monitors for undervoltage, which is a widespread issue as we will see next, and will underclock the CPU to prevent instructions failing and the CPU to hang, which results in people’s devices running at 600MHz instead of 1400MHz in the best case. This throttling starts happening at 4.65V and can also be triggered by temperature. Linux and its frequency governor still thinks that is happily running at full speed.

This is only what we can see. Because the main OS is closed source we have not way of knowing what else it is doing or is capable of doing which will always be a concern for privacy aware individuals.

There is at least one patent included in the closed source blob that will prevent it from being released until at least 2025 , but we don’t know if there is any intention of doing so even then. There have been attempts at reverse engineering the VideoCore IV and generating open source firmware for the VideoCore IV, but unfortunately the project died before getting to produce anything useful. Just like with Android blobs, this is incredibly hard work.

Powering issues

This is not a technical fault of the Raspberry Pi, but more of a very typical user mistake.

The first model barely used 80 mA, but each new generation is more powerful than the previous one, and for that reason also more power hungry . On top of that, many users connect USB devices that also draw power, unless they come with their own power supply.

The microUSB connector was only originally designed to provide 1.8A , and even though that is an old standard and you can find chargers that perform just fine at more than that, so many people try to reuse old phone 1A chargers or buy cheap adaptors online to power their Raspberry Pis. The Pi is a computer, it requires a good quality, stable power supply that provides a stable 5V at the input and is capable of providing 2.5A. Not only the transformer needs to be decent, but also the connection needs to be good (or there will be a voltage drop) but more importantly, the cable needs to be good, or there will be a big drop along it. Bad cables are even more typical to find than unstable voltage supplies, so please, use a good cable, maybe a 20AWG or similar, or just get the official power supply. The take away is that not any USB charger is going to work properly, even if it is 2.5A 5V.

Add this to was we saw in the last section and we can begin to see the big picture. Most users are running their devices undervolted, and the GPU is hiding this from them, so they are actually running underclocked at 600MHz, almost as bad as the original ARMv6 pi.

In many cases not even the GPU efforts are enough and the system randomly fails or just hangs. This mostly happens under load which is when the transistors require more power. Then, the user goes to the forums and complaints: my power supply is just fine, I just ran this and that and it didn’t fail . Of course this is not true, but often they won’t believe it.

In my opinion this is what the Japanese would call Poka Yoke , in other words, we should design our systems in order to prevent the user to shoot itself in the foot, by design. Again, the official power supply is very good quality for the price and I highly recommend it.

I don’t like that they throttle the board silently outside of my control. I would rather have the system hang so I can realize what is going on and replace the PSU than to fool users and have them complaint in frustration all over the internet . It is hard to imagine a reason why the developers of the Pi would do this if it is not to hide the Poka Yoke issue.

Checking for power issues

It took too long, but we finally have this logged in the Linux Kernel. If you see in your system logs

kern  :crit  : [ 1701.464833    2.116656] Under-voltage detected! (0x00050005)
kern  :info  : [ 1707.668180    6.203347] Voltage normalised (0x00000000

, then you are suffering from undervoltage. It is nice that at least Linux logs this information now, but if we want to get more information, we have to access the GPU directly.

The vcgencmd command is able to communicate with the ThreadX firmware to get information about the system, or to change settings.

# vcgencmd get_config int
arm_freq=1000
core_freq=500
sdram_freq=600
over_voltage=6
disable_overscan=1
force_pwm_open=1

We can use the vcgencmd measure_clock arm and vcgencmd measure_volts commands to read the real frequency and voltage. This is an example output from a moritoring script by tkaiser.

# With a crappy PSU and/or Micro USB cable output looks like this
# on a RPi 3:
#
# 44.0'C  600 MHz 1010000000000000000 1.2V
# 44.5'C  600 MHz 1010000000000000000 1.2V
# 44.0'C  600 MHz 1010000000000000101 1.2V
# 44.0'C  600 MHz 1010000000000000101 1.2V
# 44.0'C  600 MHz 1010000000000000101 1.2V
# 44.5'C  600 MHz 1010000000000000000 1.2V
# 45.1'C  600 MHz 1010000000000000101 1.2V
# 
# With an ok-ish cable it looks like this (when running cpuburn-a53):
# 
# 48.3'C 1200 MHz 0000000000000000000 1.3312V
# 48.3'C 1200 MHz 0000000000000000000 1.3312V
# 48.3'C 1200 MHz 0000000000000000000 1.3312V
# 48.3'C 1200 MHz 0000000000000000000 1.3312V
# 50.5'C 1200 MHz 0000000000000000000 1.3312V
# 56.4'C  600 MHz 0000000000000000000 1.2V
# 54.8'C  600 MHz 1010000000000000101 1.2V
# 55.3'C  600 MHz 1010000000000000101 1.2V
# 55.8'C  600 MHz 1010000000000000101 1.3312V
# 53.7'C  600 MHz 1010000000000000101 1.2V
# 51.5'C  600 MHz 1010000000000000101 1.2V
# 51.0'C  600 MHz 1010000000000000101 1.2V
# 
# And only by bypassing the crappy connector you can enjoy RPi 3
# performing as it should (please note, there's a heatsink on my RPi
# -- without throttling would start and then reported clockspeed
# numbers start to get funny):
# 
# 75.2'C 1200 MHz 1010000000000000000 1.3250V
# 75.8'C 1200 MHz 1010000000000000000 1.3250V
# 75.8'C 1200 MHz 1010000000000000000 1.3250V
# 76.3'C 1200 MHz 1010000000000000000 1.3250V
# 76.3'C 1200 MHz 1010000000000000000 1.3250V
# 73.6'C 1200 MHz 1010000000000000000 1.3250V
# 72.0'C 1200 MHz 1010000000000000000 1.3250V
# 70.4'C 1200 MHz 1010000000000000000 1.3250V
#
# Now with a pillow on top for some throttling:
#
# 82.2'C 1200/ 947 MHz 1110000000000000010 1.3250V
# 82.7'C 1200/ 933 MHz 1110000000000000010 1.3250V
# 82.7'C 1200/ 931 MHz 1110000000000000010 1.3250V
# 82.7'C 1200/ 918 MHz 1110000000000000010 1.3250V
# 82.2'C 1200/ 935 MHz 1110000000000000010 1.3250V
# 79.9'C 1200/1163 MHz 1110000000000000000 1.3250V
# 75.8'C 1200 MHz 1110000000000000000 1.3250V
#
# And here on RPi 2 with crappy USB cable and some load
#
# 50.8'C  900 MHz 1010000000000000000 1.3125V
# 49.8'C  900 MHz 1010000000000000000 1.3125V
# 49.8'C  900/ 600 MHz 1010000000000000101 1.2V
# 49.8'C  900/ 600 MHz 1010000000000000101 1.2V
# 48.7'C  900/ 600 MHz 1010000000000000101 1.2V
# 49.2'C  900/ 600 MHz 1010000000000000101 1.2V
# 48.7'C  900 MHz 1010000000000000000 1.3125V
# 46.5'C  900 MHz 1010000000000000000 1.3125V
#
# The funny thing is that while the kernel thinks it's running
# with 900 MHz (performance governor) in reality the 'firmware'
# throttles down to 600 MHz but no one knows :)

Conclusion

I think that the Raspberry Pi has been a very important event in the history of SBCs but today it falls behind in quality, performance and transparency. There are other affordable alternatives out there where developers have given more consideration to those issues.

Despite all this, I am using the Raspberry Pi as a means to reach my goal of helping people self host their personal cloud services, and given how popular this board is, it still makes sense for me to support it as long as it is useful towards that purpose.