Test ODROID-M1S – Partie 2 : benchmarks et tests de fonctionnalités Ubuntu 20.04

Plus d’un mois s’est écoulé depuis notre déballage et notre test rapide Ubuntu 20.04 du SBC ODROID-M1S et nous avons maintenant eu le temps de tester plus de fonctionnalités et d’exécuter des tests de performance en utilisant la version officielle Ubuntu 20.04.6 LTS de Hardkernel. Un utilisateur a mentionné qu’Ubuntu 22.04 est pris en charge, mais qu’il est pris en charge par un tiers et que nous avons utilisé l’image officielle pour les tests.

Les résultats de nos tests montreront les performances et les fonctionnalités prises en charge du SBC ODROID-M1S alimenté par Rockchip RK3566 lors de l’exécution d’Ubuntu 20.04. Lisez la suite pour découvrir à quel point le tableau fonctionne.

Tests ODROID-M1S

Commençons par évaluer l’ODROID-M1S avec le script sbc-bench.sh de Thomas Kaiser :

</p><br /> <p>odroid@gnome-desktop:~/sbc-bench$ sudo ./sbc-bench.sh -r Début de l’test du matériel/logiciel à des fins d’test… Charge moyenne et/ou utilisation du processeur trop élevée (trop d’activité en arrière-plan). En attente… sbc-bench v0.9.60 Installation des outils nécessaires, tinymembench, ramlat, mhz, cpufetch, cpuminer. Fait. Vérification de cpufreq OPP… Terminé. Exécution de tinymembench. Fait. Exécution du testeur de latence RAM. Fait. Exécution du benchmark OpenSSL. Fait. Exécution d’un benchmark 7-zip. Fait. Test de throttling : mise en chauffe de l’appareil, encore 5 minutes d’attente. Fait. Vérification à nouveau de cpufreq OPP. Terminé (16 minutes se sont écoulées). Validation des résultats : * Vitesse d’horloge maximale du processeur annoncée par rapport à celle mesurée : -1,4 % avant, -1,8 % après -> https://tinyurl.com/32w9rr94 * Activité en arrière-plan (% système) OK # Hardkernel ODROID-M1S Testé avec sbc-bench v0.9.60 le dimanche 21 janvier 2024 10:14:59 +0700. ### Informations générales : Informations fournies par cpufetch : SoC : Rockchip RK3566 Technologie : 22 nm Microarchitecture : Cortex-A55 Fréquence maximale : 1,800 GHz Cœurs : 4 cœurs Caractéristiques : NEON, SHA1, SHA2, AES, CRC32 Performances maximales : 57,60 GFLOP/s Rockchip RK3566 (35662000), noyau : aarch64, pays utilisateur : arm64 Topologie du processeur sysfs (clusters, membres cpufreq, vitesses d’horloge) cpufreq min max Politique de cluster du processeur vitesse vitesse type de cœur 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 Ko de RAM disponible ### Gouverneurs/politiques (performances par rapport à la consommation inactive) : Paramètres d’origine du gouverneur : cpufreq-policy0 : performances / 1 800 MHz (performances d’économie d’énergie de l’espace utilisateur à la demande interactive et conservatrice / 408 600 816 1104 1416 1608 1800) fde60000.gpu : performances / 800 MHz (vdec2_ondemand venc_ondemand performances d’économie d’énergie de l’espace utilisateur simple_ondemand / 200 300 400 600 700 800) fdf40 000.rkvenc : performances / 400 MHZ (VDec2_ondemand Venc_ondemand Userspace PowerSave Performance Simple_ondemand / 297 400) FDF80200.rkvdec: Performance / 400 MHz (VDEC2_ondemand Venc_ondemand Userspace Power Performance_ondemand / 297 400) Paramètres de réglage: CPUFRESS. Performance / 800 MHz fdf40000.rkvenc : performances / 400 MHz fdf80200.rkvdec : performances / 400 MHz État des politiques liées aux performances trouvées ci-dessous /sys : /sys/devices/platform/fde60000.gpu/power_policy : [coarse_demand] toujours_on /sys/module/pcie_aspm/parameters/policy : par défaut [performance] powersave powersupersave ### Vitesses d’horloge (inactif ou chauffé) : Avant à 44,4°C : cpu0 (Cortex-A55) : OPP : 1800, Mesuré : 1775 (-1,4%) Après à 59,4°C : cpu0 (Cortex-A55 ) : OPP : 1 800, Mesuré : 1 767 (-1,8 %) ### Performance de base * memcpy : 2 906,9 Mo/s, memchr : 3 139,8 Mo/s, memset : 7952,8 Mo/s * Latence 16 M : 180,7 183,8 181,6 183,0 180,2 181,9 244,0 451,9 * Latence 128M : 217,3 194,0 190,3 193,6 189,0 194,1 251,4 482,6 * MIPS 7-zip (3 exécutions consécutives) : 4581, 4575, 4612 (4590 en moyenne), monothread : 1322 * `aes -256-cbc 156417.72k 398262.61 k 654734,34k 780968,62k 827375,62k 827000,09k` * `aes-256-cbc 157146,64k 398160,17k 653565,10k 780867,58k 826146,82k 827419,31k ` ### Périphériques de stockage : * 232,9 Go SSD « WD_BLACK SN770 250 Go » sous /dev/nvme0 : Vitesse 5GT/s (rétrogradée), Largeur x1 (rétrogradée), 0% d’usure, température du disque : 47°C * 58,2 Go « MMC64G » HS200 eMMC 5.1 comme /dev/mmcblk0 : date 05/2023, manfid/oemid : 0x000032/0x0101, hw/fw rev : 0x0/0x0300000000000000 ### Versions du logiciel : * Ubuntu 20.04.6 LTS * Compilateur : /usr/bin/gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0 / aarch64-linux-gnu * OpenSSL 1.1.1f, construit le 31 mars 2020 ### Informations sur le noyau : * `/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` * Vulnérabilité Spectre v1 : atténuation ; __désinfection du pointeur utilisateur * Kernel 5.10.0-odroid-arm64 / CONFIG_HZ=300 Le noyau 5.10.0 n’est pas la dernière version 5.10.208 LTS publiée le 15/01/2024. Temps de charge CPU %cpu %sys %usr %nice %io %irq Temp 10:15:06 : 1800 MHz 3,54 14 % 1 % 11 % 0 % 0 % 0 % 53,8°C 10:16:06 : 1800 MHz 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

