Hello, I am going to review the Purple Pi OH boards from Wireless-Tag. The Purple Pi OH is a single-board computer (SBC) mechanically compatible with the Raspberry Pi. They are designed for personal mobile Internet devices and AIoT devices, which can be used in various applications, such as tablets, speakers with screens, and lightweight AI applications. The manufacturer sent me two models. The first model is the Purple Pi OH, which is equipped with 2GB of memory and 16GB of storage space and supports 2.4GHz Wi-Fi. The second model is the Purple Pi OH Pro, equipped with 4GB of memory and 32GB of storage space. This board supports both 2.4GHz and 5GHz Wi-Fi.
The other components of both devices are almost the same. They are powered by the Rockchip RK3566 chip, which integrates a quad-core Cortex-A55 processor up to 1.8 GHz, a Mali-G52 GPU from Arm for 3D graphics acceleration, and a neural processing unit (NPU) for artificial intelligence tasks, with processing performance up to 1 TOPS. Further specifications can be found on the manufacturer’s website.
Purple Pi OH and Purple Pi OH Pro unboxing
The parcel arrived from China in a cardboard box. Inside, the devices were packed separately in cardboard, along with the same components: the mainboard, a dual-band antenna for 2.4/5.8GHz Wi-Fi, a backup battery for the RTC, a heat sink, a debug serial port line, a USB Type-C cable, a plastic screen stand, a 7-inch MIPI camera, and a MIPI CSI OV5648 camera. After assembling and powering up the devices, I found that the operating system was already installed and they were ready to use.
Other views of the two devices.
Operating System installation
The manufacturer states that the device supports several operating systems, including Android 11, Debian 10, Ubuntu 20.04, OpenHarmony, and Kylin OS. For this review, I will install Ubuntu 20.04.
The installation guides are available on the manufacturer’s website. To install Ubuntu, you can follow the instructions provided in the ‘Purple-Pi-OH RK3566-Firmware and burning instructions’ file. The firmware image file and other burning tools are accessible on the manufacturer’s Cloud, hosted on Baidu. The URL, username, and password for downloading these files can also be found in the PDF. To burn the firmware, you will need to prepare a USB Type-C cable to connect the board to the computer. After installing the required software, such as DriverAssitant and RkDevTool on the computer, you have to put the device into Loader mode. Then, use the RkDevTool to open the image file and press the upgrade button in the software to burn the image file. For me, this OS installation process finished in a few minutes, as shown in the images below.
Even though the installation processes were easy to follow. However, I encountered some minor issues. The first one was the UI of the tools, which was in Chinese. Fortunately, this problem can be simply managed by opening the config.ini file, locating the [Language] section, and replacing Selected=1 with Selected=2. After saving the changes and reopening the software, the UI will switch to English.
The next issue I encountered was that the installation resources are hosted on the Baidu website, which requires registration before downloading the files. However, during this review, I found that the website requires a mobile phone number for account activation, and the system does not currently allow phone numbers from foreign countries to register. Therefore, I had to request the manufacturer to share the resources using another cloud provider. Eventually, they provided me with a DropBox link.
As mentioned earlier, we need to put the device into Loader mode before burning the firmware. There are two methods to enter Loader mode: by pushing the Recovery button and by using the software. In this review, I used the first method, but I encountered an issue with the Recovery button (labeled as SW1) location. According to the document (version 2022/04/06), the Recovery button should be located in the yellow rectangle of the following image (left). However, the physical location of the Recovery button is on the other side of the board, as shown in the image (right). Therefore, you may need to carefully check where the Recovery button is located before pressing it.
The overall installation process proceeded smoothly, and I successfully installed Ubuntu 20.04 (Focal Fossa) with LXQt 0.14.1. Afterward, I checked the specifications of the two devices using the inxi
command, as shown below.
System Information of Purple Pi OH
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
ido@ido:~$ inxi -Fc0 System: Host: ido Kernel: 4.19.232 aarch64 bits: 64 Desktop: LXQt 0.14.1 Distro: Ubuntu 20.04.3 LTS (Focal Fossa) Machine: Type: ARM Device System: Rockchip RK3566 Purple Pi OH-3566 V1 Board serial: c448f480018ea206 CPU: Topology: Quad Core model: N/A variant: cortex-a55 bits: 64 type: MCP Speed: 1800 MHz min/max: 408/1800 MHz Core speeds (MHz): 1: 1800 2: 1800 3: 1800 4: 1800 Graphics: Device-1: display-subsystem driver: rockchip_drm v: N/A Device-2: mali-bifrost driver: mali v: N/A Display: x11 server: X.Org 1.20.8 driver: modesetting resolution: 800x1280~60Hz OpenGL: renderer: llvmpipe (LLVM 12.0.0 128 bits) v: 4.5 Mesa 21.0.3 Audio: Device-1: simple-audio-card driver: N/A Device-2: simple-audio-card driver: asoc_simple_card Sound Server: ALSA v: k4.19.232 Network: Device-1: rk3568-gmac driver: rk_gmac_dwmac IF: eth0 state: down mac: 5a:6c:19:cf:9a:88 Device-2: wlan-platdata driver: wlan_platdata IF-ID-1: wlan0 state: up mac: e8:fb:1c:86:ea:dd Drives: Local Storage: total: 14.56 GiB used: 7.18 GiB (49.3%) ID-1: /dev/mmcblk0 model: AJTD4R size: 14.56 GiB Partition: ID-1: / size: 13.94 GiB used: 7.18 GiB (51.5%) fs: ext4 dev: /dev/mmcblk0p8 Sensors: Message: No sensors data was found. Is sensors configured? Info: Processes: 190 Uptime: 26m Memory: 1.93 GiB used: 667.5 MiB (33.8%) Shell: bash inxi: 3.0.38 |
System Information of the Pro board
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
System: Host: ido Kernel: 4.19.232 aarch64 bits: 64 Desktop: LXQt 0.14.1 Distro: Ubuntu 20.04.3 LTS (Focal Fossa) Machine: Type: ARM Device System: Rockchip RK3566 Purple Pi OH-3566 V1 Board serial: 65442c043c42255b CPU: Topology: Quad Core model: N/A variant: cortex-a55 bits: 64 type: MCP Speed: 1800 MHz min/max: 408/1800 MHz Core speeds (MHz): 1: 1800 2: 1800 3: 1800 4: 1800 Graphics: Device-1: display-subsystem driver: rockchip_drm v: N/A Device-2: mali-bifrost driver: mali v: N/A Display: x11 server: X.Org 1.20.8 driver: modesetting resolution: 800x1280~60Hz OpenGL: renderer: llvmpipe (LLVM 12.0.0 128 bits) v: 4.5 Mesa 21.0.3 Audio: Device-1: simple-audio-card driver: N/A Device-2: simple-audio-card driver: asoc_simple_card Sound Server: ALSA v: k4.19.232 Network: Device-1: rk3568-gmac driver: rk_gmac_dwmac IF: eth0 state: down mac: 1a:8e:b0:55:33:b0 Device-2: wlan-platdata driver: wlan_platdata IF-ID-1: wlan0 state: up mac: 10:68:38:21:c9:fb Drives: Local Storage: total: 29.12 GiB used: 4.60 GiB (15.8%) ID-1: /dev/mmcblk0 model: SPeMMC size: 29.12 GiB Partition: ID-1: / size: 28.50 GiB used: 4.60 GiB (16.2%) fs: ext4 dev: /dev/mmcblk0p8 Sensors: Message: No sensors data was found. Is sensors configured? Info: Processes: 197 Uptime: 2h 20m Memory: 3.81 GiB used: 1.08 GiB (28.3%) Shell: bash inxi: 3.0.38 |
Benchmarking with sbc-bench
I started my review of the products by running the sbc-bench
script from Thomas Kaiser and the results are shown below.
For the 2GB/16GB board:
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 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 |
ido:~/Desktop/PPI/Tools/sbc-bench$ sudo ./sbc-bench.sh -r Starting to examine hardware/software for review purposes... ... sbc-bench v0.9.63 Installing needed tools: apt-get -f -qq -y install, updating cpufetch. Done. Checking cpufreq OPP. Done. Executing tinymembench. Done. Executing RAM latency tester. Done. Executing OpenSSL benchmark. Done. Executing 7-zip benchmark. Done. Throttling test: heating up the device, 5 more minutes to wait. Done. Checking cpufreq OPP again. Done (16 minutes elapsed). Results validation: * Measured clockspeed not lower than advertised max CPU clockspeed * Background activity (%system) OK Full results uploaded to http://sprunge.us/96JoCE # Rockchip RK3566 Purple Pi OH-3566 V1 Board Tested with sbc-bench v0.9.63 on Thu, 29 Feb 2024 14:04:05 +0700. Full info: [http://sprunge.us/96JoCE](http://sprunge.us/96JoCE) ### General information: Rockchip RK3566 (35662000), Kernel: aarch64, Userland: arm64 CPU sysfs topology (clusters, cpufreq members, clockspeeds) cpufreq min max CPU cluster policy speed speed core type 0 0 0 408 1800 Cortex-A55 / r2p0 1 0 0 408 1800 Cortex-A55 / r2p0 2 0 0 408 1800 Cortex-A55 / r2p0 3 0 0 408 1800 Cortex-A55 / r2p0 1972 KB available RAM ### Governors/policies (performance vs. idle consumption): Original governor settings: cpufreq-policy0: performance / 1800 MHz (conservative ondemand userspace powersave interactive performance / 408 600 816 1104 1416 1608 1800) dmc: performance / 1056 MHz (rknpu_ondemand dmc_ondemand vdec2_ondemand venc_ondemand userspace powersave performance simple_ondemand / 324 528 780 1056) fde40000.npu: performance / 900 MHz (rknpu_ondemand dmc_ondemand vdec2_ondemand venc_ondemand userspace powersave performance simple_ondemand / 200 297 400 600 700 800 900) fde60000.gpu: performance / 800 MHz (rknpu_ondemand dmc_ondemand vdec2_ondemand venc_ondemand userspace powersave performance simple_ondemand / 200 300 400 600 700 800) fdf40000.rkvenc: performance / 400 MHz (rknpu_ondemand dmc_ondemand vdec2_ondemand venc_ondemand userspace powersave performance simple_ondemand / 297 400) fdf80200.rkvdec: performance / 400 MHz (rknpu_ondemand dmc_ondemand vdec2_ondemand venc_ondemand userspace powersave performance simple_ondemand / 297 400) Tuned governor settings: cpufreq-policy0: performance / 1800 MHz dmc: performance / 1056 MHz fde40000.npu: performance / 900 MHz fde60000.gpu: performance / 800 MHz fdf40000.rkvenc: performance / 400 MHz fdf80200.rkvdec: performance / 400 MHz Status of performance related policies found below /sys: /sys/devices/platform/fde60000.gpu/power_policy: [coarse_demand] always_on ### Clockspeeds (idle vs. heated up): Before at 41.2°C: cpu0 (Cortex-A55): OPP: 1800, Measured: 1791 After at 72.2°C: cpu0 (Cortex-A55): OPP: 1800, Measured: 1764 (-2.0%) ### Performance baseline * memcpy: 2849.1 MB/s, memchr: 3142.0 MB/s, memset: 7754.8 MB/s * 16M latency: 181.9 185.7 181.9 183.5 181.2 182.9 244.4 451.7 * 128M latency: 198.3 198.6 193.6 196.4 196.3 196.5 252.3 467.5 * 7-zip MIPS (3 consecutive runs): 4579, 4578, 4541 (4570 avg), single-threaded: 1338 * `aes-256-cbc 157355.90k 400690.82k 661750.87k 786019.33k 832268.97k 835589.46k` * `aes-256-cbc 157278.01k 399711.51k 657654.02k 784094.89k 830868.14k 834093.06k` ### Storage devices: * 14.6GB "Samsung AJTD4R" HS200 eMMC 5.1 card as /dev/mmcblk0: date 03/2023, manfid/oemid: 0x000015/0x0100, hw/fw rev: 0x0/0x0600000000000000 ### Software versions: * Ubuntu 20.04.3 LTS (focal) * Compiler: /usr/bin/gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0 / aarch64-linux-gnu * OpenSSL 1.1.1f, built on 31 Mar 2020 ### Kernel info: * `/proc/cmdline: storagemedia=emmc androidboot.storagemedia=emmc androidboot.mode=normal androidboot.verifiedbootstate=orange rw rootwait earlycon=uart8250,mmio32,0xfe660000 console=ttyFIQ0 root=PARTUUID=614e0000-0000` * Vulnerability Spectre v1: Mitigation; __user pointer sanitization * Kernel 4.19.232 / CONFIG_HZ=300 Kernel 4.19.232 is not latest 4.19.307 LTS that was released on 2024-02-23. See https://endoflife.date/linux for details. It is somewhat likely that a lot of exploitable vulnerabilities exist for this kernel as well as many unfixed bugs. But this version string doesn't matter since this is not an official LTS Linux from kernel.org. This device runs a forward ported Rockchip vendor/BSP kernel. All known settings adjusted for performance. Device now ready for benchmarking. Once finished stop with [ctrl]-[c] to get info about throttling, frequency cap and too high background activity all potentially invalidating benchmark scores. All changes with storage and PCIe devices as well as suspicious dmesg contents will be reported too. Time CPU load %cpu %sys %usr %nice %io %irq Temp 14:04:06: 1800MHz 3.30 48% 1% 46% 0% 0% 0% 60.6°C 14:05:06: 1800MHz 1.21 0% 0% 0% 0% 0% 0% 50.6°C 14:06:06: 1800MHz 0.44 0% 0% 0% 0% 0% 0% 46.7°C 14:07:06: 1800MHz 0.16 0% 0% 0% 0% 0% 0% 44.4°C 14:08:06: 1800MHz 0.06 0% 0% 0% 0% 0% 0% 42.5°C 14:09:06: 1800MHz 0.08 0% 0% 0% 0% 0% 0% 41.2°C 14:10:06: 1800MHz 0.08 0% 0% 0% 0% 0% 0% 40.6°C ^C Cleaning up. Done. Checking cpufreq OPP again. Done. Clockspeeds now at 43.8°C: cpu0 (Cortex-A55): OPP: 1800, Measured: 1789 ... |
For the 4GB/16GB “Pro” board:
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 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 |
Starting to examine hardware/software for review purposes... Average load and/or CPU utilization too high (too much background activity). Waiting... ... sbc-bench v0.9.63 ... Results validation: * Measured clockspeed not lower than advertised max CPU clockspeed * Background activity (%system) OK # Rockchip RK3566 Purple Pi OH-3566 V1 Board ... ### General information: Rockchip RK3566 (35662000), Kernel: aarch64, Userland: arm64 CPU sysfs topology (clusters, cpufreq members, clockspeeds) cpufreq min max CPU cluster policy speed speed core type 0 0 0 408 1800 Cortex-A55 / r2p0 1 0 0 408 1800 Cortex-A55 / r2p0 2 0 0 408 1800 Cortex-A55 / r2p0 3 0 0 408 1800 Cortex-A55 / r2p0 3905 KB available RAM ### Governors/policies (performance vs. idle consumption): Original governor settings: cpufreq-policy0: performance / 1800 MHz (conservative ondemand userspace powersave interactive performance / 408 600 816 1104 1416 1608 1800) dmc: performance / 1056 MHz (rknpu_ondemand dmc_ondemand vdec2_ondemand venc_ondemand userspace powersave performance simple_ondemand / 324 528 780 1056) fde40000.npu: performance / 900 MHz (rknpu_ondemand dmc_ondemand vdec2_ondemand venc_ondemand userspace powersave performance simple_ondemand / 200 297 400 600 700 800 900) fde60000.gpu: performance / 800 MHz (rknpu_ondemand dmc_ondemand vdec2_ondemand venc_ondemand userspace powersave performance simple_ondemand / 200 300 400 600 700 800) fdf40000.rkvenc: performance / 400 MHz (rknpu_ondemand dmc_ondemand vdec2_ondemand venc_ondemand userspace powersave performance simple_ondemand / 297 400) fdf80200.rkvdec: performance / 400 MHz (rknpu_ondemand dmc_ondemand vdec2_ondemand venc_ondemand userspace powersave performance simple_ondemand / 297 400) Tuned governor settings: cpufreq-policy0: performance / 1800 MHz dmc: performance / 1056 MHz fde40000.npu: performance / 900 MHz fde60000.gpu: performance / 800 MHz fdf40000.rkvenc: performance / 400 MHz fdf80200.rkvdec: performance / 400 MHz Status of performance related policies found below /sys: /sys/devices/platform/fde60000.gpu/power_policy: [coarse_demand] always_on ### Clockspeeds (idle vs. heated up): Before at 48.3°C: cpu0 (Cortex-A55): OPP: 1800, Measured: 1860 (+3.3%) After at 59.4°C: cpu0 (Cortex-A55): OPP: 1800, Measured: 1862 (+3.4%) ### Performance baseline * memcpy: 2826.4 MB/s, memchr: 3241.7 MB/s, memset: 7495.4 MB/s * 16M latency: 180.8 184.1 180.3 181.8 179.4 181.4 241.6 447.2 * 128M latency: 196.7 195.6 191.4 195.9 191.2 194.5 252.1 462.1 * 7-zip MIPS (3 consecutive runs): 4836, 4779, 4822 (4810 avg), single-threaded: 1390 * `aes-256-cbc 162279.43k 415338.52k 687460.10k 819039.23k 868196.35k 871940.10k` * `aes-256-cbc 161383.75k 417960.73k 687332.35k 819466.92k 868843.52k 872781.14k` ### Storage devices: * 29.1GB "SPeMMC" HS200 eMMC 5.1 card as /dev/mmcblk0: date 06/2021, manfid/oemid: 0x0000ea/0x010e, hw/fw rev: 0x0/0x3035303530380000 ### Software versions: * Ubuntu 20.04.3 LTS (focal) * Compiler: /usr/bin/gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0 / aarch64-linux-gnu * OpenSSL 1.1.1f, built on 31 Mar 2020 ### Kernel info: * `/proc/cmdline: storagemedia=emmc androidboot.storagemedia=emmc androidboot.mode=normal androidboot.verifiedbootstate=orange rw rootwait earlycon=uart8250,mmio32,0xfe660000 console=ttyFIQ0 root=PARTUUID=614e0000-0000` * Vulnerability Spectre v1: Mitigation; __user pointer sanitization * Kernel 4.19.232 / CONFIG_HZ=300 ... Time CPU load %cpu %sys %usr %nice %io %irq Temp 03:11:06: 1800MHz 4.05 47% 1% 45% 0% 0% 0% 50.0°C 03:12:06: 1800MHz 1.48 0% 0% 0% 0% 0% 0% 39.4°C 03:13:06: 1800MHz 0.54 0% 0% 0% 0% 0% 0% 37.2°C 03:14:06: 1800MHz 0.24 1% 0% 0% 0% 0% 0% 38.3°C 03:15:06: 1800MHz 0.09 0% 0% 0% 0% 0% 0% 36.7°C ^C Cleaning up. Done. Checking cpufreq OPP again. Done. Clockspeeds now at 40.0°C: cpu0 (Cortex-A55): OPP: 1800, Measured: 1878 (+4.3%) ... |
The room temperature during the tests was around 26°C when we examined how temperature affects the CPU frequency. For the Purple Pi OH, the initial temperature was around 41°C, and the CPU clock frequency was 1791 MHz. As the CPU heated up to 72°C, the CPU clock frequency was measured at 1764 MHz. For the Purple Pi OH Pro, the CPU was heated up to around 59.4°C, and the measured clock frequencies before and after the tests were 1860 MHz and 1862 MHz, respectively. In both cases, no CPU throttling was reported.
The performance of memory operations for both devices was similar, with the Purple Pi OH showing slightly higher performance than the Purple Pi OH Pro.
Comparisons of the read/write performances of the storage device
The next test compared the reading and writing performance of the storage devices using IOZone3. I ran iozone3 with the -I parameter to force testing with no cache and set the file size to 512 MB. The other parameters and the results are shown below.
Purple Pi OH:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
Iozone: Performance Test of File I/O Version $Revision: 3.489 $ Compiled for 64 bit mode. Build: linux ... Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 524288 kB Record Size 1024 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 512M -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 524288 1024 53586 54298 136851 136444 135645 54183 524288 16384 55061 55075 156190 154180 153423 52958 |
Purple Pi OH Pro:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
Iozone: Performance Test of File I/O Version $Revision: 3.489 $ Compiled for 64 bit mode. Build: linux ... Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 524288 kB Record Size 1024 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 512M -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 524288 1024 122779 121618 164453 164805 162214 111418 524288 16384 121198 120461 166699 167023 166970 119274 |
The storage device of the Purple Pi OH is 16GB, and the results showed a sequential file reading speed of around 156MB/s and a writing speed of 55MB/s. For the Purple Pi OH Pro, the reading speed was 166MB/s, and the writing speed was around 121 MB/s.
It can be seen that the performance of reading data on the Purple Pi OH Pro was approximately 70% of the writing speed. However, for the Purple Pi OH, the reading speed was only 37% of the data writing speed. This difference was significant and interesting. So, I searched the Internet and found a report on the WiKi page of the ODROID. The report showed that the read/write performance of the 8GB and 16GB Samsung eMMC 5.1 devices had very similar characteristics: the writing speed was around 33% of the reading speed. Therefore, I concluded that my testing results were within the normal specifications of the storage device used in the Purple Pi OH board.
Testing the network performance
Next, I tested networking performance using the iperf3 program. I began with the Gigabit Ethernet connection speed test, followed by the Wi-Fi tests, as follows.
Testing Gigabit Ethernet connection speed
I tested the Gigabit Ethernet port by connecting the board to my office’s LAN and using a desktop computer as a server for iperf3 tests. The tests were configured to run for 60 seconds and summarize the data every 10-second interval. The results are shown below.
Purple Pi OH: sending
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
ido@ido:~$ iperf3 -c 10.2.1.201 -t 60 -i 10 Connecting to host 10.2.1.201, port 5201 [ 5] local 10.2.1.86 port 37266 connected to 10.2.1.201 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec 0 220 KBytes [ 5] 10.00-20.00 sec 1.10 GBytes 941 Mbits/sec 0 220 KBytes [ 5] 20.00-30.00 sec 1.10 GBytes 942 Mbits/sec 0 220 KBytes [ 5] 30.00-40.00 sec 1.09 GBytes 941 Mbits/sec 0 220 KBytes [ 5] 40.00-50.00 sec 1.09 GBytes 939 Mbits/sec 0 220 KBytes [ 5] 50.00-60.00 sec 1.09 GBytes 937 Mbits/sec 0 220 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 6.56 GBytes 940 Mbits/sec 0 sender [ 5] 0.00-60.00 sec 6.56 GBytes 940 Mbits/sec receiver iperf Done. |
Purple Pi OH Pro: sending
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
ido@ido:~$ iperf3 -c 10.2.1.201 -t 60 -i 10 Connecting to host 10.2.1.201, port 5201 [ 5] local 10.2.1.87 port 33802 connected to 10.2.1.201 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-10.00 sec 1.05 GBytes 902 Mbits/sec 104 211 KBytes [ 5] 10.00-20.00 sec 1.08 GBytes 931 Mbits/sec 0 211 KBytes [ 5] 20.00-30.00 sec 1.09 GBytes 935 Mbits/sec 0 211 KBytes [ 5] 30.00-40.00 sec 1.09 GBytes 935 Mbits/sec 0 211 KBytes [ 5] 40.00-50.00 sec 1.09 GBytes 934 Mbits/sec 0 211 KBytes [ 5] 50.00-60.00 sec 1.09 GBytes 936 Mbits/sec 0 211 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 6.49 GBytes 929 Mbits/sec 104 sender [ 5] 0.00-60.00 sec 6.49 GBytes 929 Mbits/sec receiver iperf Done. |
Purple Pi OH: receiving
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
ido@ido:~$ iperf3 -c 10.2.1.201 -t 60 -i 10 -R Connecting to host 10.2.1.201, port 5201 Reverse mode, remote host 10.2.1.201 is sending [ 5] local 10.2.1.86 port 37258 connected to 10.2.1.201 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec [ 5] 10.00-20.00 sec 1.09 GBytes 938 Mbits/sec [ 5] 20.00-30.00 sec 1.10 GBytes 943 Mbits/sec [ 5] 30.00-40.00 sec 1.10 GBytes 942 Mbits/sec [ 5] 40.00-50.00 sec 1.09 GBytes 939 Mbits/sec [ 5] 50.00-60.00 sec 1.09 GBytes 940 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-60.00 sec 6.57 GBytes 940 Mbits/sec sender [ 5] 0.00-60.00 sec 6.57 GBytes 940 Mbits/sec receiver iperf Done. |
Purple Pi OH Pro: receiving
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
ido@ido:~$ iperf3 -c 10.2.1.201 -t 60 -i 10 -R Connecting to host 10.2.1.201, port 5201 Reverse mode, remote host 10.2.1.201 is sending [ 5] local 10.2.1.87 port 33878 connected to 10.2.1.201 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 1.10 GBytes 943 Mbits/sec [ 5] 10.00-20.00 sec 1.10 GBytes 941 Mbits/sec [ 5] 20.00-30.00 sec 1.10 GBytes 943 Mbits/sec [ 5] 30.00-40.00 sec 1.10 GBytes 943 Mbits/sec [ 5] 40.00-50.00 sec 1.10 GBytes 943 Mbits/sec [ 5] 50.00-60.00 sec 1.10 GBytes 943 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-60.00 sec 6.59 GBytes 943 Mbits/sec sender [ 5] 0.00-60.00 sec 6.59 GBytes 943 Mbits/sec receiver iperf Done. |
We can see that the overall performance of data transmission over the Gigabit Ethernet port of both devices was very similar. The average sending speed was approximately 940 MB/s for both boards, while the receiving speeds for the Purple Pi OH and Purple Pi OH Pro were 929 MB/s and 943 MB/s, respectively.
Testing data communication speeds over the 2.4GHz Wi-Fi
I have to remind you that the results of wireless data communication speed testing can vary and depend highly on many factors, such as the specifications of the router, testing positions, distances between the router and testing devices, and the number of other devices around the testing areas. In this review, I tested the devices using the Wi-Fi network in my house. I turned off other SSIDs and created a new SSID specifically for this test. I left the configurations of my router untouched as I use it in daily life. The distance between the router and the devices was around 3 meters. The results of running iperf3 on the Wi-Fi 2.4GHz were as follows.
2GB/16GB SBC: sending
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
ido@ido:~$ iperf3 -c 192.168.1.16 -t 60 -i 10 Connecting to host 192.168.1.16, port 5201 [ 5] local 192.168.1.19 port 54120 connected to 192.168.1.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-10.00 sec 32.3 MBytes 27.1 Mbits/sec 10 199 KBytes [ 5] 10.00-20.00 sec 32.9 MBytes 27.6 Mbits/sec 3 263 KBytes [ 5] 20.00-30.00 sec 32.4 MBytes 27.2 Mbits/sec 0 363 KBytes [ 5] 30.00-40.00 sec 32.7 MBytes 27.5 Mbits/sec 7 188 KBytes [ 5] 40.00-50.00 sec 32.1 MBytes 26.9 Mbits/sec 9 144 KBytes [ 5] 50.00-60.00 sec 32.4 MBytes 27.2 Mbits/sec 4 168 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 195 MBytes 27.3 Mbits/sec 33 sender [ 5] 0.00-60.00 sec 194 MBytes 27.2 Mbits/sec receiver iperf Done. |
4GB/16GB “Pro” SBC: sending
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
ido@ido:~$ iperf3 -c 192.168.1.16 -t 60 -i 10 Connecting to host 192.168.1.16, port 5201 [ 5] local 192.168.1.6 port 50126 connected to 192.168.1.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-10.00 sec 43.3 MBytes 36.3 Mbits/sec 0 718 KBytes [ 5] 10.00-20.00 sec 45.0 MBytes 37.7 Mbits/sec 0 1.04 MBytes [ 5] 20.00-30.00 sec 44.2 MBytes 37.1 Mbits/sec 0 1.04 MBytes [ 5] 30.00-40.00 sec 43.0 MBytes 36.1 Mbits/sec 0 1.04 MBytes [ 5] 40.00-50.00 sec 41.6 MBytes 34.9 Mbits/sec 0 1.04 MBytes [ 5] 50.00-60.00 sec 43.7 MBytes 36.6 Mbits/sec 0 1.04 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 261 MBytes 36.5 Mbits/sec 0 sender [ 5] 0.00-60.00 sec 258 MBytes 36.1 Mbits/sec receiver iperf Done. |
2GB/16GB SBC: receiving
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
ido@ido:~$ iperf3 -c 192.168.1.16 -t 60 -i 10 -R Connecting to host 192.168.1.16, port 5201 Reverse mode, remote host 192.168.1.16 is sending [ 5] local 192.168.1.19 port 54198 connected to 192.168.1.2 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 40.5 MBytes 34.0 Mbits/sec [ 5] 10.00-20.00 sec 35.5 MBytes 29.7 Mbits/sec [ 5] 20.00-30.00 sec 40.4 MBytes 33.9 Mbits/sec [ 5] 30.00-40.00 sec 40.3 MBytes 33.8 Mbits/sec [ 5] 40.00-50.00 sec 36.7 MBytes 30.7 Mbits/sec [ 5] 50.00-60.00 sec 36.2 MBytes 30.4 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-60.00 sec 233 MBytes 32.6 Mbits/sec sender [ 5] 0.00-60.00 sec 230 MBytes 32.1 Mbits/sec receiver iperf Done. |
4GB/16GB “Pro” SBC: receiving
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
ido@ido:~$ iperf3 -c 192.168.1.16 -t 60 -i 10 -R Connecting to host 192.168.1.16, port 5201 Reverse mode, remote host 192.168.1.16 is sending [ 5] local 192.168.1.6 port 50142 connected to 192.168.1.2 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 48.0 MBytes 40.3 Mbits/sec [ 5] 10.00-20.00 sec 45.3 MBytes 38.0 Mbits/sec [ 5] 20.00-30.00 sec 44.6 MBytes 37.5 Mbits/sec [ 5] 30.00-40.00 sec 45.6 MBytes 38.2 Mbits/sec [ 5] 40.00-50.00 sec 47.1 MBytes 39.5 Mbits/sec [ 5] 50.00-60.00 sec 44.9 MBytes 37.6 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-60.00 sec 279 MBytes 39.1 Mbits/sec sender [ 5] 0.00-60.00 sec 275 MBytes 38.5 Mbits/sec receiver iperf Done. |
According to the results, the Purple Pi OH board had transmitting and receiving speeds of around 27.2 Mb/s and 32.3 Mb/s, respectively. Meanwhile, the Purple Pi OH Pro had transmitting and receiving speeds of 36.3 Mb/s and 38.8 Mb/s, respectively. In summary, the performance of the Purple Pi OH Pro was higher than that of the Purple Pi OH. The sending speed of the Purple Pi OH Pro was approximately 33% higher than that of the Purple Pi OH, and the receiving speed was also around 20% higher. Additionally, when I changed the location of the tests, I usually found data retransmissions on the Purple Pi OH board, while they were rarely found on the Purple Pi OH Pro.
Testing data communication speeds over the 5GHz Wi-Fi
Since the Purple Pi OH does not support Wi-Fi 5GHz, only the Purple Pi OH Pro was tested here. I ran iperf3 with the same parameters as in the above tests and obtained the following results. In summary, the average data receiving speed on Wi-Fi 5GHz was higher than that on Wi-Fi 2.4GHz by around 25%, while the overall data communication speed on Wi-Fi 5GHz was approximately 3 times higher than on Wi-Fi 2.4GHz.
Sending
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
ido@ido:~$ iperf3 -c 192.168.1.2 -t 60 -i 10 Connecting to host 192.168.1.2, port 5201 [ 5] local 192.168.1.6 port 50390 connected to 192.168.1.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-10.00 sec 129 MBytes 108 Mbits/sec 0 660 KBytes [ 5] 10.00-20.00 sec 134 MBytes 112 Mbits/sec 0 1.16 MBytes [ 5] 20.00-30.00 sec 131 MBytes 110 Mbits/sec 0 1.16 MBytes [ 5] 30.00-40.00 sec 134 MBytes 112 Mbits/sec 0 1.16 MBytes [ 5] 40.00-50.00 sec 132 MBytes 111 Mbits/sec 0 1.16 MBytes [ 5] 50.00-60.00 sec 132 MBytes 111 Mbits/sec 0 1.16 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 792 MBytes 111 Mbits/sec 0 sender [ 5] 0.00-60.00 sec 790 MBytes 110 Mbits/sec receiver iperf Done. |
Receiving
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
ido@ido:~$ iperf3 -c 192.168.1.2 -t 60 -i 10 -R Connecting to host 192.168.1.2, port 5201 Reverse mode, remote host 192.168.1.2 is sending [ 5] local 192.168.1.6 port 50398 connected to 192.168.1.2 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 151 MBytes 127 Mbits/sec [ 5] 10.00-20.00 sec 171 MBytes 144 Mbits/sec [ 5] 20.00-30.00 sec 181 MBytes 152 Mbits/sec [ 5] 30.00-40.00 sec 170 MBytes 143 Mbits/sec [ 5] 40.00-50.00 sec 157 MBytes 131 Mbits/sec [ 5] 50.00-60.00 sec 155 MBytes 130 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-60.00 sec 988 MBytes 138 Mbits/sec sender [ 5] 0.00-60.00 sec 985 MBytes 138 Mbits/sec receiver iperf Done. |
So, both devices can perform their wireless data communications as expected, with the Purple Pi OH Pro demonstrating better performance than the Purple Pi OH. Additionally, the retransmission rates for the Purple Pi OH Pro were usually very low to none, whether in Wi-Fi 2.4GHz or Wi-Fi 5GHz tests.
Testing web browsers with Speedometer 2.0
I tested the performance of web browsers on both boards using the Speedometer 2.0 benchmark. For this review, I used the default Chromium 92.0.4515.159 (64-bit) preinstalled with the OS and manually installed the new Firefox 122.0.1 (64-bit). The testing results were as follows: Firefox outperformed Chromium by around 11 – 12%. The Purple Pi OH Pro showed slightly better performance than the Purple Pi OH. However, I have to note that the results of these tests may vary depending on the versions of the browsers.
Rockchip RK3566’s 3D graphics testing
OpenGL ES with glmark-es2
Next, I proceeded to test the performance of OpenGL (ES). I initially attempted to conduct the tests using the glmark2-es2-wayland. However, I encountered issues that glmark2-es2-wayland
failed to run after installation. So, I used the command echo $XDG_SESSION_TYPE
and discovered that the OS was using X11, which is incompatible with glmark2-es2-wayland. There, I decided to test OpenGL (ES) using the pre-installed glmark2-es2
. Both boards provided the same score of 57, whereas the Purple Pi OH Pro had slightly better performance in certain tests, such as in rendering terrain and shadows. The remaining testing results remained identical between the two boards.
Performance of OpenGL ES
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 |
ido@ido:~$ glmark2-es2 ======================================================= glmark2 2021.02 ======================================================= OpenGL Information GL_VENDOR: ARM GL_RENDERER: Mali-G52 GL_VERSION: OpenGL ES 3.2 v1.g2p0-01eac0.327c41db9c110a33ae6f67b4cc0581c7 ======================================================= [build] use-vbo=false: FPS: 50 FrameTime: 20.000 ms [build] use-vbo=true: FPS: 60 FrameTime: 16.667 ms [texture] texture-filter=nearest: FPS: 59 FrameTime: 16.949 ms [texture] texture-filter=linear: FPS: 60 FrameTime: 16.667 ms [texture] texture-filter=mipmap: FPS: 60 FrameTime: 16.667 ms [shading] shading=gouraud: FPS: 60 FrameTime: 16.667 ms [shading] shading=blinn-phong-inf: FPS: 60 FrameTime: 16.667 ms [shading] shading=phong: FPS: 60 FrameTime: 16.667 ms [shading] shading=cel: FPS: 60 FrameTime: 16.667 ms [bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms [bump] bump-render=normals: FPS: 60 FrameTime: 16.667 ms [bump] bump-render=height: FPS: 60 FrameTime: 16.667 ms [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 60 FrameTime: 16.667 ms [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 60 FrameTime: 16.667 ms [pulsar] light=false:quads=5:texture=false: FPS: 60 FrameTime: 16.667 ms [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 59 FrameTime: 16.949 ms [desktop] effect=shadow:windows=4: FPS: 60 FrameTime: 16.667 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 60 FrameTime: 16.667 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 60 FrameTime: 16.667 ms [buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 60 FrameTime: 16.667 ms [ideas] speed=duration: FPS: 60 FrameTime: 16.667 ms [jellyfish] <default>: FPS: 60 FrameTime: 16.667 ms [terrain] <default>: FPS: 30 FrameTime: 33.333 ms [shadow] <default>: FPS: 60 FrameTime: 16.667 ms [refract] <default>: FPS: 30 FrameTime: 33.333 ms [conditionals] fragment-steps=0:vertex-steps=0: FPS: 60 FrameTime: 16.667 ms [conditionals] fragment-steps=5:vertex-steps=0: FPS: 60 FrameTime: 16.667 ms [conditionals] fragment-steps=0:vertex-steps=5: FPS: 60 FrameTime: 16.667 ms [function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms [function] fragment-complexity=medium:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 60 FrameTime: 16.667 ms [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 60 FrameTime: 16.667 ms [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 60 FrameTime: 16.667 ms ======================================================= glmark2 Score: 57 |
WebGL rendering on Chromium
The next test was checking the performance of WebGL’s 3D rendering on a web browser. I performed the test using WebGL Aquarium on Chromium, where I varied the number of fishes from 1 to 30,000. The comparison results are shown below.
The following table compares the framerates of the tests. We can see that the WebGL performances of both boards were very similar. Both devices ran smoothly when the number of fish was lower than 500. However, the performance dropped significantly when the number of fish exceeded 5000. For 30000 fish, the framerate was just 2 fps on both devices.
(unit: fps)
1 | 100 | 500 | 1000 | 5000 | 10000 | 15000 | 20000 | 30000 | |
---|---|---|---|---|---|---|---|---|---|
Purple Pi OH | 37 | 35 | 27 | 20 | 8 | 4 | 3 | 3 | 2 |
Purple Pi OH Pro | 40 | 34 | 27 | 21 | 8 | 5 | 3 | 3 | 2 |
Testing YouTube video playback on Purple Pi OH boards
To test the video playing performance, I connected the device to my office’s wired network using the Gigabit Ethernet port. In YouTube, the viewing mode was set to full screen, and I overlaid the screen with the Stats for Nerds. The video resolutions were varied from 720p to 2160p. In summary, both devices could smoothly play videos at resolutions up to 1080p or lower without any noticeable stuttering. In this case, the dropout rates were lower than 1%, with most dropped frames occurring only at the beginning of playback.
However, when I increased the resolution to 1080p, significant stuttering was noticeable on both devices. Moreover, when I set the resolution to 2160p, the videos could not be played continuously because the dropout rates of both devices were consistently higher than 60%, as shown in the following figures.
The table below compares the dropout rates of both devices. Although the Purple Pi OH Pro had slightly lower dropout rates at 2160p, they were still unacceptably high and rendered the devices unable to smoothly play videos at this resolution.
Percentage of dropped frames
720p | 1080p | 1440p | 2160p | |
---|---|---|---|---|
Purple Pi OH | 0.7% | 0.8% | 37.6% | 66.9% |
Purple Pi OH Pro | 0.2% | 1.0% | 37.1% | 61.5% |
Testing the NPU and AI acceleration on Purple Pi OH SBCs
For the NPU and AI performance tests, I utilized the RKNN-Toolkit2 and RKNPU2 from the GitHub repository of rockchip-linux following the same procedure as in the reviews of the Youyeetoo YY3568 and Mixtile Blade 3 single board computers. In this review, I tested the devices with the YOLOv5 model using the provided rknn_yolov5_demo source code. I began by cloning the source code onto the devices and then executed the build-linux_RK3566_RK3568.sh script to build the program. The overall process of this preparation was straightforward, and fast, and no issues were encountered.
To test the model, I executed the rknn_yolov5_demo program built in the previous step by using the pre-trained yolov5s-640-640.rknn model included with the toolkit. The testing images consisted of an office image and a pedestrian image, which I obtained from Wikipedia. The images were cropped to 640×640 pixels to match the dimensions of the input layer of the model. The results are displayed below.
Testing Yolov5 on the Purple Pi OH
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
post process config: box_conf_threshold = 0.25, nms_threshold = 0.45 Loading mode... sdk version: 1.5.2 (c6b7b351a@2023-08-23T15:28:22) driver version: 0.8.2 model input num: 1, output num: 3 index=0, name=images, n_dims=4, dims=[1, 640, 640, 3], n_elems=1228800, size=1228800, w_stride = 640, size_with_stride=1228800, fmt=NHWC, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003922 index=0, name=output, n_dims=4, dims=[1, 255, 80, 80], n_elems=1632000, size=1632000, w_stride = 0, size_with_stride=1638400, fmt=NCHW, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003860 index=1, name=283, n_dims=4, dims=[1, 255, 40, 40], n_elems=408000, size=408000, w_stride = 0, size_with_stride=409600, fmt=NCHW, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003922 index=2, name=285, n_dims=4, dims=[1, 255, 20, 20], n_elems=102000, size=102000, w_stride = 0, size_with_stride=122880, fmt=NCHW, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003915 model is NHWC input fmt model input height=640, width=640, channel=3 Read office.jpg ... img width = 640, img height = 640 once run use 60.780000 ms loadLabelName ./model/coco_80_labels_list.txt .... loop count = 10 , average run 60.645700 ms |
Testing Yolov5 on Purple Pi OH Pro
1 2 3 4 5 |
post process config: box_conf_threshold = 0.25, nms_threshold = 0.45 Loading mode... sdk version: 1.5.2 (c6b7b351a@2023-08-23T15:28:22) driver version: 0.8.2 ... loop count = 10 , average run 52.298700 ms |
There were approximately 40 objects recognized in both images. According to the output results, the Purple Pi OH took around 60ms (approximately 16 fps) to complete this task, while the Purple Pi OH Pro processed it faster, taking around 52ms (approximately 19 fps), which is approximately 16% faster.
To benchmark the AI performance, I also used the rknn_benchmark program from the examples folder. After building, running, and benchmarking the devices using the same images, the results were as follows. The Purple Pi OH Pro took around 50ms (approximately 20 fps) to complete the calculations, which was slightly better than the Purple Pi OH, which took around 52ms (approximately 19 fps) to complete the same task.
Benchmarking RKNN on Purple Pi OH
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 |
rknn_api/rknnrt version: 1.5.2 (c6b7b351a@2023-08-23T15:28:22), driver version: 0.8.2 total weight size: 7308672, total internal size: 6144000 total dma used size: 21528576 model input num: 1, output num: 3 input tensors: index=0, name=images, n_dims=4, dims=[1, 640, 640, 3], n_elems=1228800, size=1228800, w_stride = 640, size_with_stride=1228800, fmt=NHWC, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003922 output tensors: index=0, name=output, n_dims=4, dims=[1, 255, 80, 80], n_elems=1632000, size=1632000, w_stride = 0, size_with_stride=1638400, fmt=NCHW, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003860 index=1, name=283, n_dims=4, dims=[1, 255, 40, 40], n_elems=408000, size=408000, w_stride = 0, size_with_stride=409600, fmt=NCHW, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003922 index=2, name=285, n_dims=4, dims=[1, 255, 20, 20], n_elems=102000, size=102000, w_stride = 0, size_with_stride=122880, fmt=NCHW, type=INT8, qnt_type=AFFINE, zp=-128, scale=0.003915 custom string: Warmup ... 0: Elapse Time = 52.64ms, FPS = 19.00 1: Elapse Time = 52.91ms, FPS = 18.90 2: Elapse Time = 53.65ms, FPS = 18.64 3: Elapse Time = 53.17ms, FPS = 18.81 4: Elapse Time = 52.37ms, FPS = 19.09 Begin perf ... 0: Elapse Time = 52.70ms, FPS = 18.97 1: Elapse Time = 52.77ms, FPS = 18.95 2: Elapse Time = 52.66ms, FPS = 18.99 3: Elapse Time = 52.90ms, FPS = 18.90 4: Elapse Time = 52.71ms, FPS = 18.97 5: Elapse Time = 52.38ms, FPS = 19.09 6: Elapse Time = 53.48ms, FPS = 18.70 7: Elapse Time = 53.21ms, FPS = 18.79 8: Elapse Time = 53.79ms, FPS = 18.59 9: Elapse Time = 53.52ms, FPS = 18.69 Avg Time 53.01ms, Avg FPS = 18.863 |
Benchmarking RKNN on the Pro board
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
... Warmup ... 0: Elapse Time = 49.83ms, FPS = 20.07 1: Elapse Time = 48.92ms, FPS = 20.44 2: Elapse Time = 48.76ms, FPS = 20.51 3: Elapse Time = 50.00ms, FPS = 20.00 4: Elapse Time = 49.70ms, FPS = 20.12 Begin perf ... 0: Elapse Time = 49.74ms, FPS = 20.10 1: Elapse Time = 49.60ms, FPS = 20.16 2: Elapse Time = 49.69ms, FPS = 20.12 3: Elapse Time = 49.90ms, FPS = 20.04 4: Elapse Time = 49.88ms, FPS = 20.05 5: Elapse Time = 50.57ms, FPS = 19.78 6: Elapse Time = 50.24ms, FPS = 19.90 7: Elapse Time = 50.22ms, FPS = 19.91 8: Elapse Time = 48.84ms, FPS = 20.47 9: Elapse Time = 53.48ms, FPS = 18.70 Avg Time 50.22ms, Avg FPS = 19.914 |
Test MIPI Camera and USB Camera
The manufacturer provides a MIPI Camera with the board, and it works well with the preinstalled OS. However, I couldn’t manage to make the camera run on Ubuntu 20.04. Therefore, I decided to perform quick tests by connecting my Full HD USB camera to the device. When listing the details and controllable parameters of the USB camera using the v4l2-ctl
program, I obtained the following results. Then, I wrote a simple shell script to control the brightness and contrast and used the fswebcam
to test recording the image, as follows.
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 |
v4l2-ctl -d /dev/video9 --all Streaming Parameters Video Capture: Capabilities : timeperframe Frames per second: 30.000 (30/1) Read buffers : 0 brightness 0x00980900 (int) : min=0 max=255 step=1 default=137 value=120 contrast 0x00980901 (int) : min=0 max=255 step=1 default=129 value=255 saturation 0x00980902 (int) : min=0 max=255 step=1 default=128 value=255 hue 0x00980903 (int) : min=0 max=255 step=1 default=103 value=103 white_balance_temperature_auto 0x0098090c (bool) : default=1 value=1 gamma 0x00980910 (int) : min=0 max=255 step=1 default=130 value=100 gain 0x00980913 (int) : min=0 max=255 step=1 default=0 value=0 power_line_frequency 0x00980918 (menu) : min=0 max=2 default=1 value=1 0: Disabled 1: 50 Hz 2: 60 Hz white_balance_temperature 0x0098091a (int) : min=2800 max=6500 step=1 default=4600 value=4600 flags=inactive sharpness 0x0098091b (int) : min=0 max=255 step=1 default=240 value=255 backlight_compensation 0x0098091c (int) : min=0 max=2 step=1 default=1 value=1 exposure_auto 0x009a0901 (menu) : min=0 max=3 default=3 value=1 1: Manual Mode 3: Aperture Priority Mode exposure_absolute 0x009a0902 (int) : min=3 max=2047 step=1 default=166 value=266 focus_absolute 0x009a090a (int) : min=0 max=255 step=1 default=0 value=0 flags=inactive focus_auto 0x009a090c (bool) : default=0 value=1 |
Thermal testing
Next, I performed thermal testing on both devices. So, I ran a 4K YouTube video in fullscreen mode for around 5 minutes and used a thermal camera to capture the thermal images. The following images compared the temperature of both boards when running the videos and in the idle stage. The average temperature of both devices in the idle stage was in the range of 38 – 40°C, with the hottest part being the Rockchip RK809-5 chip, located on the lower left corner of the board. When running the 4K YouTube videos, the highest temperatures climbed to around 62°C at the heat sink of the devices.
Testing power consumption
My last test was to compare the power consumption of the devices. Therefore, I set the screen’s brightness to the maximum value, connected the device to the Internet using Wi-Fi 2.4 GHz, and then played 4K videos on YouTube with 4 resolutions: 720p, 1080p, 1440p, and 2160p. For each setting, I played the video for around 30 seconds and used the USB voltage and current meter to measure the power consumption. The results were as follows. The Purple Pi OH Pro consumed more power than the Purple Pi OH board, around 10 – 25% more, which may be because the Pro version has more memory.
Board | 720p | 1080p | 1440p | 2160p |
---|---|---|---|---|
Purple Pi OH | 3.61W | 4.78W | 5.06W | 5.25W |
Purple Pi OH Pro | 4.53W | 5.31W | 5.55W | 5.62W |
I then attempted to check how the brightness of the screen affects power consumption. So, I closed all open programs, ran the devices in an idle stage for around 5 minutes, and then measured the power consumption when the brightness of the screen was set to minimum and maximum values. The results are shown in the following table. It can be seen that setting the screen brightness to the maximum value used more power than in the case of the lowest brightness, almost 2 times as much. Additionally, the Purple Pi OH Pro used slightly more power than the Purple Pi OH in this test.
Board | Lowest brightness level | Highest brightness level |
---|---|---|
Purple Pi OH | 1.43W | 2.68W |
Purple Pi OH Pro | 1.43W | 2.77W |
Conclusion
After owning the devices for around one month, I found that both of them are well-manufactured. Despite encountering some problems during the installation process, both devices performed as expected once set up. The Purple Pi OH Pro’s 32 GB of storage space is quite big for a single-board computer. The performance of the NPU tests using the RKNN-Toolkit2/RKNPU2 was impressive. However, they struggled to run 4K videos on YouTube smoothly. Wi-Fi worked fine, but depending on your setup you may be able to achieve better performance than in this review.
I would like to thank Wireless-Tag for providing me with the devices for this review. If you are interested, you can purchase the Purple Pi OH and the Purple Pi OH Pro boards from Alibaba. The Purple Pi OH is priced at $50.05, while the Purple Pi OH Pro goes for $82.50.
My main research areas are digital image/audio processing, digital photogrammetry, AI, IoT, and UAV. I am open to other subjects as well.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Which RPi is this mechanically compatible with?
I’m the one who added the “mechanically” word in the text. So I’ll answer. What I meant is that it should work with some cases and some HATs, not that it’s a drop-in replacement in a device like the Pi-Top.
Ahh ok – sorry I was thinking of the USB, Ethernet, HDMI and 3.5mm A/V ports… Still, whilst there shouldn’t be a problem with HATs, there are only a few cases designed for the RPi4B+ with an exchangeable “window” that allows for the full size HDMI port as on the RPi3B+
Wow, it sort of looks like a cross between a Pi 3 and a Pi 4; it has the larger HDMI port of the Pi3 but the USB/Ethernet arrangement of the Pi 4. That’s certainly a choice.
Exactly
> For the Purple Pi OH Pro, the reading speed was 166MB/s, and the writing speed was around 121 MB/s.
On an eMMC device that’s not from Samsung (‘SPeMMC’ HS200 eMMC 5.1 card as /dev/mmcblk0: date 06/2021, manfid/oemid: 0x0000ea/0x010e). Are you able to identify the manufacturer by readings on the chip?
That’s a SiliconGo SGM8100C eMMC flash. I can’t find that exact model on the manufacturer’s website.
Thank you, found a data sheet that confirms Manufacturer/OEM IDs as part of CID Register 🙂
This appears to be from the same manufacturer as one of the previously posted Sigma Star SSD202 based boards (https://www.cnx-software.com/2021/04/19/dual-ethernet-sigmastar-ssd201-ssd202-sbc-supports-4-inch-or-7-inch-displays/).
Yes. They also sell under the Industio brand.