Over one month has passed since our unboxing and quick Ubuntu 20.04 testing of the ODROID-M1S SBC and we’ve now had time to test more features and run benchmarks using the official Ubuntu 20.04.6 LTS release from Hardkernel. One user mentioned Ubuntu 22.04 is supported, but that’s supported by a third party and we used the official image for testing.
Our test results will show the performance and supported features of the Rockchip RK3566-powered ODROID-M1S SBC when running Ubuntu 20.04. Read on to find out how well the board works.
ODROID-M1S benchmarks
Let’s start benchmarking the ODROID-M1S with Thomas Kaiser’s sbc-bench.sh script:
|
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 |
odroid@gnome–desktop:~/sbc–bench$ sudo ./sbc–bench.sh –r 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.60
Installing needed tools, tinymembench, ramlat, mhz, cpufetch, cpuminer. 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:
* Advertised vs. measured max CPU clockspeed: –1.4% before, –1.8% after -> https://tinyurl.com/32w9rr94 * Background activity (%system) OK
# Hardkernel ODROID-M1S
Tested with sbc–bench v0.9.60 on Sun, 21 Jan 2024 10:14:59 +0700.
### General information:
Information courtesy of cpufetch:
SoC: Rockchip RK3566 Technology: 22nm Microarchitecture: Cortex–A55 Max Frequency: 1.800 GHz Cores: 4 cores Features: NEON,SHA1,SHA2,AES,CRC32 Peak Performance: 57.60 GFLOP/s
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
7676 KB available RAM
### Governors/policies (performance vs. idle consumption):
Original governor settings:
cpufreq–policy0: performance / 1800 MHz (interactive conservative ondemand userspace powersave performance / 408 600 816 1104 1416 1608 1800) fde60000.gpu: performance / 800 MHz (vdec2_ondemand venc_ondemand userspace powersave performance simple_ondemand / 200 300 400 600 700 800) fdf40000.rkvenc: performance / 400 MHz (vdec2_ondemand venc_ondemand userspace powersave performance simple_ondemand / 297 400) fdf80200.rkvdec: performance / 400 MHz (vdec2_ondemand venc_ondemand userspace powersave performance simple_ondemand / 297 400)
Tuned governor settings:
cpufreq–policy0: performance / 1800 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 /sys/module/pcie_aspm/parameters/policy: default [performance] powersave powersupersave
### Clockspeeds (idle vs. heated up):
Before at 44.4°C:
cpu0 (Cortex–A55): OPP: 1800, Measured: 1775 (–1.4%)
After at 59.4°C:
cpu0 (Cortex–A55): OPP: 1800, Measured: 1767 (–1.8%)
### Performance baseline
* memcpy: 2906.9 MB/s, memchr: 3139.8 MB/s, memset: 7952.8 MB/s * 16M latency: 180.7 183.8 181.6 183.0 180.2 181.9 244.0 451.9 * 128M latency: 217.3 194.0 190.3 193.6 189.0 194.1 251.4 482.6 * 7–zip MIPS (3 consecutive runs): 4581, 4575, 4612 (4590 avg), single–threaded: 1322 * `aes–256–cbc 156417.72k 398262.61k 654734.34k 780968.62k 827375.62k 827000.09k` * `aes–256–cbc 157146.64k 398160.17k 653565.10k 780867.58k 826146.82k 827419.31k`
### Storage devices: * 232.9GB “WD_BLACK SN770 250GB” SSD as /dev/nvme0: Speed 5GT/s (downgraded), Width x1 (downgraded), 0% worn out, drive temp: 47°C * 58.2GB “MMC64G” HS200 eMMC 5.1 card as /dev/mmcblk0: date 05/2023, manfid/oemid: 0x000032/0x0101, hw/fw rev: 0x0/0x0300000000000000
### Software versions:
* Ubuntu 20.04.6 LTS * 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 root=UUID=e104067f–7a88–4dea–9fc2–2b876ee3a6ca rootwait ro quiet console=tty1 console=ttyS2,1500000 pci=nomsi fsck.mode=force fsck.repair=yes` * Vulnerability Spectre v1: Mitigation; __user pointer sanitization * Kernel 5.10.0–odroid–arm64 / CONFIG_HZ=300
Kernel 5.10.0 is not latest 5.10.208 LTS that was released on 2024–01–15.
Time CPU load %cpu %sys %usr %nice %io %irq Temp 10:15:06: 1800MHz 3.54 14% 1% 11% 0% 0% 0% 53.8°C 10:16:06: 1800MHz 1.30 0% 0% 0% 0% 0% 0% 48.3°C 10:17:06: 1800MHz 0.47 0% 0% 0% 0% 0% 0% 46.7°C 10:18:06: 1800MHz 0.17 0% 0% 0% 0% 0% 0% 45.0°C 10:19:06: 1800MHz 0.06 0% 0% 0% 0% 0% 0% 44.4°C |
According to the test results, the CPU temperature reached up to 59.4°C under load and no CPU throttling occurred in a room with an ambient temperature of approximately 29 °C. The memcpy and memset results were similar to the ODROID-N2+, while the 7-zip performance of the ODROID-M1S was somewhat similar to that of the Raspberry Pi 4.
Web Browsing performance with Speedometer 2.0
We look at web browsing performance with Speedometer 2.0 in both Chromium and Firefox:
The test results in Speedometer 2.0 are similar to the results on the Raspberry Pi 4 board with the Chromium values scoring approximately 30% higher than in Firefox.
Again results in Firefox were similar to the ones on Raspberry Pi 4 (tested over four years ago).
3D graphics acceleration on ODROID-M1S SBC running Ubuntu 20.04
We tested 3D graphics acceleration with glmark2-es2-wayland with the board connected to the ODROID-Vu8S 8-inch.
Terminal output:
|
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 |
odroid@gnome–desktop:~$ glmark2–es2–wayland ======================================================= glmark2 2021.02 ======================================================= OpenGL Information GL_VENDOR: ARM GL_RENDERER: Mali–G52 GL_VERSION: OpenGL ES 3.2 v1.r25p0–01eac0.9771aca0686ac609bad539142d5c7fce ======================================================= [build] use–vbo=false:FPS: 442 FrameTime: 2.262 ms [build] use–vbo=true:FPS: 628 FrameTime: 1.592 ms [texture] texture–filter=nearest: FPS: 692 FrameTime: 1.445 ms [texture] texture–filter=linear: FPS: 690 FrameTime: 1.449 ms [texture] texture–filter=mipmap: FPS: 708 FrameTime: 1.412 ms [shading] shading=gouraud: FPS: 467 FrameTime: 2.141 ms [shading] shading=blinn–phong–inf: FPS: 472 FrameTime: 2.119 ms [shading] shading=phong: FPS: 427 FrameTime: 2.342 ms [shading] shading=cel: FPS: 421 FrameTime: 2.375 ms [bump] bump–render=high–poly: FPS: 231 FrameTime: 4.329 ms [bump] bump–render=normals: FPS: 772 FrameTime: 1.295 ms [bump] bump–render=height: FPS: 730 FrameTime: 1.370 ms [effect2d] kernel=0,1,0;1,–4,1;0,1,0;: FPS: 442 FrameTime: 2.262 ms [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 177 FrameTime: 5.650 ms [pulsar] light=false:quads=5:texture=false: FPS: 692 FrameTime: 1.445 ms [desktop] blur–radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 205 FrameTime: 4.878 ms [desktop] effect=shadow:windows=4: FPS: 418 FrameTime: 2.392 ms [buffer] columns=200:interleave=false:update–dispersion=0.9:update–fraction=0.5:update–method=map: FPS: 57 FrameTime: 17.544 ms [buffer] columns=200:interleave=false:update–dispersion=0.9:update–fraction=0.5:update–method=subdata: FPS: 57 FrameTime: 17.544 ms [buffer] columns=200:interleave=true:update–dispersion=0.9:update–fraction=0.5:update–method=map: FPS: 57 FrameTime: 17.544 ms [ideas] speed=duration: FPS: 190 FrameTime: 5.263 ms [jellyfish] <default>: FPS: 370 FrameTime: 2.703 ms [terrain] <default>: FPS: 26 FrameTime: 38.462 ms [shadow] <default>: FPS: 228 FrameTime: 4.386 ms [refract] <default>: FPS: 58 FrameTime: 17.241 ms [conditionals] fragment–steps=0:vertex–steps=0: FPS: 657 FrameTime: 1.522 ms [conditionals] fragment–steps=5:vertex–steps=0: FPS: 583 FrameTime: 1.715 ms [conditionals] fragment–steps=0:vertex–steps=5: FPS: 600 FrameTime: 1.667 ms [function] fragment–complexity=low:fragment–steps=5: FPS: 888 FrameTime: 1.126 ms [function] fragment–complexity=medium:fragment–steps=5: FPS: 883 FrameTime: 1.133 ms [loop] fragment–loop=false:fragment–steps=5:vertex–steps=5: FPS: 1064 FrameTime: 0.940 ms [loop] fragment–steps=5:fragment–uniform=false:vertex–steps=5: FPS: 1059 FrameTime: 0.944 ms [loop] fragment–steps=5:fragment–uniform=true:vertex–steps=5: FPS: 999 FrameTime: 1.001 ms ======================================================= glmark2 Score: 496 ======================================================= |
The score is 496 or slightly lower than the Raspberry Pi 4 and significantly lower than the Raspberry Pi 5’s 2036 points.
We then check if 3D graphics acceleration also working in Chromium with the WebGL aquarium demo.
The result was a bit disappointing with 1 FPS with 500 fish tested in both Chromium and Firefox. So the official image doesn’t support WebGL, and hopefully, this will be fixed in future releases of the Ubuntu image.
YouTube video playback
We started YouTube video playback at 4K resolution and 30 fps, and the video was unwatchable. When looking at the statistics, the dropped frame rate was over 50% as a result of hardware acceleration not being supported in the web browser.
We lowered our expectation and resolution to 1080p30, but the result was not much better.
It was only when we dropped the resolution to 720p30 (1280×720) that the video was smooth with obvious glitches while playing files. There were still over 10% of dropped frames. In any case, that means the CPU decoding should be possible at a maximum resolution of 720p30 (1280×720 @ 30 Hz).
We also tried the totem program that was pre-installed with the official image and installed Rockchip MPP for H.265/H.264 hardware video decoding:
|
sudo apt install librga2 librockchip–mpp1 gstreamer1.0–rockchip1 gstreamer1.0–plugins–bad gstreamer1.0–tools odroid@gnome–desktop:~$ gst–inspect–1.0 |grep Rockchip rockchipmpp: mpph264enc: Rockchip Mpp H264 Encoder rockchipmpp: mpph265enc: Rockchip Mpp H265 Encoder rockchipmpp: mppvp8enc: Rockchip Mpp VP8 Encoder rockchipmpp: mppjpegenc: Rockchip Mpp JPEG Encoder rockchipmpp: mppvideodec: Rockchip‘s MPP video decoder rockchipmpp: mppjpegdec: Rockchip’s MPP JPEG image decoder |
The video clip shows H.265 video playback is not perfectly smooth either with some dropped frames. The htop command reveals only 1 core of the CPU is being used for hardware video decoding.
The Wiki recommends testing hardware video decoding with GStreamer. So we tried that too:
|
gst–launch–1.0 filesrc location=Beauty_3840x2160_120fps_420_8bit_HEVC_MP4.mp4 ! qtdemux ! h265parse ! mppvideodec ! rkximagesink |
But the ODROID-Vu8S display was just green during video playback. So we asked Hardkernel and initially, they could not reproduce the issue with their own video and it also worked with our test video. But we eventually found out we could play the video fine with hardware video decoding using the command above with HDMI output.
Hardware video decoding also works (sort of) with the MIPI DSI display, but it’s a little more complex. We need to locate the plane number for “Esmart0-win0”:
|
$ sudo cat /sys/kernel/debug/dri/0/state | grep ‘plane\[‘ plane[57]: Smart1–win0 plane[79]: Smart0–win0 plane[101]: Esmart1–win0 plane[115]: Esmart0–win0 plane[129]: Cluster0–win0 plane[143]: Cluster1–win0 |
Now we can add the 115 plane to the command line:
|
gst–launch–1.0 filesrc location=Beauty_3840x2160_120fps_420_8bit_HEVC_MP4.mp4 ! qtdemux ! h265parse ! mppvideodec ! rkximagesink plane–id=115 |
The problem is that the video is rotated and scaled incorrectly. Only the darker parts would show with the video above, so we tested with another video.
So hardware video decoding with the ODROID-Vu8S MIPI display does work, but the video is just rendered properly due to scaling and orientation issue, and Hardkernel has yet to find a solution.
Storage Performance (eMMC, microSD card, and NVMe SSD)
We ran a test with iozone3 to test the read/write speed of each storage. The -i parameter was used to read directly from the disk and avoid reading from the cache:
|
odroid@gnome–desktop:~$ iozone –e –I –a –s 512M –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.489 $ Compiled for 64 bit mode. Build: linux
random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 524288 4 25659 35431 40120 39880 26014 34370 524288 16 63723 77055 87397 86320 46409 72131 524288 512 126298 127758 140568 140514 136658 123703 524288 1024 130849 131660 150881 150899 146499 130203 524288 16384 143485 141761 174894 175345 174619 141784 |
The read speed is around 174 MB/s and the write speed is 141 MB/s within the limits of eMMC 5.1 flash.
|
odroid@gnome–desktop:/media/sdcard$ sudo 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.489 $ Compiled for 64 bit mode. Build: linux
random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 4001 4148 11369 11365 11348 2598 102400 16 7933 8788 27763 27776 27739 6048 102400 512 19339 20857 59121 59295 59272 18864 102400 1024 21383 20480 60488 60593 60600 18375 102400 16384 22036 22220 67492 67649 67647 19187 |
A Sandisk Ultra 32GB Class 10 microSD card was used for testing. The read speed is approximately 67 MB/s and the write speed is 19 MB/s. That’s fine for a Class 10 SD card.
|
odroid@gnome–desktop:/media/nvme$ sudo 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.489 $ Compiled for 64 bit mode. Build: linux
random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 42604 72594 67778 68046 45038 71205 102400 16 122454 176403 158488 159796 120390 172478 102400 512 358798 368993 348561 349538 336942 368715 102400 1024 375695 381881 325273 343442 343842 381611 102400 16384 402410 404107 385306 386161 389643 402360 |
WD_BLACK SN770 NVMe SSD was used for testing the M.2 socket. The read speed is approximately 389MB/s and the write speed is 402 MB/s. Considering the ODROID-M1S relies on a 1-lane PCIe 2.0 interface that speed is expected, and even Hardkernel claims up to 400 MB/s. That is roughly equivalent to USB 3.0 speeds on the Raspberry Pi 5.
Networking performance (Ethernet and Wi-Fi)
We then used the iperf3 program to test gigabit Ethernet performance:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
odroid@gnome–desktop:~$ iperf3 –c 192.168.1.162 –f g Connecting to host 192.168.1.162, port 5201 [ 5] local 192.168.1.26 port 44022 connected to 192.168.1.162 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00–1.00 sec 114 MBytes 0.96 Gbits/sec 0 390 KBytes [ 5] 1.00–2.00 sec 113 MBytes 0.95 Gbits/sec 0 390 KBytes [ 5] 2.00–3.00 sec 112 MBytes 0.94 Gbits/sec 0 390 KBytes [ 5] 3.00–4.00 sec 112 MBytes 0.94 Gbits/sec 0 390 KBytes [ 5] 4.00–5.00 sec 113 MBytes 0.94 Gbits/sec 0 390 KBytes [ 5] 5.00–6.00 sec 112 MBytes 0.94 Gbits/sec 0 390 KBytes [ 5] 6.00–7.00 sec 113 MBytes 0.95 Gbits/sec 0 390 KBytes [ 5] 7.00–8.00 sec 113 MBytes 0.94 Gbits/sec 0 390 KBytes [ 5] 8.00–9.00 sec 112 MBytes 0.94 Gbits/sec 0 390 KBytes [ 5] 9.00–10.00 sec 112 MBytes 0.94 Gbits/sec 0 390 KBytes – – – – – – – – – – – – – – – – – – – – – – – – – [ ID] Interval Transfer Bitrate Retr [ 5] 0.00–10.00 sec 1.10 GBytes 0.94 Gbits/sec 0 sender [ 5] 0.00–10.04 sec 1.10 GBytes 0.94 Gbits/sec receiver
iperf Done. |
The data transmission speed was 0.94 Gbps per second, so no problem here.
While the ODROID-M1S does not come with built-in WiFi, it can take USB WiFi dongles including Hardkernel’s WiFi Module 5BK included in the package we received. So we tested the WiFi 5 module at 5 GHz connected to the 3BB modem router:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
odroid@gnome–desktop:~$ iperf3 –c 192.168.1.162 –f m Connecting to host 192.168.1.162, port 5201 [ 5] local 192.168.1.27 port 35092 connected to 192.168.1.162 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00–1.00 sec 27.8 MBytes 233 Mbits/sec 0 1.04 MBytes [ 5] 1.00–2.00 sec 26.2 MBytes 220 Mbits/sec 0 1.34 MBytes [ 5] 2.00–3.00 sec 26.2 MBytes 220 Mbits/sec 0 1.66 MBytes [ 5] 3.00–4.00 sec 27.5 MBytes 231 Mbits/sec 0 1.66 MBytes [ 5] 4.00–5.00 sec 27.5 MBytes 231 Mbits/sec 0 1.76 MBytes [ 5] 5.00–6.00 sec 26.2 MBytes 220 Mbits/sec 0 1.95 MBytes [ 5] 6.00–7.00 sec 27.5 MBytes 231 Mbits/sec 0 1.95 MBytes [ 5] 7.00–8.00 sec 27.5 MBytes 231 Mbits/sec 0 1.95 MBytes [ 5] 8.00–9.00 sec 26.2 MBytes 220 Mbits/sec 0 2.05 MBytes [ 5] 9.00–10.00 sec 27.5 MBytes 231 Mbits/sec 0 2.05 MBytes – – – – – – – – – – – – – – – – – – – – – – – – – [ ID] Interval Transfer Bitrate Retr [ 5] 0.00–10.00 sec 270 MBytes 227 Mbits/sec 0 sender [ 5] 0.00–10.05 sec 267 MBytes 223 Mbits/sec receiver
iperf Done. |
The average bitrate is 227 Mbps, in line with what we would expect with this setup.
Power consumption
The power consumption of the ODROID-M1S SBC was tested with a USB power meter:
- Power off – 0 Watt
- Idle – 1.955 Watts (connected to 8-inch screen, WiFi only)
- YouTube 4K video in Chromium (full screen) – 4.5 Watts on average
- Full load test on all four cores – 6 Watts on average
Conclusion
Our tests of the ODROID-M1S with the official Ubuntu 20.04 image from Hardkernel showed a good performance considering the Rockchip RK3566 SoC used with decent reading and writing speeds of both NVMe SSD and eMMC flash, and networking is working as expected both for gigabit Ethernet and WiiI through the WiFi Module 5BK included in our review kit.
Both hardware video decoding (via HDMI) and 3D graphics acceleration are working with GStreamer and glmark2-es2 respectively, but neither has been implemented in Chromium with both WebGL and YouTube video playback showing poor performance. Hardware video decoding is currently not working properly with the ODROID-Vu8S MIPI display due to scaling and orientation issues. Hopefully, those issues will be fixed in future OS images.
We’d like to thank Hardkernel for sending the ODROID-M1S board and accessories for review. The ODROID-M1S board with 8GB RAM and 64GB eMMC flash reviewed here can be purchased for $59 on Hardkernel website and our review kit also includes the ODROID-Vu8S 8-inch touchscreen display ($39), a $9 UPS module, and the WiFi module 5BK ($8.90) which you can select during the ordering process.
CNXSoft: This review is a translation from the original article on CNX Software Thailand by Arnon Thongtem, edited by Suthinee Kerdkaew.
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.
