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
Them thermals..
Not quite hot enough for frying an egg on though…
An RK-3399, Atom, the Tegra, etc. are beasts in that regard as well. Unless you’re talking a RISC-V core set that’s comparable, you’re going to have these levels for this class of performance.
I was referring to the dissipation provisioning, or lack thereof. I’m perfectly aware what temps CA72 does at 28nm, ergo my first post in the announcement thread.
Just a suggestion, try iperf3 instead of iperf, it’s the most up to date variant and seems to work much better.
Also, is it possible that 4K video playback require more than 1GB of RAM?
Last time I tried there was no option for full duplex anymore.
You’re correct, but iperf2 does that at least.
Few remarks: 1) sbc-bench reports you’re running an outdated primary OS: Jun 7 2019 18:01:29 Copyright (c) 2012 Broadcom version b5cfeb0a81046c23b73eb41dab3745fcf0601247 (clean) (release) (start) 123 Jun 7 2019 18:01:29 Copyright (c) 2012 Broadcomversion b5cfeb0a81046c23b73eb41dab3745fcf0601247 (clean) (release) (start) You should upgrade to at least version 407b1da8fa3d1a7108cb1d250f5064a3420d2b7d from last Thursday. 2) sbc-bench also reported frequency capping so you’re affected by undervoltage (or the ThreadX release has problems): Querying ThreadX on RPi for thermal or undervoltage issues: 1100000000000000010 ||| |||_ under-voltage ||| ||_ currently throttled ||| |_ arm frequency capped |||_ under-voltage has occurred since last reboot ||_ throttling has occurred since last reboot… Read more »
Here they are: pi@raspberrypi:~ $ sudo lspci 00:00.0 PCI bridge: Broadcom Limited Device 2711 (rev 10) 01:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host Controller (rev 01) pi@raspberrypi:~ $ lsusb Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 0bc2:2312 Seagate RSS LLC Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 1a2c:0002 China Resource Semico Co., Ltd Bus 001 Device 003: ID 0461:4d15 Primax Electronics, Ltd Dell Optical Mouse Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001:… Read more »
About the firmware, I went through the automatic updated, but only rebooted after running the test.
However, I can see I still have the old firmware:
Going to bed I’ll find out how to upgrade it tomorrow.
Updated firmware with rpi-update. I’ve just tried 4K again, and neither output nor decoding works: pi@raspberrypi:~ $ /opt/vc/bin/vcgencmd version Jun 24 2019 20:53:43 Copyright (c) 2012 Broadcom version 39b2ae90606289b2b5d8ffba51f238892711eb4e (clean) (release) (start) pi@raspberrypi:~ $ uname -a Linux raspberrypi 4.19.55-v7l+ #905 SMP Mon Jun 24 20:52:10 BST 2019 armv7l GNU/Linux pi@raspberrypi:~ $ omxplayer /media/pi/USB3_NTFS/Video_Samples/4K/Fifa_WorldCup2014_Uruguay-Colombia_4K-x265.mp4 Vcodec id unknown: ad have a nice day ;) 123456789 pi@raspberrypi:~ $ /opt/vc/bin/vcgencmd versionJun 24 2019 20:53:43 Copyright (c) 2012 Broadcomversion 39b2ae90606289b2b5d8ffba51f238892711eb4e (clean) (release) (start)pi@raspberrypi:~ $ uname -aLinux raspberrypi 4.19.55-v7l+ #905 SMP Mon Jun 24 20:52:10 BST 2019 armv7l GNU/Linuxpi@raspberrypi:~ $ omxplayer /media/pi/USB3_NTFS/Video_Samples/4K/Fifa_WorldCup2014_Uruguay-Colombia_4K-x265.mp4 Vcodec id unknown: adhave… Read more »
It’s not undervoltage; it’s throttling due to insufficient cooling for extensive activity, like benchmarks. The bitmask shows this clearly by having an 0 for under-voltage and a 1 for currently throttled.
Simply look again. I was talking about the bits on the left that report behavior since last boot: Querying ThreadX on RPi for thermal or undervoltage issues: 1100000000000000010 ||| |||_ under-voltage ||| ||_ currently throttled ||| |_ arm frequency capped |||_ under-voltage has occurred since last reboot ||_ throttling has occurred since last reboot |_ arm frequency capped has occurred since last reboot 123456789 Querying ThreadX on RPi for thermal or undervoltage issues: 1100000000000000010||| |||_ under-voltage||| ||_ currently throttled||| |_ arm frequency capped|||_ under-voltage has occurred since last reboot||_ throttling has occurred since last reboot|_ arm frequency capped has occurred… Read more »
oops, 9,8,7 110 not 111, easy to mistake it as ascii drawing is still to 8bit, we need a real consistant cli gfx in the shell scripting in 2020… whats available on git we might use.
whats wrong with that
graphics:
Device-1: bcm2835-vc4 driver: vc4_drm v: N/A
Device-2: bcm2835-hdmi driver: N/A
didnt they include them or get a working copy in time for benches,did it effect the video non playing i wonder as a side effect…
https://wiki.gentoo.org/wiki/Raspberry_Pi_VC4 Using the “VC4” driver on the raspberry pi to enable hardware acceleration (in X, Wayland, opengl applications) presents many challenges. There’s plenty of instructions floating around for Raspbian, but for Gentoo, not so much. This page contains a couple of nuggets of wisdom that may help you get there. …Kernel To have proper GPU acceleration with VideoCore, you need its kernel module loaded. That module has been integrated in v4.5, but it’s also present in rpi’s kernel v4.4. To get VC4 core working you need to use latest firmware from sys-boot/raspberrypi-firmware 9999 ebild. To have installed only firmware files… Read more »
Have you enabled 4K video in the config.txt file? I believe that is necessary at the moment to enable 4K output. However you don’t need 4K output to check 4K decode do you?
hdmi_enable_4k=1 (This is for 4K60 at least)
https://forum.libreelec.tv/thread/17698-libreelec-leia-9-2-alpha1-with-raspberry-pi-4b-support/?postID=121496#post121496
The setting menu in LXDE does just that. That’s the content of my config.txt: # For more options and information see # http://rpf.io/configtxt # Some settings may impact device functionality. See link above for details # uncomment if you get no picture on HDMI for a default "safe" mode #hdmi_safe=1 # uncomment this if your display has a black border of unused pixels visible # and your display can output without overscan #disable_overscan=1 # uncomment the following to adjust overscan. Use positive numbers if console # goes off screen, and negative if there is too much border #overscan_left=16 #overscan_right=16 #overscan_top=16… Read more »
Ah – OK – that makes sense. Also I wonder whether all flavours of HDMI 4K are handled – I’d hope 4:2:0 was as that’s a pretty much guaranteed baseline that all HDMI 2.0 4K displays should support (and is HDMI 1.4b bandwidth compatible) However 4:2:2 and 4:4:4 would be better for desktop use (4:4:4 ideally)
Just about working on LibreElec alpha test video, but still buggy.
I added both RPi 4 and VIM3 numbers to sbc-bench results list: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md
But I took the RPi 4 results generated by German c’t magazine since on their install overheating wasn’t that massive and they run with a newer ThreadX release. The good news: if you want a fast performing ARM device, choose VIM3 instead! 🙂
Something’s telling me there might be faster arm devices out there, depending on workloads ; )
My benchmark scores are often lower than other reviewers since my room temperature is usually higher.
Only drawbacks on some of these benchmarks…some of them highlight a single core’s performance, not the device’s workload over all four cores.
When you have the RK-3399, with a dual core A72 “big” coreplex set, beating a QUADCORE one…the benchmark is valid but should be taken with a block of salt for making real-world comparisons there. At clock, single and dual threaded tasks will be faster on the RK-3399. Spread out over multiple cores, a quad threaded task will see the quadcore being faster.
I’ve tested one RK3399 device that wasnt throttling and both these things happened:
– Heterogeneous kernel scheduler was working great.
– Compiling code w/ the six cores yielded a 50% reduction in compile time.
So yes, because the RK3399 was clocked faster, it can beat a quad A72 if you also make use of the A53 cores.
It also helps if the quad core has huge thermal issue when you load down the cores with actual work.
I wonder how much of a performance / benchmark improvement an RPI4 with 4GB of RAM will have over an RPI4 with 1GB of RAM
Why?
Unless the benchmark or ‘application’ in question needs more than 1 GB RAM and as such the system needs to swap why should be there a reason for more RAM increasing performance?
You might see a drop in performance if the system has not enough RAM (and as such swap involves heavy IO activity or zram/zswap starts to eat up CPU cycles) but there is no reason why more RAM should be ‘better’ otherwise.
More RAM modules could provide more parallel memory channels? Upton must have considered that since it’s standard stuff in low power (“Allwinner”) devices as well.
> More RAM modules could provide more parallel memory channels?
Is this true with LPDDR? I’ve never encountered an LPDDR equipped SBC so far with more than one DRAM chip.
With DDR3 I believe it can make a difference since boards with 2 or more DDR3 modules operated in dual-channel mode while those with just one DDR3 module were forced to slower single-channel mode. But I’m a total hardware noob.
Rockpro 64 is using two LPDDR4 chips (two 32-bit channels).
There are also at least two arm chromebooks with dual-channel LPDDR3 on the market.
Right, but where’s the difference between 2 x 32-bit LPDDR and 1 x 64-bit LPDDR as on Renegade Elite?
https://www.cnx-software.com/2018/06/24/odroid-n1-canceled-due-to-ram-supply-issues-odroid-n2-coming-later-this-year/#comment-554505
I don’t expect RPi4 to show any RAM performance difference with higher RAM configs — the number of channels seems set, as there are no RAM isles on the back of the board.
It really depends on the memory controller’s capabilities. In practice Some can pipeline multiple accesses over the same bus using the chip select lines so that while a DRAM chip is waiting for data to be ready, another read can be engaged with another chip. In practice I’ve never seen a controller do that in any ARM CPU, even higher end ones such as Armada 8040. On x86 I’ve observed up to 4 parallel prefetches on a dual-channel, 4-DIMM machine.
willy, are you sure those were actually carried out in parallel and not just buffered? While a chip-select should not be able to increase the theoretical BW of the channel, it might be able to improve the channel saturation. At the end of the day it’s about sustained percentage of channel BW.
Rockpi4
Perhaps the HDMI output (or the software) doesn’t support 4:2:0 mode, as your TV doesn’t do 4K in 4:4:4.
Jean-Luc, once you manage to get a 4K output, could you compare memory demanding benchmarks (like 7zip and tinymembench) at different resolutions? I’m curious to see what influence the framebuffer refresh has on the CPU.
I’ve been running the benchmarks in an SSH window with the display just outputting black since the Raspberry Pi appears to turn the display black (HDMI still on) when there’s no keyboard or mouse activity for a while. So I’d assume no framebuffer refresh occur during benchmarks.
Thank you. I don’t know if there is a setting in the Rpi boot config to turn the display off entirely–like there is for most ODROID boards. Hmm, there’s “hdmi_blanking” which when set to 1 will disable HDMI instead of blanking it. Not sure if that shuts down the scanout part of the display pathway. I don’t see any other settings to disable video out.
Before:
After:
Nope, now tried again after using
/usr/bin/tvservice -p --> Powering on HDMI with preferred settingsI did a reboot in between and updated packages before so maybe new ‘firmware’ kicked in.
I’m now even more confused, Thomas! 🙂
Switching HDMI on/off via tvservice did NOT change anything about tinymembench results. I tested it twice later with reboots in between. So the result variation above might be due to different ThreadX versions or whatever. Don’t know.
I’ve been reading and it looks like “vcgencmd display_power 0” is what you want to turn the display off. I’ll keep reading.
Nope, nevermind, that was wrong your “-o” was the right way to do it.
I’ve been asked to run one more benchmark: $ git clone https://github.com/blu/bsearch $ ./build_test_bsearch.sh gcc g++ -o test_bsearch test_bsearch.cpp -lrt -marm -mfpu=neon -ffast-math -fstrict-aliasing -fstrict-overflow -funroll-loops -fomit-frame-pointer -O3 -DNDEBUG -march=armv8-a -mtune=cortex-a72 -DCACHELINE_SIZE=64 -fpermissive $ ./test_bsearch generating search space.. verifying standard bsearch consistency.. verifying bsearch_standard consistency for size 1999.. done elapsed time: 0.801316 searching.. elapsed time: 1.733997 (10000000 repetitions over a space of 1999) average searches/s: 5767024.085116 12345678910111213 $ git clone https://github.com/blu/bsearch $ ./build_test_bsearch.sh gccg++ -o test_bsearch test_bsearch.cpp -lrt -marm -mfpu=neon -ffast-math -fstrict-aliasing -fstrict-overflow -funroll-loops -fomit-frame-pointer -O3 -DNDEBUG -march=armv8-a -mtune=cortex-a72 -DCACHELINE_SIZE=64 -fpermissive $ ./test_bsearch generating search space..verifying standard bsearch consistency..verifying bsearch_standard consistency for… Read more »
Thanks, Jean-Luc. For comparison, result from 2.1GHz CA72 in MT8173A (g++-8.1.0, aarch64):
this GPU will support 4K openGL applications? (not video, desktop X11 GLX acceleration for apps in 4k )
for example a Qt/QML 4K app.
what about a 64bit raspbian? any news?
32 bit raspbian is here to stay, because legacy boards dont support 64 bit.
Raspbian will remain 32-bit (and built for ARMv6) but at least they plan on shipping with a 64-bit kernel in the future: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=243372&start=50#p1484079
My RPi 4 arrived an hour ago. Using the Raspbian Buster Lite image I quickly checked for storage performance. With an USB3 connected Samsung EVO840 in a JMS567 enclosure (UAS capable) transfer speeds are up to 360MB/s read and 320 MB/s write: random random kB reclen write rewrite read reread read write 102400 4 22302 27249 20241 20395 20237 27021 102400 16 75679 87955 83502 83747 83282 86495 102400 512 275383 284198 304086 306688 306716 282608 102400 1024 290456 297695 325241 327736 327800 296176 102400 16384 312888 307813 359110 362559 362575 312788 1024000 16384 320656 321783 363482 364006 363931 321833… Read more »
Has anyone tested what the ampage is under full load with ethernet, usb hardrive and pheripherals running?
My idle consumption with their official USB-C PSU and an USB3 connected Samsung EVO840 in a RPi powered JMS567 enclosure with Gigabit Ethernet active is 5.2W. Switching to Fast Ethernet I’m at 4.9W (the usual difference caused by GbE PHY active or not). When running an iozone3 storage test (+300 MB/s), consumption increases by 3W to 4W, when running LanTest achieving +85MB/s NAS performance the consumption increase compared to idle is around 3W. The above numbers always include consumption of a connected SSD so only make partially sense. For me the high idle consumption is the problem. With our little… Read more »
Can I ask what command and parameters you used for iops?
The Himeno Poisson Pressure Solver is branch-heavy, so it reveals differences in branch prediction accuracy, reorder buffer efficacy, and pipeline flush cost between microarch implementations. A72 slaughters the in-order cores, and A76 will in turn slaughter A72.
Back from beergarden a quick Samba/SMB benchmark: https://forum.openmediavault.org/index.php/Thread/27710-Raspberry-pi-4-announced-better-than-3/?postID=207230#post207230
+85MB/s in both directions with beta software isn’t too bad.
With the usual tweaks applied raw network performance is nothing one could complain about: mac-tk-2018:~ tk$ iperf3 -c rpi4.local Connecting to host 192.168.83.136, port 5201 [ 5] local 192.168.83.64 port 59551 connected to 192.168.83.136 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 113 MBytes 946 Mbits/sec [ 5] 1.00-2.00 sec 112 MBytes 940 Mbits/sec [ 5] 2.00-3.00 sec 112 MBytes 940 Mbits/sec [ 5] 3.00-4.00 sec 112 MBytes 940 Mbits/sec [ 5] 4.00-5.00 sec 112 MBytes 940 Mbits/sec [ 5] 5.00-6.00 sec 112 MBytes 940 Mbits/sec [ 5] 6.00-7.00 sec 112 MBytes 940 Mbits/sec [ 5] 7.00-8.00… Read more »
Another test, this time not focused on performance but reliability. More than one USB3 drive connected to an SBC can be a real sh*t show and it seems this doesn’t change here even if the situation on the RPi 4 should be better (no USB3 hub involved, hopefully proper XHCI controller). I attached two 120 GB SSDs to the USB3 ports and created a btrfs raid1 out of them: mkfs.btrfs -f -d raid1 -m raid1 /dev/sda /dev/sdb. This ensures that both drives will be pretty busy at the same time and due to btrfs’ checksum mechanism data corruption can be… Read more »
And the good news: it was just the usual ‘USB peripherals underpowered’ drama the SBC world is full of. Now I replaced one of the two SSD with another one in an externally powered enclosure and repeated the tests with both usb-storage and uas (the latter as usual showing better performance): UAS random random kB reclen write rewrite read reread read write 102400 4 16339 17795 28667 30303 17338 17173 102400 16 53296 48270 82398 46101 57816 40547 102400 512 132077 130991 187930 190746 185211 131467 102400 1024 130464 130977 220379 246195 221023 131378 102400 16384 130178 128957 348131 358787… Read more »
So the xhci doesn’t signal the over-current condition, else there would be traces (but perhaps it just cuts power, or it doesn’t but the voltage drops).
Has there been any progress on H.265 decoding since this was published?
I’ve got a brand new Pi4b here & it won’t play 720p x265 videos in VLC. I’m looking for anything I can do to configure it better.
The recommended software is Kodi in Raspbian, or install LibreELEC if you mostly want to play videos.
I haven’t tried for a while, but I have a new Raspberry Pi 4B 8GB RAM here, so I’ll probably test video playback soon (once Raspberry Pi OS 64-bit is released).