Selon les résultats des tests, la température du processeur a atteint jusqu’à 59,4 °C sous charge et aucune limitation du processeur ne s’est produite dans une pièce avec une température ambiante d’environ 29 °C. Les résultats memcpy et memset étaient similaires à ceux de l’ODROID-N2+, tandis que les performances 7-zip de l’ODROID-M1S étaient quelque peu similaires à celles du Raspberry Pi 4.

Performances de navigation Web avec Speedometer 2.0

Nous examinons les performances de navigation Web avec Speedometer 2.0 dans Chromium et Firefox :

Les résultats des tests dans Speedometer 2.0 sont similaires à ceux de la carte Raspberry Pi 4, les valeurs de Chromium étant environ 30 % plus élevées que dans Firefox.

Encore une fois, les résultats dans Firefox étaient similaires à ceux du Raspberry Pi 4 (testé il y a plus de quatre ans).

Accélération graphique 3D sur ODROID-M1S SBC exécutant Ubuntu 20.04

Nous avons testé l’accélération graphique 3D avec glmark2-es2-wayland avec la carte connectée à l’ODROID-Vu8S 8 pouces.

Sortie terminale :

</p><br /> <p>odroid@gnome-desktop:~$ glmark2-es2-wayland ====================================== ================== glmark2 2021.02 =============================== ========================= Informations OpenGL GL_VENDOR : ARM GL_RENDERER : Mali-G52 GL_VERSION : OpenGL ES 3.2 v1.r25p0-01eac0.9771aca0686ac609bad539142d5c7fce === =================================================== ==<br /><br /> [build] use-vbo=false:FPS : 442 FrameTime : 2,262 ms<br /><br /> [build] use-vbo=true:FPS : 628 FrameTime : 1,592 ms<br /><br /> [texture] texture-filter=le plus proche : FPS : 692 FrameTime : 1,445 ms<br /><br /> [texture] texture-filter=linéaire : FPS : 690 FrameTime : 1,449 ms<br /><br /> [texture] texture-filter=mipmap : FPS : 708 FrameTime : 1,412 ms<br /><br /> [shading] shading=gouraud : FPS : 467 FrameTime : 2,141 ms<br /><br /> [shading] shading=blinn-phong-inf : FPS : 472 FrameTime : 2,119 ms<br /><br /> [shading] shading=phong : FPS : 427 FrameTime : 2,342 ms<br /><br /> [shading] shading=cel : FPS : 421 FrameTime : 2,375 ms<br /><br /> [bump] bump-render=high-poly : FPS : 231 FrameTime : 4,329 ms<br /><br /> [bump] bump-render=normals : FPS : 772 FrameTime : 1,295 ms<br /><br /> [bump] bump-render=hauteur : FPS : 730 FrameTime : 1,370 ms<br /><br /> [effect2d] noyau = 0,1,0;1,-4,1;0,1,0; : FPS : 442 FrameTime : 2,262 ms<br /><br /> [effect2d] noyau = 1,1,1,1,1;1,1,1,1,1;1,1,1,1,1; : FPS : 177 FrameTime : 5,650 ms<br /><br /> [pulsar] light=false:quads=5:texture=false : FPS : 692 FrameTime : 1,445 ms<br /><br /> [desktop] Blur-radius=5:effect=blur:passes=1:separable=true:windows=4 : FPS : 205 FrameTime : 4,878 ms<br /><br /> [desktop] effect=shadow:windows=4 : FPS : 418 FrameTime : 2,392 ms<br /><br /> [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map : FPS : 57 FrameTime : 17,544 ms<br /><br /> [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata : FPS : 57 FrameTime : 17,544 ms<br /><br /> [buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map : FPS : 57 FrameTime : 17,544 ms<br /><br /> [ideas] vitesse=durée : FPS : 190 FrameTime : 5,263 ms<br /><br /> [jellyfish] <par défaut> : FPS : 370 FrameTime : 2,703 ms<br /><br /> [terrain] <par défaut> : FPS : 26 FrameTime : 38,462 ms<br /><br /> [shadow] <par défaut> : FPS : 228 FrameTime : 4,386 ms<br /><br /> [refract] <par défaut> : FPS : 58 FrameTime : 17,241 ms<br /><br /> [conditionals] fragment-steps=0:vertex-steps=0 : FPS : 657 FrameTime : 1,522 ms<br /><br /> [conditionals] fragment-steps=5:vertex-steps=0 : FPS : 583 FrameTime : 1,715 ms<br /><br /> [conditionals] fragment-steps=0:vertex-steps=5 : FPS : 600 FrameTime : 1,667 ms<br /><br /> [function] fragment-complexity=low:fragment-steps=5 : FPS : 888 FrameTime : 1,126 ms<br /><br /> [function] fragment-complexity=medium:fragment-steps=5 : FPS : 883 FrameTime : 1,133 ms<br /><br /> [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5 : FPS : 1064 FrameTime : 0,940 ms<br /><br /> [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5 : FPS : 1059 FrameTime : 0,944 ms<br /><br /> [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5 : FPS : 999 FrameTime : 1,001 ms ========================== ============================== Score glmark2 : 496 ================ ========================================

Le score est de 496 ou légèrement inférieur à celui du Raspberry Pi 4 et nettement inférieur aux 2036 points du Raspberry Pi 5.

Nous vérifions ensuite si l’accélération graphique 3D fonctionne également dans Chromium avec la démo d’aquarium WebGL.

Le résultat était un peu décevant avec 1 FPS avec 500 poissons testés à la fois dans Chromium et Firefox. L’image officielle ne prend donc pas en charge WebGL et, espérons-le, cela sera corrigé dans les prochaines versions de l’image Ubuntu.

Lecture vidéo YouTube

Nous avons démarré la lecture de vidéos YouTube en résolution 4K et 30 ips, et la vidéo était impossible à regarder. Lorsque l’on examine les statistiques, la baisse de la fréquence d’images était supérieure à 50 % en raison de l’accélération matérielle non prise en charge dans le navigateur Web.

Nous avons réduit nos attentes et notre résolution à 1080p30, mais le résultat n’était pas bien meilleur.

Ce n’est que lorsque nous avons baissé la résolution à 720p30 (1280×720) que la vidéo est devenue fluide, avec des problèmes évidents lors de la lecture des fichiers. Il y avait encore plus de 10 % d’images perdues. Dans tous les cas, cela signifie que le décodage du CPU devrait être possible à une résolution maximale de 720p30 (1280×720 à 30 Hz).

Nous avons également essayé le programme totem préinstallé avec l’image officielle et installé Rockchip MPP pour le décodage vidéo matériel H.265/H.264 :

</p><br /> <p>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 Encodeur rockchipmpp : mpph265enc : Encodeur Rockchip Mpp H265 rockchipmpp : mppvp8enc : Encodeur Rockchip Mpp VP8 rockchipmpp : mppjpegenc : Encodeur Rockchip Mpp JPEG rockchipmpp : mppvideodec : Décodeur vidéo MPP de Rockchip rockchipmpp : mppjpegdec : Décodeur d’image MPP JPEG de Rockchip

Le clip vidéo montre que la lecture vidéo H.265 n’est pas non plus parfaitement fluide avec quelques pertes d’images. La commande htop révèle qu’un seul cœur du processeur est utilisé pour le décodage vidéo matériel.

Le Wiki recommande de tester le décodage vidéo matériel avec GStreamer. Alors nous avons essayé ça aussi :

</p><br /> <p>emplacement gst-launch-1.0 filesrc=Beauty_3840x2160_120fps_420_8bit_HEVC_MP4.mp4 ! qtdemux ! h265analyser ! mppvideodec ! rkximagesink

Mais l’écran de l’ODROID-Vu8S était juste vert pendant la lecture vidéo. Nous avons donc demandé à Hardkernel et au départ, ils ne pouvaient pas reproduire le problème avec leur propre vidéo et cela a également fonctionné avec notre vidéo de test. Mais nous avons finalement découvert que nous pouvions lire la vidéo correctement avec le décodage vidéo matériel en utilisant la commande ci-dessus avec une sortie HDMI.

Le décodage vidéo matériel fonctionne également (en quelque sorte) avec l’écran MIPI DSI, mais c’est un peu plus complexe. Nous devons localiser le numéro d’avion pour « Esmart0-win0 » :

</p><br /> <p>$ sudo cat /sys/kernel/debug/dri/0/state | grep ‘avion\[‘<br /><br /> plane[57]: Avion Smart1-win0[79]: Plan Smart0-win0[101]: Avion Esmart1-win0[115]: avion Esmart0-win0[129]: Plan Cluster0-win0[143]: Cluster1-win0

Nous pouvons maintenant ajouter le plan 115 à la ligne de commande :

</p><br /> <p>emplacement gst-launch-1.0 filesrc=Beauty_3840x2160_120fps_420_8bit_HEVC_MP4.mp4 ! qtdemux ! h265analyser ! mppvideodec ! rkximagesink plan-id = 115

Le problème est que la vidéo n’est pas pivotée et mise à l’échelle de manière incorrecte. Seules les parties les plus sombres seraient visibles dans la vidéo ci-dessus, nous avons donc testé avec une autre vidéo.

Ainsi, le décodage vidéo matériel avec l’écran MIPI ODROID-Vu8S fonctionne, mais la vidéo n’est pas restituée correctement en raison de problèmes de mise à l’échelle et d’orientation, et Hardkernel n’a pas encore trouvé de solution.

Performances de stockage (eMMC, carte microSD et SSD NVMe)

Nous avons effectué un test avec iozone3 pour tester la vitesse de lecture/écriture de chaque stockage. Le paramètre -i était utilisé pour lire directement depuis le disque et éviter de lire depuis le cache :

</p><br /> <p>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 : Test de performances du fichier I/ O Version $Révision : 3,489 $ Compilé pour le mode 64 bits. Construction : Linux aléatoire aléatoire bkwd record stride ko reclen écriture réécriture lecture relecture lecture écriture lecture réécriture lecture 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

La vitesse de lecture est d’environ 174 Mo/s et la vitesse d’écriture est de 141 Mo/s dans les limites du flash eMMC 5.1.

</p><br /> <p>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 : test de performances de la version d’E/S de fichier $Révision : 3,489 $ Compilé pour le mode 64 bits. Construction : Linux aléatoire aléatoire bkwd record stride ko reclen écriture réécriture lecture relecture lecture écriture lecture réécriture lecture 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

Une carte microSD Sandisk Ultra 32 Go Classe 10 a été utilisée pour les tests. La vitesse de lecture est d’environ 67 Mo/s et la vitesse d’écriture est de 19 Mo/s. C’est bien pour une carte SD de classe 10.

</p><br /> <p>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 : test de performances de la version d’E/S de fichier $Révision : 3,489 $ Compilé pour le mode 64 bits. Build: Linux aléatoire aléatoire bkwd record stride ko reclen écriture réécriture lecture relecture lecture écriture lecture réécriture lecture fwrite frewrite fread freread 102400 4 42604 72594 67778 68046 45038 71205 102400 16 122454 176403 158488 159796 1 20390 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

Le SSD NVMe WD_BLACK SN770 a été utilisé pour tester le socket M.2. La vitesse de lecture est d’environ 389 Mo/s et la vitesse d’écriture est de 402 Mo/s. Étant donné que l’ODROID-M1S repose sur une interface PCIe 2.0 à 1 voie, cette vitesse est attendue, et même Hardkernel revendique jusqu’à 400 Mo/s. Cela équivaut à peu près aux vitesses USB 3.0 sur le Raspberry Pi 5.

Performances réseau (Ethernet et Wi-Fi)

Nous avons ensuite utilisé le programme iperf3 pour tester les performances Gigabit Ethernet :

</p><br /> <p>odroid@gnome-desktop:~$ iperf3 -c 192.168.1.162 -fg Connexion à l’hôte 192.168.1.162, port 5201<br /><br /> [ 5] port local 192.168.1.26 44022 connecté au port 192.168.1.162 5201<br /><br /> [ ID] Retr Cwnd de débit binaire de transfert d’intervalle<br /><br /> [ 5] 0,00-1,00 s 114 Mo 0,96 Gbits/s 0 390 Ko<br /><br /> [ 5] 1,00-2,00 s 113 Mo 0,95 Gbits/s 0 390 Ko<br /><br /> [ 5] 2,00-3,00 s 112 Mo 0,94 Gbits/s 0 390 Ko<br /><br /> [ 5] 3,00-4,00 s 112 Mo 0,94 Gbits/s 0 390 Ko<br /><br /> [ 5] 4,00-5,00 s 113 Mo 0,94 Gbits/s 0 390 Ko<br /><br /> [ 5] 5,00-6,00 s 112 Mo 0,94 Gbits/s 0 390 Ko<br /><br /> [ 5] 6,00-7,00 s 113 Mo 0,95 Gbits/s 0 390 Ko<br /><br /> [ 5] 7,00-8,00 s 113 Mo 0,94 Gbits/s 0 390 Ko<br /><br /> [ 5] 8,00-9,00 s 112 Mo 0,94 Gbits/s 0 390 Ko<br /><br /> [ 5] 9,00-10,00 s 112 Mo 0,94 Gbits/s 0 390 Ko – – – – – – – – – – – – – – – – – – – – – – -<br /><br /> [ ID] Retrait du débit binaire de transfert par intervalle<br /><br /> [ 5] 0,00-10,00 s 1,10 Go 0,94 Gbits/s 0 expéditeur<br /><br /> [ 5] 0,00-10,04 sec 1,10 Go 0,94 Gbits/sec iperf du récepteur Terminé.

La vitesse de transmission des données était de 0,94 Gbit/s par seconde, donc pas de problème ici.

Bien que l’ODROID-M1S ne soit pas livré avec le WiFi intégré, il peut accepter des dongles WiFi USB, notamment le module WiFi 5BK de Hardkernel inclus dans le package que nous avons reçu. Nous avons donc testé le module WiFi 5 à 5 GHz connecté au modem routeur 3BB :

</p><br /> <p>odroid@gnome-desktop:~$ iperf3 -c 192.168.1.162 -fm Connexion à l’hôte 192.168.1.162, port 5201<br /><br /> [ 5] port local 192.168.1.27 35092 connecté au port 192.168.1.162 5201<br /><br /> [ ID] Retr Cwnd de débit binaire de transfert d’intervalle<br /><br /> [ 5] 0,00-1,00 s 27,8 Mo 233 Mbits/s 0 1,04 Mo<br /><br /> [ 5] 1,00-2,00 s 26,2 Mo 220 Mbits/s 0 1,34 Mo<br /><br /> [ 5] 2,00-3,00 s 26,2 Mo 220 Mbits/s 0 1,66 Mo<br /><br /> [ 5] 3,00-4,00 s 27,5 Mo 231 Mbits/s 0 1,66 Mo<br /><br /> [ 5] 4,00-5,00 s 27,5 Mo 231 Mbits/s 0 1,76 Mo<br /><br /> [ 5] 5,00-6,00 s 26,2 Mo 220 Mbits/s 0 1,95 Mo<br /><br /> [ 5] 6,00-7,00 s 27,5 Mo 231 Mbits/s 0 1,95 Mo<br /><br /> [ 5] 7,00-8,00 s 27,5 Mo 231 Mbits/s 0 1,95 Mo<br /><br /> [ 5] 8,00-9,00 s 26,2 Mo 220 Mbits/s 0 2,05 Mo<br /><br /> [ 5] 9h00-10h00 s 27,5 Mo 231 Mbits/s 0 2,05 Mo – – – – – – – – – – – – – – – – – – – – – – – -<br /><br /> [ ID] Retrait du débit binaire de transfert par intervalle<br /><br /> [ 5] 0,00-10,00 s 270 Mo 227 Mbits/s 0 expéditeur<br /><br /> [ 5] 0,00-10,05 s 267 Mo 223 Mbits/s iperf du récepteur Terminé.

Le débit moyen est de 227 Mbps, conforme à ce à quoi on pourrait s’attendre avec cette configuration.

Consommation d’énergie

La consommation électrique du SBC ODROID-M1S a été testée avec un wattmètre USB :

• Mise hors tension – 0 Watt
• Inactif – 1,955 watts (connecté à un écran de 8 pouces, WiFi uniquement)
• Vidéo YouTube 4K en Chromium (plein écran) – 4,5 Watts en moyenne
• Test à pleine charge sur les quatre cœurs – 6 watts en moyenne

Conclusion

Nos tests de l’ODROID-M1S avec l’image officielle Ubuntu 20.04 de Hardkernel ont montré de bonnes performances compte tenu du SoC Rockchip RK3566 utilisé avec des vitesses de lecture et d’écriture décentes du SSD NVMe et du flash eMMC, et la mise en réseau fonctionne comme prévu à la fois pour Gigabit Ethernet et WiiI via le module WiFi 5BK inclus dans notre kit de révision.

Le décodage vidéo matériel (via HDMI) et l’accélération graphique 3D fonctionnent respectivement avec GStreamer et glmark2-es2, mais aucun n’a été implémenté dans Chromium, la lecture vidéo WebGL et YouTube affichant des performances médiocres. Le décodage vidéo matériel ne fonctionne actuellement pas correctement avec l’écran MIPI ODROID-Vu8S en raison de problèmes de mise à l’échelle et d’orientation. Espérons que ces problèmes seront résolus dans les futures images du système d’exploitation.

Nous tenons à remercier Hardkernel pour avoir envoyé la carte ODROID-M1S et ses accessoires pour test. La carte ODROID-M1S avec 8 Go de RAM et 64 Go de flash eMMC examinée ici peut être achetée pour 59 $ sur le site Web Hardkernel et notre kit d’évaluation comprend également l’écran tactile ODROID-Vu8S de 8 pouces (39 $), un module UPS à 9 $ et le module WiFi. 5BK (8,90 $) que vous pouvez sélectionner lors du processus de commande.

Retrouvez l’histoire de Raspberry Pi dans cette vidéo :