Raspberry Pi 4 has just been released with many improvements over Raspberry Pi 3 Model B+ including a faster processor, a proper Gigabit Ethernet port, USB 3.0 interfaces, and 4K video support. That’s the theory, but how does it work in practice?
I can now let you know as I’ve received a Raspberry Pi 4 sample courtesy of Cytron, and ran some tests and benchmarks on the very latest boards from the Raspberry Pi foundation.
System Info
Before starting with the benchmarks, let’s go through some basic system info:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
pi@raspberrypi:~ $ cat /etc/issue Raspbian GNU/Linux 10 \n \l pi@raspberrypi:~ $ uname -a Linux raspberrypi 4.19.46-v7l+ #866 SMP Fri Jun 7 18:00:39 BST 2019 armv7l GNU/Linux pi@raspberrypi:~ $ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 13G 4.7G 7.4G 39% / devtmpfs 334M 0 334M 0% /dev tmpfs 463M 0 463M 0% /dev/shm tmpfs 463M 6.4M 456M 2% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 463M 0 463M 0% /sys/fs/cgroup /dev/mmcblk0p6 253M 40M 213M 16% /boot tmpfs 93M 0 93M 0% /run/user/1000 /dev/sda4 200G 175G 24G 89% /media/pi/USB3_BTRFS /dev/sda2 241G 181G 48G 80% /media/pi/USB3_EXT4 /dev/sda1 245G 182G 63G 75% /media/pi/USB3_NTFS pi@raspberrypi:~ $ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 270.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 .... processor : 3 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 270.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 Hardware : BCM2835 Revision : a03111 Serial : 00000000ea51204b |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
$ inxi -Fc0 System: Host: raspberrypi Kernel: 4.19.46-v7l+ armv7l bits: 32 Console: tty 1 Distro: Raspbian GNU/Linux 10 (buster) Machine: Type: ARM Device System: Raspberry Pi 4 Model B Rev 1.1 details: BCM2835 rev: a03111 serial: 00000000ea51204b CPU: Topology: Quad Core model: ARMv7 v7l variant: cortex-a72 bits: 32 type: MCP Speed: 1500 MHz min/max: 600/1500 MHz Core speeds (MHz): 1: 1500 2: 1500 3: 1500 4: 1500 Graphics: Device-1: bcm2835-vc4 driver: vc4_drm v: N/A Device-2: bcm2835-hdmi driver: N/A Display: tty server: X.org 1.20.4 driver: modesetting unloaded: fbdev tty: 80x24 Message: Advanced graphics data unavailable in console. Try -G --display Audio: Device-1: bcm2835-audio driver: bcm2835_audio Device-2: bcm2835-hdmi driver: N/A Sound Server: ALSA v: k4.19.46-v7l+ Network: Message: No ARM data found for this feature. IF-ID-1: eth0 state: up speed: 1000 Mbps duplex: full mac: dc:a6:32:00:9e:9c IF-ID-2: wlan0 state: up mac: dc:a6:32:00:9e:9d Drives: Local Storage: total: 946.35 GiB used: 540.58 GiB (57.1%) ID-1: /dev/mmcblk0 vendor: SanDisk model: SL16G size: 14.84 GiB ID-2: /dev/sda type: USB vendor: Seagate model: Expansion size: 931.51 GiB Partition: ID-1: / size: 12.68 GiB used: 4.71 GiB (37.1%) fs: ext4 dev: /dev/mmcblk0p7 ID-2: /boot size: 252.0 MiB used: 39.3 MiB (15.6%) fs: vfat dev: /dev/mmcblk0p6 Sensors: Message: No sensors data was found. Is sensors configured? Info: Processes: 179 Uptime: 4h 37m Memory: 1000.5 MiB used: 324.1 MiB (32.4%) gpu: 76.0 MiB Init: systemd runlevel: 5 Shell: bash inxi: 3.0.32 |
For reference, you’ll find Raspberry Pi 4 Linux boot log here.
Phoronix benchmarks
Let’s go ahead and install the latest version of Phoronix benchmarks:
|
1 2 3 |
sudo apt install php-cli php-gd php-xml php-zip wget http://phoronix-test-suite.com/releases/repo/pts.debian/files/phoronix-test-suite_8.8.1_all.deb sudo dpkg -i phoronix-test-suite_8.8.1_all.deb |
Now let’s run the test to compare the performance of Raspberry Pi 4 model B to some other Arm Linux boards including Raspberry Pi 3 Model B.
|
1 |
phoronix-test-suite benchmark 1709271-TY-1704029RI26 |
For reference, my office has an ambient temperature of around 28 to 30°C, and I’ve monitored the CPU temperature with an IR thermometer during some of the phases:
- Idle – 62°C
- Phoronix benchmarks download/installation – 64°C
- John The Ripper – 73°C
I also typed a few commands to get the system temperature and CPU clock, in this case during John the Ripper benchmark:
|
1 2 3 4 |
pi@raspberrypi:~ $ /opt/vc/bin/vcgencmd measure_temp temp=85.0'C pi@raspberrypi:~ $ /opt/vc/bin/vcgencmd measure_clock arm frequency(48)=1000265600 |
So the CPU is clocked down to around 1.0 GHz since proper cooling is not implemented for this type of workload, and the system automatically lowers the CPU frequency.
Another way to confirm throttling does occur is to check out the output of Phoronix John The Ripper:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
Test: Blowfish: 696 621 536 561 558 574 554 558 545 482 500 494 491 443 472 |
The test is repeated several times, with the score starting at 696, and eventually dropping under 500, as the board fails to cool.
This behavior is actually explained in the board’s datasheet:
To reduce thermal output when idling or under light load, the Pi4B reduces the CPU clock speed and voltage. During heavier load the speed and voltage (and hence thermal output) are increased. The
internal governor will throttle back both the CPU speed and voltage to make sure the CPU temperature never exceeds 85 degrees C.The Pi4B will operate perfectly well without any extra cooling and is designed for sprint performance – expecting a light use case on average and ramping up the CPU speed when needed (e.g. when loading a webpage). If a user wishes to load the system continually or operate it at a high temperature at full performance, further cooling may be needed.
We do not have a cooling solution at hand here, so running the benchmarks without heatsink, nor fan does seriously impact the performance under load, meaning Raspberry Pi 4 is slower than Raspberry Pi 3 model B in some of the benchmarks.
John the Ripper is a shocker since my Raspberry Pi 4 is actually slower than a Raspberry Pi 3 model B tested by others due to the lack of proper cooling for the multi-threaded benchmark.
C-Ray looks better since RPi 4 is about 27% faster than RPi 3 model B (187.03s vs 250.79s), but still twice as slow as Rockchip RK3399 powered VS-RK3399 board.
Raspberry Pi 4 performance also looks better with Smallpt illumination renderer benchmark.
The board is however much much faster with Himeno Poisson solver benchmark, almost 5 times faster than RPi 3 model B, so there may have been some software/compilation changes in this Phoronix benchmark, or possibly there are some extra instructions that come with Cortex-A72 cores, since the Rockchip RK3399 hexa-core processor with 2x A72 + 4x A53 is also quite faster than other A53/A7 Arm platforms.
AFAIK, FLAC Audio encoding is a single-core benchmark so it’s not quite as susceptible to overheating as other multi-threaded benchmarks, and Raspberry Pi 4 did perform well.
We can see from Raspberry Pi 4 benchmarks that the board is quite faster than Raspberry Pi 3 model B in most cases, but it’s also clear that to leverage the full power of the board, especially for multi-threaded tasks, a proper cooling solution is needed. You can check out the full results here.
SBC Bench
SBC Bench is a simple benchmark for single board computers developed by Thomas Kaiser that allows checking the performance of SBC quite faster than running Phoronix benchmarks.
|
1 2 |
wget https://raw.githubusercontent.com/ThomasKaiser/sbc-bench/master/sbc-bench.sh sudo /bin/bash ./sbc-bench.sh -c |
That’s the output which confirms throttling does occur:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
sbc-bench v0.6.7 Installing needed tools. This may take some time... Done. Checking cpufreq OPP... Done. Executing tinymembench. This will take a long time... Done. Executing OpenSSL benchmark. This will take 3 minutes... Done. Executing 7-zip benchmark. This will take a long time..../sbc-bench.sh: line 600: 3795 Killed taskset -c 0 "${SevenZip}" b -mmt 1 >> ${TempLog} ./sbc-bench.sh: line 600: 3963 Killed "${SevenZip}" b >> ${TempLog} Done. Checking cpufreq OPP... Done. ATTENTION: Throttling and frequency capping has occurred. Check the log for details. Memory performance: memcpy: 2583.7 MB/s (0.5%) memset: 3434.2 MB/s (0.5%) 7-zip total scores (3 consecutive runs): 3586,3550 OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 62570.05k 76593.98k 83103.91k 84647.59k 85267.80k 85120.34k aes-128-cbc 55480.44k 73520.90k 82036.48k 84438.02k 85032.96k 84972.89k aes-192-cbc 56285.33k 67360.75k 71948.54k 73276.76k 73512.28k 73531.39k aes-192-cbc 56282.36k 67388.65k 71970.22k 73076.05k 73613.31k 73525.93k aes-256-cbc 50946.77k 60065.37k 63566.34k 64609.62k 64891.56k 64902.49k aes-256-cbc 50878.17k 60053.57k 63672.75k 64565.59k 64937.98k 64946.18k Full results uploaded to http://ix.io/1MFA. Please check the log for anomalies (e.g. swapping or throttling happened) and otherwise share this URL. |
Checking into the details in the link, we can see for example the CPU dropped to 1.0 GHz for most of 7-zip multi-threaded tests, dropping even as low as 600 MHz once. 7-zip crashed so we only got two results instead of three. That’s Raspberry Pi 3 model B result for reference:
|
1 |
7-zip total scores (3 consecutive runs): 3313,3285,3050 |
So RPi 4 is barely faster at just under 3,600, but proper cooling should improve things.
OpenSSL AES results look like Armv8 crypto extension are not enabled, as an Allwinner H5 based Orange Pi Zero Plus board underclocked at just 816 MHz is considerably (up to around 8 times) faster:
|
1 2 3 4 5 |
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 102568.41k 274205.76k 458456.23k 569923.58k 613422.42k aes-192-cbc 95781.66k 235775.72k 366295.72k 435745.79k 461294.25k aes-256-cbc 91725.44k 211677.08k 313433.77k 362907.31k 380482.90k |
Checking out /proc/cpuinfo above, AES feature is missing, so it might be Broadcom did not include Armv8 crypto extension in the processor (TBC).
USB 3.0 & microSD Storage Benchmarks
Since Raspberry Pi 4 now comes with two USB 3.0 ports, I’ve connected USB 3.0 mechanical hard drive, and installed iozone to verify Raspberry Pi can now achieve the ~100MB/s read/write speed expected from such drive.
Usually, iozone can be installed as follows in most Ubuntu/Debian systems:
|
1 |
sudo apt install iozone3 |
But it’s not available in Raspbian Buster, so I’ve built it from sources instead:
|
1 2 3 4 5 |
wget http://www.iozone.org/src/current/iozone3_487.tar tar xvf iozone3_487.tar cd iozone3_487/src/current make -j4 linux-arm sudo cp iozone /usr/local/bin/ |
We can now run the test to check sequential read and write speeds in the EXT-4 partition of my drive:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.487 $ Compiled for 32 bit mode. Build: linux-arm Run began: Mon Jun 24 20:45:40 2019 Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 22017 26219 26320 26983 518 1113 102400 16 74339 80166 85491 84292 2204 6957 102400 512 92358 91388 94616 96972 35399 53793 102400 1024 92372 92300 96088 97583 53058 66673 102400 16384 92204 92644 94833 96150 88518 89131 iozone test complete. |
So around 94MB/s read and 92 MB/s write that’s about what we should expect from USB 3.0 with this drive, and much better than the 30+MB/S one would get with Raspberry Pi 3.
While I’m at it, I’ve also tested the performance of the NOOBS Class A1 microSD card part of the kit I received:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.487 $ Compiled for 32 bit mode. Build: linux-arm Run began: Mon Jun 24 20:52:50 2019 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 3738 4573 10511 10507 7984 4603 102400 16 6949 12131 23774 23768 20344 11188 102400 512 16940 35841 43994 43995 43675 26330 102400 1024 29274 36396 44371 44371 44243 30636 102400 16384 28914 33645 44531 44530 44525 27945 |
The most important numbers here are the random read and write values, and results are good resulting in a smooth experience while using the board (in most cases).
Gigabit Ethernet Benchmark
True Gigabit Ethernet is another key feature of the new Raspberry Pi port, so I’ve tested full duplex Ethernet performance using iperf:
|
1 2 |
sudo apt install iperf iperf -t 60 -c 192.168.1.4 -d |
It ended badly on the client side:
|
1 2 3 4 5 6 |
Client connecting to 192.168.1.4, TCP port 5001 TCP window size: 122 KByte (default) ------------------------------------------------------------ [ 4] local 192.168.1.10 port 37782 connected with 192.168.1.4 port 5001 [ 5] local 192.168.1.10 port 5001 connected with 192.168.1.4 port 56156 Segmentation fault |
But I got some numbers on the server (my laptop) side:
|
1 2 3 4 5 6 7 8 |
Client connecting to 192.168.1.10, TCP port 5001 TCP window size: 153 KByte (default) ------------------------------------------------------------ [ 6] local 192.168.1.4 port 56150 connected with 192.168.1.10 port 5001 [ ID] Interval Transfer Bandwidth [ 6] 0.0-60.0 sec 2.22 GBytes 318 Mbits/sec [ 4] 0.0-60.0 sec 233 MBytes 32.5 Mbits/sec [ 4] local 192.168.1.4 port 5001 connected with 192.168.1.10 port 37782 |
I repeated the test twice with similar results. It does not look so good, so let’s repeat the test in one direction only:
- Upload
|
1 2 3 4 5 6 7 8 |
iperf -t 60 -c 192.168.1.4 ------------------------------------------------------------ Client connecting to 192.168.1.4, TCP port 5001 TCP window size: 43.8 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.10 port 37784 connected with 192.168.1.4 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-60.0 sec 6.32 GBytes 905 Mbits/sec |
- Download
|
1 2 3 4 5 6 7 8 |
iperf -t 60 -c 192.168.1.10 ------------------------------------------------------------ Client connecting to 192.168.1.10, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.4 port 56196 connected with 192.168.1.10 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-60.0 sec 6.50 GBytes 931 Mbits/sec |
So it looks much better here, as the full bandwidth enabled by Gigabit Ethernet is basically saturated by both tests. The driver may have troubles handling high download/upload traffic at the same time in the first test.
4K Video Playback and Output
All previous Raspberry Pi boards were limited to 1080p30/60 video playback with H.264 and other codecs, but Raspberry Pi 4 is the first to play 4K videos using H.265 codec.
So I went back to the desktop to play some 4K H.265 videos played from my USB drive. Clicking on the files opened then in VLC media player:
- Beauty_3840x2160_120fps_420_8bit_HEVC_MP4.mp4 (H.265) – First frame only
- MHD_2013_2160p_ShowReel_R_9000f_24fps_RMN_QP23_10b.mkv (10-bit HEVC, 24 fps) – First frame only for several seconds then video becomes gray, and system hangs
- Fifa_WorldCup2014_Uruguay-Colombia_4K-x265.mp4 (4K, H.265, 60 fps) – First frame only for several seconds then video updates every 5-10 seconds with heavily gray frames, and frequent audio cuts. Eventually, lost mouse pointer and control of the system -> hard power cycle required
OK, so I guess I can stop right here, as 4K video playback is clearly not working, at least with VLC. So I tried to omxplayer command line:
|
1 2 3 4 5 6 7 8 |
pi@raspberrypi:~ $ omxplayer /media/pi/USB3_NTFS/Video_Samples/4K/Fifa_WorldCup2014_Uruguay-Colombia_4K-x265.mp4 Vcodec id unknown: ad tvservice-client: [tvservice_send_command] not sending invalid command -2147483637 have a nice day ;) pi@raspberrypi:~ $ omxplayer /media/pi/USB3_NTFS/Video_Samples/4K/Beauty_3840x2160_120fps_420_8bit_HEVC_MP4.mp4 Vcodec id unknown: ad tvservice-client: [tvservice_send_command] not sending invalid command -2147483637 have a nice day ;) |
Let’s switch to 4K video output. There’s an option in the settings and if you planned on using a dual display setup, you can also configure the screen layout as needed.
So I selected 4K HDMI, clicked on OK, and was told I needed to reboot to apply the new settings. Fair enough, and after the 35 seconds it typically takes to boot the board I was back in the desktop environment, but still at 1080p60 video output & resolution. For reference, my TV is LG 42UB820T which perfectly supports 4K video output. I did, however, connect it through Onkyo TX-NR636 A/V receiver which should not be a problem, but in case of compatibility issues, I connected the RPi 4 directly to the HDMI 3 of my TV and rebooted the board. But sadly same results.
So right now, Raspberry Pi 4 only has the potential to use 4K video decode and output, as it’s just not working right now, at least in the Raspbian image I was provided with the NOOBS microSD card.
Final words
The Raspberry Pi 4 does provide much better I/O performance thanks to Gigabit Ethernet and USB 3.0 both of which are mostly performing as expected. The processor is also quite faster, but you may have to come up with a cooling solution such as Pimoroni Fan SHIM to leverage it’s full potential, especially if you live in a hot climate. 4K does not work at all right now, with 4K video playback clearly relying on software decode with both VLC and omxplayer, and 4K video output is not working at least with my 4K TV.
The Raspberry Pi 4 hardware changes mean you’ll need some extra accessories, and Cytron sent me the Raspberry Pi 4 together with the official 5V/3A USB-C power supply, as well as a micro HDMI cable, and a 16GB NOOBS Class A1 microSD card. So make sure you get at least the first two accessories in your order or you may not be able to use the Raspberry Pi 4 for a while.
I’d like to thank Cytron for the opportunity of getting a Raspberry Pi 4 so early, and you could consider purchasing the board from their store. They ship worldwide, but if you’d rather get the 2GB or 4GB RAM models you’ll have to wait a little longer, as those are not quite available yet.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
