If you are new to the element14 Community, we have historically put new models of the Raspberry Pi through their paces before, and you can read how we did so here:
Putting the New Raspberry Pi 2 to the Test
These tests vary from measuring its electrical draw, to assessing its processing capabilities and network connectivity, to 3D rendering. As time progresses, I tend to find more tests compiled for the ARM processor, or different ways to test the hardware. This time, I will be working to my strengths and focusing more on the areas which people prefer: networking and processing power.
I do not have an 'ideal' test setup, far from it. These tests are not completed in a laboratory with Faraday cages - this is done at my home, with my broadband internet connection (that's about 100mbit) in England, and I think that is just fine; because when you buy your Raspberry Pi, home is probably where you will also be using yours, and you will want to know that it works.
Besides, the results scale reasonably well.
We have a new processor!
The Raspberry Pi 4 brings solid changes to the System on a Chip (SoC for short), and with the rest of the board, changes that I have seen requested since the board first appeared many years back. And I will be most interested in what people will expect of the platform from now on, so now let us see what is different!
Component / Board
Raspberry Pi 4 Model B
Broadcom 2711, Quad-core Cortex-A72 64-bit ARMv8 SoC
|Processor Speed||1.5Ghz per core|
|Video Chip||VideoCore VI at 500Mhz|
|Max Power Draw||3A|
|Wireless LAN||2.4Ghz and 5Ghz Dual-Band On-Board Antenna, supporting IEEE 802.11 b/g/n/ac|
|Bluetooth||Bluetooth Low Energy (BLE) 5.0|
|Ethernet / Local Area Network||1000mbps Gigabit (802.3ab using dedicated chip)|
The SoC is in a familiar package, being topped off with the metal heat-sink-type plate that has been introduced with the Raspberry Pi 3 Model B+; this allows for any heat generated to be dissipated a lot more easily than the usual black ceramic enclosure found on earlier models.
The processor has been created with a 28 nano-meter lithographic process - this is new for the Raspberry Pi, and it basically means a processing performance increase, as the smaller components are, the more components can be fit into the space. This means that the VideoCore, the main graphics component of the processor, has been upgraded to the VideoCore VI, and it is 100Mhz faster than its previous version the VideoCore IV. The ARM CPU has been switched out from the Cortex-A53 to the improved Cortex-A72, with a further 100Mhz speed increase to 1.5Ghz from the old 1.4Ghz.
This all means that, ultimately, we need more power. The USB-C connector supplies the much needed 3 amps at 5 volts, though there's no sign of support of negotiating 'QuickCharge' higher voltage or amp pull from new USB ports, so you may be limited to using the dedicated power supply for this board rather than your new smartphone mobile charger or connecting it to the latest USB 3.1 port on your computer.
Comparing the Pi 4 Model B against its Predecessors
|Section||Raspberry Pi 4 Model B||Raspberry Pi 3 Model B+||Raspberry Pi 3 Model B||Raspberry Pi 2 Model B v1.1||Raspberry Pi 1 Model B+|
|Model Name||ARMv7 Processor rev 3 (v7l)||ARMv7 Processor rev 4 (v7l)||ARMv7 Processor rev 4 (v7l)||ARMv7 Processor rev 5 (v7l)||ARMv6-compatible processor rev 7 (v6l)|
|Instruction Features||half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32||half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32||half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32||half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm||half thumb fastmult vfp edsp java tls|
|CPU Max Mhz||1500.0000||1400.0000||1200.0000||900.0000||700.0000|
|CPU Min Mhz||600.0000||600.0000||600.0000||600.0000||700.0000|
The outputs in the chart are combined from 'cpuinfo' and 'lscpu', both are Linux commands for pulling information from the processor. It also provides a basic benchmark, 'BogoMIPS' which is one of the more unscientific benchmarks available for measuring the CPU speed that Linux can do when it is doing absolutely nothing.
The lscpu command under Raspbian reported a new section for the BCM2711 processor, 'stepping'. I checked this against previous lscpu outputs for the other models of Pi and it hasn't been reported before, this time it was reported with a value of 'r0p3'. I also noticed it now provides its "Vendor ID" as ARM.
I found it interesting that it reports as a revision behind the chip used in the Pi 3 Model B+, though we see a consistent use of the 'Model' parameter, this time set to '7'.
The commands I used can be installed and run on your own installation of Raspbian, the following commands will set this up for you:
sudo apt-get update
sudo apt-get install lscpu cpuinfo lshw
What's that? True Gigabit Ethernet? USB 3.0?
Yes, we are finally there. To some it was a wretched component of the Raspberry Pi which held it back over the years, and the shared speed between the 100mbps Ethernet and USB 2.0 hub is no more.
USB is now handled thanks to the Via Labs 805 chip, supporting USB 3.0 revision 1.0, and a few additional features that we can only assume might make their way onto the hardware in the future, such as the PCI Express 2.0 support, or the ability to have 2 more USB 3.0 ports - because at present we only have two. Still, it is a step in the right direction.
Broadcom are providing the 1000BASE-T IEEE 802.3ab Gigabit Ethernet (GbE) chip, but fortunately the BCM54213PE supports 100mbps and 10mbps if you need the fall back to the slower days, and we haven't lost the ability to use the .
About that VideoCore VI...
Some people are very, very sleuth-y. About a year ago, Michael Larabel wrote on a website called phoronix about the VideoCore V being mentioned, and yet no signs of it anywhere, yet there was a hint at a VideoCore VI on github. I will not be going down the rabbit hole of breadcrumb trails here to find all of the references, though it is worth mentioning that there are hints of support not only for OpenCL but also Vulkan, the OpenGL library.
Vulkan is a library set which allows optimised rendering of 3D with little CPU overhead; basically, faster, nicer, more efficient. One day we may be benchmarking that on the Raspberry Pi.
With the introduction of a speed increase on the main graphics chip, we also have the functionality of supporting two 4k (that's 3840 x 2160 pixels) resolution screens over HDMI. Using two at once reduces the update rate of the screen to 30 times per second, which is pretty slow, but it is suitable for day to day computer work.
Using one screen means you can run at 60 updates per second, 4kp60, and your second screen can actually then run at 1080p60 - which means you won't necessarily lose out on the high update rate, and maybe you are not lucky enough to run with two high resolution screens anyway.
If you are not familiar with updates per second, or hertz, or refresh rate: basically if your computer can render, say, a game at 60 frames per second, and your screen can only update at 30 frames per second, your screen is going to look slow and not silky smooth and natural. It will be your call as to what you prefer.
The VideoCore VI is also running 100Mhz faster, and while this means that it can run a little hotter, it should give us more power to render 3D environments faster and better, overall improving the experience.
It is worth noting that there are some settings which you need to be aware of with 'raspi-config'. Enabling 4k output over HDMI will disable the analog video, the composite out over the 3.5mm jack; however thanks to raspi-config we can also disable the analog video, and we can disable 4k output over HDMI at the same time. At the moment I am not entirely sure what that allows us to do, perhaps it frees up some internal GPIO on the processor?
How Fast can it Render?
There are a series of tests which I have yet to get the opportunity to test on the older Raspberry Pi boards, though rest assured I certainly can, and those are to verify the render speed of the Raspberry Pi's VideoCore under various circumstances and environments.
One such test for how fast the VideoCore can render can be a tool called 'glxgears', though if you do not pass it an environmental parameter, you will quickly find that the amount of frames per second that the utility can render is limited by the refresh rate of the screen (this would be a good test of whether 4kp30 is actually updating the screen 30 times a second, someone buy me a 4k screen? as it should limit it to 30fps) so I typically turn this setting off to get an idea for the amount of frames that can be rendered.
We're getting about 1100fps with glxgears, which is a pretty solid result. This uses the OpenGL library to render a set of three cogs that rotate to the screen. Now, it has been mentioned that the VideoCore is capable of OpenGLES, OpenCL and Vulkan, and this means that we should be able to render a whole lot more than just three cogs. In fact, most of you reading this have probably played Minecraft at some point, and that involves cubes, shapes and textures, and those encapsulate different mechanisms in 3D rendering and memory.
There is a test we can run which will put the VideoCore through its functionality a little bit more, and that is glmark2. At the moment, glmark2 only supports OpenGL/ES 2.0 rather than OpenGLES 3.0, though it is a step in the right direction. It can be compiled on your computer of choice, I compiled it with opengl, x11 and opengl es support. Trying to run glmark2 in OpenGL mode on the Pi 4 crashed, which is not surprising as it does not fully support the instruction set, however running it in OpenGLES was fine.
In general, so long as the FPS (frames per second) is higher than your monitors refresh rate (typically 60hz, so 60fps) then we are onto a good framerate rendered to the screen. In the results here we can see that some areas certainly fall lower than that. These tests are particularly rendering particular features of OpenGLES individually, so combined and pushing a larger amount of vertices or polygons, as graphics are made up of, with these features will probably bring the render speed down, the 'terrain' and 'refract' tests struggled to make the grade. In these results we would also prefer 'frametime' to be smaller, while FPS is higher.
This test was also done with default settings, so the rendering area wasn't 1920x1080, it was more like 800x600; this rendering resolution will have an effect on the benchmark as well - so it is certainly an area you could play about with and compare!
You can find some example scores to compare against here and here, and we will have a good idea of how this score shapes up when it is compared against other models from the past and in the future. Give it a go?
If anyone can get Quake 3 Arena compiled to work on it, let me know and we will have a 1v1 instagib tournament match!
Testing the Processor Speed
The tools which I use to put the CPU through its paces are tried and tested methods of speed testing; we run it on one core, then up to 4 cores of the processor, and do simple tests like "how fast can it compute prime numbers?" through to "how fast can it literally count?"
The results from these tests are often returned in measurements of time, and typically lower values are better, unless we are measuring how fast information is transferred at once, in which case higher numbers are better.
This software tells the processor to compute prime numbers, and it has been covered before. What we're interested in here is the total time taken for each model of the Raspberry Pi to have taken to compute the numbers, the lower value the better.
We also have values such as the minimum amount of time it took to compute a single number, the max amount of time and the average amount of time overall. These nuances give us insights into how variable performing an action on the computer that is the Pi can take, since Linux can distract the board from what we want it to do.
It is easy to see that the newest model of the Raspberry Pi is taking the lead; compared to the previous model it is still faster if only by a small amount, perhaps we are starting to see a plateau in performance as we hit Moore's Law versus processor temperature.
There is still significant improvement in the time when we are computing numbers in parallel on each processor core instead of on a single core.
I will admit that these results are a little trickier to present and interpret, especially as the Raspberry Pi 1 Model B+ just takes that much more time to execute the times, so let us break this down a little.
"1T Min" - this is where, on a single thread, each board took the minimum amount of time to calculate a number. And we can see the clear cascade, as even in "1T Avg" which is the average time overall on all calculations, that the Pi 4 Model B takes the crown, even in "4T Min" and "4T Avg" which is where it is processed on four threads, and it is on average faster.
However, we are seeing some interesting results for the maximum amount of time taken with 1T (one thread) and 4T (four threads). The maximum amount of time taken is less on the Raspberry Pi 3 Model B; perhaps there is just something about the processor core which is better at computing these numbers in that model of board? Still, it doesn't win by much.
This is a method of testing the processor that is almost lost to the sands of time, I retrieved the source code for this one from the archive of the internet purely because I love that it compares it against old computer chips (the original sites are now very dead).
Taken from the original documentation:
"The emulated floating-point benchmark includes routines that are similar to those that would be executed whenever a system performs floating-point operations in the absence of a coprocessor. In general, this amounts to a mixture of integer instructions, including shift operations, integer addition and subtraction, and bit testing (among others)."
This refers to the 'fp emulation' test in the chart; I wonder if something was broken in the Raspbian I ran this test on, as sometimes I am forced to run a pre-release build of Raspbian that is basically a development version.
Still, the 'numeric sort' and 'string sort' tests are those which should be self explanatory: it's the amount of time taken to sort numbers, letters and characters, and less is better. nBench has more tests, I decided that posting the ones that stood out would be better.
This is a utility used to check if your system memory is faulty, and it can still be a good check of how long it takes to check out your memory. Lower is typically better, and we can see that the new Pi really takes a chunk off the time.
In these tests we only check the first 256 megabytes of RAM - since not all boards have the same amount (especially with the new board having up to four gigabytes!) we can still see a significant difference.
Being able to check through memory faster is important, because information is copied to/from memory, not only calculations that we do, but also when we run software and copy files it is usually copied into memory first and then sent on its way - so when you are doing network transfers, we still touch on memory in some way.
NEON Speed Test
I have previously mentioned Neon; it is a technology that was introduced to ARM7 processors to improve the multimedia experience by accelerating audio and video encoding/decoding along with rendering. It has some uses in signal processing as well.
Not all of the Raspberry Pi models have this functionality, and it is measured in how many floating point (decimal) operations per second it can perform - so higher is better.
I may have to look up an updated version of Roy's Benchmark Test to continue to use in the future, as the ARMv8 architecture supports 64bit Neon instructions, and I think this test was only meant for 32 bit.
Either way, you can expect better performing multimedia on your hardware once you have this in your hands - which should come as no surprise as the VideoCore VI supports h265 decoding!
Taking Advantage of the Gigabit Ethernet
I will admit that I have been most excited about the networking on the Raspberry Pi; after the Raspberry Pi 3 Model B+ introduced its gigabit-a-like over USB 2.0, everyone has been hankering for true gigabit ethernet. Although the adapter is called gigabit, you can actually expect speeds of 125 megaBYTEs per second in ideal conditions.
The speed of the ability to transfer over gigabit ethernet is also restricted by the speed of the hardware you are transferring to and from, and the capability of the speed of the cable between the hardware involved in between the Raspberry Pi and the source of the data.
In the transfer tests, I had to save a file from a File Transfer Protocol (FTP) server to the Raspberry Pi onto different devices, I used a Solid State Disk connected via USB 3.0, a USB Pen Drive which boasted 'high write speeds' that supports USB 3.1, and also saving to the microSD card in the Raspberry Pi itself, this SDCard being a Sandisk Edge HC U 1.
I did not benchmark transferring files from the Raspberry Pi to the FTP server; however, I did transfer files from the Raspberry Pi and read speeds are definitely faster than write speeds with this hardware and start saturating the gigabit ethernet a lot more.
You can see how I set up this scenario in my past benchmark A Comprehensive Raspberry Pi 3 Model B Plus Benchmark under the sections "Testing Network Throughput" and "Setting up the Tests".
The Raspberry Pi 4 has seen a change in the wireless LAN, and to many it is a subtle one. The antennas on previous models were either ceramic or a trace on the board. Now we are seeing a new design of antenna, and I believe it is having an effect on WiFi throughput and connectivity. At 2.4Ghz the WiFi adapter connected at 54mbps, so we are seeing speeds we would expect in the file transfer, though compared to the Pi 3 Model B+ we are seeing improved write speeds to the SDCard that are similar to the SSD, so the limiting factor there is now the 802.11g wireless LAN standard.
Raspberry Pi Zero W On-board Antenna
Raspberry Pi 4 Model B On-board Antenna
5Ghz data transfers have really suffered, only connecting at 180mbps (out of a maximum 300mbps); the write speeds are generally good when writing to the USB 3.0 SSD device as opposed to the SDCard, and as clever as the on-board antenna is that was introduced with the Raspberry Pi Zero, I think we should return to the one used on the Raspberry Pi 3 B+, as here are the transfer speeds for comparison:
What about Ethernet?
There you go. If you are using the Raspberry Pi 4 Model B as a network attached storage, you will want to get yourself a USB 3.0 device that has a high or fast write speed, as well as a high/fast read speed. Although the SSD I was using was rated up to 400mbps, the interface to it certainly was not up to the task, and it was actually the USB 3.1 pen drive that was maxed out at 400mbps write speed. You will have to take my word for it that the read speeds really were not a problem.
SDCard is still a lynch pin, if that is all you are relying on for your storage you are really not going to take advantage of the fast new connectivity, even if you are using it via wireless LAN. So you may want to consider booting entirely from USB and running your operating system from it with SDCard as a safety fall back.
Now, what is the fastest USB 3.0 device for write speed? Let me know in the comments!
Something odd with USB Ethernet
As part of previous tests I compared the on-board ethernet controller with one attached via USB. This USB attached ethernet adapter is USB 3.0 and rated at gigabit ethernet speeds, and in fact it performed better than the on-board ethernet because the USB 2.0 bus was faster than ethernet over USB 2.0.
This device is a TRENDnet TU3-ETG/EUNL v1.0R.
It is pretty well known, and in previous versions of Raspbian, it has worked well and has been well supported. However, something has changed, so although I have a category 5e rated cable, which works at gigabit speeds, I could not get faster than 100mbps speeds from it. I thought it might have been because I was transferring data through the VIA chip from USB 3.0 ethernet to USB 3.0 storage, however the speed limit was experienced directly to the SDCard as well, so this cannot be the case.
In the chart (which I used to create the graphs from above) we can see the significant difference in speeds: every test for USB to <x> is under the amount we would expect, while on-board to <x> are around the speeds we would expect, and they max out the write speeds of the hardware.
Hopefully, when Raspbian is updated in the future, perhaps this adapter will start working again at its full speeds, but for now on the Pi 4 it is relegated to 100mbps throughput, which is a shame if you choose to use your device as a gigabit throughput proxy server or firewall in your network, as it will quickly become the bottleneck.
Seriously, Keep this Cool and in a Case
In 2016 element14 Community member bwelsby put together a design for a 3D printed case for the Raspberry Pi. This design is intended to put the hardware through its paces when running the application 'stress' which puts the processor under an arbitrary load for the purpose of 'stress testing,' and in this instance it is being used to test the thermal properties and throttling of the Raspberry Pi.
The 3D printed case, in combination with heatsinks situated on the necessary chips on the board, and fans attached to the case, give a great baseline for checking the temperature and processor speed on each second that has passed in the test.
It has been a long held belief with the Raspberry Pi hardware that you can 'just run it without a heatsink or fan' and it will 'just work.' To some extent this is entirely true, but it is not without consequences. Just as you now require a suitable and beefy power supply, rather than running the hardware from a USB port belonging to a laptop, to maintain that sweet, sweet 1.5Ghz processor speed, you need to consider adequate cooling. Furthermore, you also need to consider cooling if you're going to enclose the Raspberry Pi in a case, and this is even the advisement in the documents from Raspberry Pi Trading.
If you are using the Raspberry Pi without a case, here is an example of the temperature you can expect when the hardware is at room temperature after being powered down. The alignment is slightly off because the camera can only align properly at about 1 metre:
The high temperatures here are false reflections on the metal connectors from my body heat and other sources, the actual temperature of the board is more towards the 22-24 deg C range as denoted by the colour variations.
Now with the hardware idle in Raspbian:
A mere 49.9 deg C, though one fact we know is that when the hardware is not under load, it scales back the processing speed to 600Mhz. So what does it look like under load when the processor is busy?
You can see previous thermal images at A Comprehensive Raspberry Pi 3 Model B Plus Benchmark
The board certainly heats up, the white spot is supposed to be in line with the central processor at 75.7 deg C, though this is the external temperature, and it is having to go through a piece of appropriate tape tacked onto the processor chip because the emissivity of the metal will otherwise just reflect any heat source nearby into the thermal camera instead of from the source. Now, this isn't the temperature the chip internally is experiencing, and we can go into detail to see what that is like.
Taking photographs of my screen is not something I make a habit of, but I did not want to interrupt the benchmarking for it to take a print of the screen - if you do not provide adequate cooling, then you are going to start seeing this symbol appear in the top right of your screen:
This symbol means that the hardware has reached its ideal limit, and it will have to start employing 'thermal throttling,' which is where the speed of the computer will be slowed down in an attempt to keep it cool and functional. This starts to happen between 81 deg C and 83 deg C.
Results of the Thermal Testing
After about two and a half minutes of heavy processor load, without even pushing the network or graphics processor, we started to see the Raspberry Pi throttle the processor speed, dropping from 1.5Ghz to 1.0Ghz, a loss of 500Mhz speed. We can see what kind of effect this does have on the VideoCore in the following screenshot, where we are also transferring files and doing a brief test with glxgears:
This speed loss set itself in place after about four and a half minutes, where we begin to see the next 'fight' in speed decrease, the speed now starts dropping from 1Ghz to 700Mhz - and it is not long until after seven minutes we see the drop down to 600Mhz.
So what we're seeing is that, after a solid 7 minutes where the Raspberry Pi 4 Model B is situated in a case, without a fan or heatsink, to protect itself the device slows itself down to the speed of a Raspberry Pi 1 Model B+. While there will still be some performance benefit, we are talking about a four core processor after all, we are losing out on over 900Mhz of performance per processor core.
Time to Cool Off
After 3D printing the case, I wanted to use some pretty good thermal paste and heatsinks, I have used these before for my tests, and they claim to be industrial diamond thermal compound and heatsinks - apparently diamond has better thermal properties due to its structure than aluminium (so no silver paste here).
After installing a rather neat and small processor fan that runs from the 5v line, and the heatsink and thermal compound, I am ready to run the stress tests again.
Some slight modification to the 3D print was necessary due to the form factor change of the Raspberry Pi, and also moving the fan into place did not go without minor incident, still, this should be fine.
It is like a night and day difference, the temperature of the processor maintains a steady 50-55 deg C and the processor speed is a solid 1.5Ghz.
You might be wondering what the drop off is at the end of the graph; this is because the Raspberry Pi idles at 600Mhz and only increases its processor speed when it is instructed to perform an intensive task, so this means that the board only uses as much power as it needs to, when it needs to, so we see a drop off at 600Mhz when the test is done.
Now I wondered: how much help the heatsink was actually providing to these tests, so I cleaned up the processor and ran the test with only a fan:
We still see a solid performance from the processor, so we are not hitting the thermal limit before throttling occurs, however we are now running 10 degrees hotter at about 60-65 deg C, and frankly there was a smell from the warm electronics in the case.
If you are going to enclose your Raspberry Pi, or frankly even if you are not, I would highly recommend having active cooling on your board at the bare minimum. Having a heatsink on the board is going to make the hardware happier and live longer, especially with the 28nm manufacturing process that is now used.
Raspberry Pi 4 Model B - The Network Attached Storage you asked for
I would say that the Raspberry Pi is finally 'there;' it is the powerful little computer that was first released to the world in 2011, and now 8 years later has picked up the pace to be a suitable replacement for your desktop computer. At 4k resolution desktop, a graphics processor that can decode 4k 60fps h265 video and resolutions below, with gigabit ethernet and wireless LAN connectivity that will get you on the internet at reasonable speeds everywhere, we are now actually waiting for the write speeds of storage to catch up.
That is funny, waiting on something to catch up to the Raspberry Pi!
Whether it is for multimedia in the home running Kodi / OpenELEC or you are using it as a Steam Link - I think you will be hard pushed to be disappointed with Raspberry Pi Trading's new offering.
Just make sure you are keeping it cool to get the most out of it.
Any questions? Let us know in the comments below. Want to see more benchmarks from the Raspberry Pi? Is there something I should have done differently? Or would you rather see them all in the same place? Let me know!
If you want to find out more about the Raspberry Pi 4, be sure to check the links at the top of the document!
Thanks for reading.