Odroid M1 sbc_bench

Post Reply
zupet
Posts: 213
Joined: Tue Dec 26, 2017 11:13 pm
languages_spoken: korean,english
ODROIDs: HC1
Has thanked: 8 times
Been thanked: 57 times
Contact:

Odroid M1 sbc_bench

Post by zupet »

Code: Select all

odroid@server:~$ sudo /bin/bash ./sbc-bench.sh -c
[sudo] password for odroid: 

sbc-bench v0.9.3

Installing needed tools. This may take some time...
 Done.
Checking cpufreq OPP. Done (results will be available in 17-23 minutes).
Executing tinymembench. Done.
Executing OpenSSL benchmark. Done.
Executing 7-zip benchmark. Done.
Executing cpuminer. 5 more minutes to wait. Done.
Checking cpufreq OPP. Done (18 minutes elapsed).

Memory performance:
memcpy: 3073.4 MB/s 
memset: 6224.0 MB/s 

Cpuminer total scores (5 minutes execution): 7.15,7.14,7.13,7.11,7.09 kH/s

7-zip total scores (3 consecutive runs): 5004,5006,5012

OpenSSL results:
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc     185784.56k   534255.42k  1023207.00k  1325274.79k  1448266.41k  1457875.63k
aes-128-cbc     185531.74k   533686.25k  1018522.03k  1322791.94k  1447327.06k  1457853.78k
aes-192-cbc     172692.98k   472499.54k   819806.81k  1010780.84k  1084489.73k  1090185.90k
aes-192-cbc     172632.89k   472248.77k   819244.97k  1010789.38k  1084282.20k  1089841.83k
aes-256-cbc     170462.23k   433133.80k   710505.39k   845103.45k   895262.72k   898651.48k
aes-256-cbc     168557.24k   430297.45k   707917.31k   843687.94k   894713.86k   898569.56k

Unable to upload full test results. Please copy&paste the below stuff to pastebin.com and
provide the URL. Check the output for throttling and swapping please.


sbc-bench v0.9.3 Hardkernel ODROID-M1 (Mon, 04 Apr 2022 08:17:14 +0000)

Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.4 LTS
Release:	20.04
Codename:	focal
Architecture:	arm64

/usr/bin/gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0

Uptime: 08:17:15 up 5 min,  1 user,  load average: 1.00, 0.56, 0.23

Linux 4.19.219-realtek-odroid-arm64 (server) 	04/04/22 	_aarch64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.48    0.00    2.71    0.02    0.00   78.79

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1          46.95      1085.42       703.59         0.00     338544     219450          0

              total        used        free      shared  buff/cache   available
Mem:          7.3Gi       130Mi       7.1Gi       1.0Mi        80Mi       7.1Gi
Swap:            0B          0B          0B


##########################################################################

Checking cpufreq OPP (Cortex-A55):

Cpufreq OPP: 1992    Measured: 1930 (1927.475/1929.203/1928.857)
Cpufreq OPP: 1800    Measured: 1770 (1769.446/1769.465/1768.321)
Cpufreq OPP: 1608    Measured: 1605 (1604.381/1604.780/1603.644)
Cpufreq OPP: 1416    Measured: 1420 (1416.925/1417.080/1417.827)
Cpufreq OPP: 1104    Measured: 1120 (1118.712/1120.593/1119.561)
Cpufreq OPP:  816    Measured:  810 (809.963/810.250/810.360)
Cpufreq OPP:  600    Measured:  595 (594.343/594.163/590.620)
Cpufreq OPP:  408    Measured:  405 (402.033/402.100/402.473)

##########################################################################

Executing benchmark on cpu0 (Cortex-A55):

tinymembench v0.4.9 (simple benchmark for memory throughput and latency)

==========================================================================
== Memory bandwidth tests                                               ==
==                                                                      ==
== Note 1: 1MB = 1000000 bytes                                          ==
== Note 2: Results for 'copy' tests show how many bytes can be          ==
==         copied per second (adding together read and writen           ==
==         bytes would have provided twice higher numbers)              ==
== Note 3: 2-pass copy means that we are using a small temporary buffer ==
==         to first fetch data into it, and only then write it to the   ==
==         destination (source -> L1 cache, L1 cache -> destination)    ==
== Note 4: If sample standard deviation exceeds 0.1%, it is shown in    ==
==         brackets                                                     ==
==========================================================================

 C copy backwards                                     :   2074.8 MB/s (1.2%)
 C copy backwards (32 byte blocks)                    :   2027.6 MB/s
 C copy backwards (64 byte blocks)                    :   1604.8 MB/s
 C copy                                               :   3078.9 MB/s
 C copy prefetched (32 bytes step)                    :   1816.2 MB/s (0.4%)
 C copy prefetched (64 bytes step)                    :   2539.3 MB/s (0.1%)
 C 2-pass copy                                        :   1873.8 MB/s (0.1%)
 C 2-pass copy prefetched (32 bytes step)             :   1161.2 MB/s (0.3%)
 C 2-pass copy prefetched (64 bytes step)             :   1700.1 MB/s
 C fill                                               :   6224.7 MB/s
 C fill (shuffle within 16 byte blocks)               :   6223.6 MB/s
 C fill (shuffle within 32 byte blocks)               :   6223.7 MB/s
 C fill (shuffle within 64 byte blocks)               :   6223.0 MB/s
 ---
 standard memcpy                                      :   3073.4 MB/s
 standard memset                                      :   6224.0 MB/s
 ---
 NEON LDP/STP copy                                    :   3072.1 MB/s
 NEON LDP/STP copy pldl2strm (32 bytes step)          :   2398.2 MB/s
 NEON LDP/STP copy pldl2strm (64 bytes step)          :   2940.7 MB/s
 NEON LDP/STP copy pldl1keep (32 bytes step)          :   2293.1 MB/s
 NEON LDP/STP copy pldl1keep (64 bytes step)          :   3119.5 MB/s
 NEON LD1/ST1 copy                                    :   3070.4 MB/s
 NEON STP fill                                        :   6228.1 MB/s
 NEON STNP fill                                       :   3521.0 MB/s (1.2%)
 ARM LDP/STP copy                                     :   3072.1 MB/s
 ARM STP fill                                         :   6227.1 MB/s
 ARM STNP fill                                        :   3528.6 MB/s (1.3%)

==========================================================================
== Memory latency test                                                  ==
==                                                                      ==
== Average time is measured for random memory accesses in the buffers   ==
== of different sizes. The larger is the buffer, the more significant   ==
== are relative contributions of TLB, L1/L2 cache misses and SDRAM      ==
== accesses. For extremely large buffer sizes we are expecting to see   ==
== page table walk with several requests to SDRAM for almost every      ==
== memory access (though 64MiB is not nearly large enough to experience ==
== this effect to its fullest).                                         ==
==                                                                      ==
== Note 1: All the numbers are representing extra time, which needs to  ==
==         be added to L1 cache latency. The cycle timings for L1 cache ==
==         latency can be usually found in the processor documentation. ==
== Note 2: Dual random read means that we are simultaneously performing ==
==         two independent memory accesses at a time. In the case if    ==
==         the memory subsystem can't handle multiple outstanding       ==
==         requests, dual random read has the same timings as two       ==
==         single reads performed one after another.                    ==
==========================================================================

block size : single random read / dual random read
      1024 :    0.0 ns          /     0.0 ns 
      2048 :    0.0 ns          /     0.0 ns 
      4096 :    0.0 ns          /     0.0 ns 
      8192 :    0.0 ns          /     0.0 ns 
     16384 :    0.7 ns          /     1.4 ns 
     32768 :    4.5 ns          /     6.8 ns 
     65536 :    9.8 ns          /    13.5 ns 
    131072 :   12.4 ns          /    16.3 ns 
    262144 :   14.7 ns          /    17.7 ns 
    524288 :   17.8 ns          /    20.4 ns 
   1048576 :   79.4 ns          /   117.9 ns 
   2097152 :  112.9 ns          /   150.2 ns 
   4194304 :  130.4 ns          /   161.5 ns 
   8388608 :  146.6 ns          /   176.4 ns 
  16777216 :  155.9 ns          /   185.8 ns 
  33554432 :  161.4 ns          /   193.2 ns 
  67108864 :  164.8 ns          /   196.6 ns 

##########################################################################

Executing benchmark twice on cluster 0 (Cortex-A55)

OpenSSL 1.1.1f, built on 31 Mar 2020
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc     185784.56k   534255.42k  1023207.00k  1325274.79k  1448266.41k  1457875.63k
aes-128-cbc     185531.74k   533686.25k  1018522.03k  1322791.94k  1447327.06k  1457853.78k
aes-192-cbc     172692.98k   472499.54k   819806.81k  1010780.84k  1084489.73k  1090185.90k
aes-192-cbc     172632.89k   472248.77k   819244.97k  1010789.38k  1084282.20k  1089841.83k
aes-256-cbc     170462.23k   433133.80k   710505.39k   845103.45k   895262.72k   898651.48k
aes-256-cbc     168557.24k   430297.45k   707917.31k   843687.94k   894713.86k   898569.56k

##########################################################################

Executing benchmark single-threaded on cpu0 (Cortex-A55)

7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=C,Utf16=off,HugeFiles=on,64 bits,4 CPUs LE)

LE
CPU Freq: - - - - - - - 1024000000 2048000000

RAM size:    7465 MB,  # CPU hardware threads:   4
RAM usage:    435 MB,  # Benchmark threads:      1

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:       1086   100   1057   1057  |      22107   100   1888   1888
23:       1017   100   1037   1037  |      21640   100   1873   1873
24:        964   100   1037   1037  |      21126   100   1855   1855
25:        900   100   1029   1029  |      20510   100   1826   1826
----------------------------------  | ------------------------------
Avr:             100   1040   1040  |              100   1860   1860
Tot:             100   1450   1450

##########################################################################

Executing benchmark 3 times multi-threaded

7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=C,Utf16=off,HugeFiles=on,64 bits,4 CPUs LE)

LE
CPU Freq: 64000000 64000000 - - - - - - -

RAM size:    7465 MB,  # CPU hardware threads:   4
RAM usage:    882 MB,  # Benchmark threads:      4

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:       2980   348    834   2899  |      83364   396   1798   7112
23:       2944   364    824   3000  |      81320   394   1785   7036
24:       2810   368    822   3022  |      79344   395   1764   6965
25:       2761   379    831   3153  |      76898   395   1731   6844
----------------------------------  | ------------------------------
Avr:             365    828   3019  |              395   1769   6989
Tot:             380   1299   5004

7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=C,Utf16=off,HugeFiles=on,64 bits,4 CPUs LE)

LE
CPU Freq: 64000000 - 64000000 - - - - - -

RAM size:    7465 MB,  # CPU hardware threads:   4
RAM usage:    882 MB,  # Benchmark threads:      4

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:       3037   354    836   2955  |      83435   395   1800   7118
23:       2883   360    816   2938  |      81136   393   1784   7020
24:       2830   369    826   3044  |      79216   394   1763   6954
25:       2711   374    827   3096  |      77755   398   1739   6920
----------------------------------  | ------------------------------
Avr:             364    826   3008  |              395   1772   7003
Tot:             380   1299   5006

7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=C,Utf16=off,HugeFiles=on,64 bits,4 CPUs LE)

LE
CPU Freq: - - - 64000000 - - - - -

RAM size:    7465 MB,  # CPU hardware threads:   4
RAM usage:    882 MB,  # Benchmark threads:      4

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:       2969   346    834   2889  |      84442   399   1806   7204
23:       2900   361    819   2956  |      81775   396   1785   7076
24:       2893   375    830   3111  |      78447   391   1761   6887
25:       2759   379    830   3151  |      76671   393   1735   6824
----------------------------------  | ------------------------------
Avr:             365    828   3026  |              395   1772   6997
Tot:             380   1300   5012

Compression: 3019,3008,3026
Decompression: 6989,7003,6997
Total: 5004,5006,5012

##########################################################################

** cpuminer-multi 1.3.3 by tpruvot@github **
BTC donation address: 1FhDPLPpw18X4srecguG3MxJYe4a1JsZnd (tpruvot)

[2022-04-04 08:30:01] 4 miner threads started, using 'scrypt' algorithm.
[2022-04-04 08:30:01] CPU #1: 1.76 kH/s
[2022-04-04 08:30:01] CPU #3: 1.76 kH/s
[2022-04-04 08:30:01] CPU #0: 1.74 kH/s
[2022-04-04 08:30:01] CPU #2: 1.77 kH/s
[2022-04-04 08:30:06] Total: 7.09 kH/s
[2022-04-04 08:30:11] CPU #0: 1.81 kH/s
[2022-04-04 08:30:11] CPU #1: 1.78 kH/s
[2022-04-04 08:30:11] CPU #3: 1.78 kH/s
[2022-04-04 08:30:11] Total: 7.15 kH/s
[2022-04-04 08:30:11] CPU #2: 1.78 kH/s
[2022-04-04 08:30:16] Total: 7.15 kH/s
[2022-04-04 08:30:21] CPU #0: 1.81 kH/s
[2022-04-04 08:30:21] CPU #1: 1.78 kH/s
[2022-04-04 08:30:21] CPU #3: 1.78 kH/s
[2022-04-04 08:30:21] Total: 7.15 kH/s
[2022-04-04 08:30:21] CPU #2: 1.78 kH/s
[2022-04-04 08:30:26] Total: 7.15 kH/s
[2022-04-04 08:30:31] CPU #0: 1.81 kH/s
[2022-04-04 08:30:31] CPU #1: 1.78 kH/s
[2022-04-04 08:30:31] CPU #3: 1.78 kH/s
[2022-04-04 08:30:31] Total: 7.15 kH/s
[2022-04-04 08:30:31] CPU #2: 1.78 kH/s
[2022-04-04 08:30:36] Total: 7.15 kH/s
[2022-04-04 08:30:41] CPU #0: 1.81 kH/s
[2022-04-04 08:30:41] CPU #1: 1.78 kH/s
[2022-04-04 08:30:41] CPU #3: 1.78 kH/s
[2022-04-04 08:30:41] Total: 7.15 kH/s
[2022-04-04 08:30:41] CPU #2: 1.78 kH/s
[2022-04-04 08:30:46] Total: 7.11 kH/s
[2022-04-04 08:30:51] CPU #0: 1.81 kH/s
[2022-04-04 08:30:51] CPU #1: 1.78 kH/s
[2022-04-04 08:30:51] CPU #3: 1.78 kH/s
[2022-04-04 08:30:51] Total: 7.14 kH/s
[2022-04-04 08:30:51] CPU #2: 1.78 kH/s
[2022-04-04 08:30:56] Total: 7.15 kH/s
[2022-04-04 08:31:01] CPU #0: 1.81 kH/s
[2022-04-04 08:31:01] CPU #1: 1.78 kH/s
[2022-04-04 08:31:01] CPU #3: 1.78 kH/s
[2022-04-04 08:31:01] Total: 7.15 kH/s
[2022-04-04 08:31:01] CPU #2: 1.78 kH/s
[2022-04-04 08:31:06] Total: 7.15 kH/s
[2022-04-04 08:31:11] CPU #0: 1.81 kH/s
[2022-04-04 08:31:11] CPU #1: 1.78 kH/s
[2022-04-04 08:31:11] CPU #3: 1.78 kH/s
[2022-04-04 08:31:11] Total: 7.15 kH/s
[2022-04-04 08:31:11] CPU #2: 1.78 kH/s
[2022-04-04 08:31:16] Total: 7.15 kH/s
[2022-04-04 08:31:21] CPU #0: 1.81 kH/s
[2022-04-04 08:31:21] CPU #1: 1.78 kH/s
[2022-04-04 08:31:21] CPU #3: 1.78 kH/s
[2022-04-04 08:31:21] Total: 7.15 kH/s
[2022-04-04 08:31:21] CPU #2: 1.78 kH/s
[2022-04-04 08:31:26] Total: 7.14 kH/s
[2022-04-04 08:31:31] CPU #0: 1.79 kH/s
[2022-04-04 08:31:31] CPU #1: 1.78 kH/s
[2022-04-04 08:31:31] CPU #3: 1.78 kH/s
[2022-04-04 08:31:31] Total: 7.13 kH/s
[2022-04-04 08:31:31] CPU #2: 1.78 kH/s
[2022-04-04 08:31:36] Total: 7.15 kH/s
[2022-04-04 08:31:41] CPU #0: 1.81 kH/s
[2022-04-04 08:31:41] CPU #1: 1.78 kH/s
[2022-04-04 08:31:41] CPU #3: 1.78 kH/s
[2022-04-04 08:31:41] Total: 7.15 kH/s
[2022-04-04 08:31:41] CPU #2: 1.78 kH/s
[2022-04-04 08:31:46] Total: 7.15 kH/s
[2022-04-04 08:31:51] CPU #0: 1.81 kH/s
[2022-04-04 08:31:51] CPU #1: 1.78 kH/s
[2022-04-04 08:31:51] CPU #3: 1.78 kH/s
[2022-04-04 08:31:51] Total: 7.15 kH/s
[2022-04-04 08:31:51] CPU #2: 1.78 kH/s
[2022-04-04 08:31:56] Total: 7.15 kH/s
[2022-04-04 08:32:01] CPU #0: 1.81 kH/s
[2022-04-04 08:32:01] CPU #1: 1.78 kH/s
[2022-04-04 08:32:01] CPU #3: 1.78 kH/s
[2022-04-04 08:32:01] Total: 7.15 kH/s
[2022-04-04 08:32:01] CPU #2: 1.78 kH/s
[2022-04-04 08:32:06] Total: 7.15 kH/s
[2022-04-04 08:32:11] CPU #0: 1.78 kH/s
[2022-04-04 08:32:11] CPU #1: 1.78 kH/s
[2022-04-04 08:32:11] CPU #3: 1.77 kH/s
[2022-04-04 08:32:11] Total: 7.11 kH/s
[2022-04-04 08:32:11] CPU #2: 1.78 kH/s
[2022-04-04 08:32:16] Total: 7.14 kH/s
[2022-04-04 08:32:21] CPU #0: 1.81 kH/s
[2022-04-04 08:32:21] CPU #1: 1.78 kH/s
[2022-04-04 08:32:21] CPU #3: 1.78 kH/s
[2022-04-04 08:32:21] Total: 7.15 kH/s
[2022-04-04 08:32:21] CPU #2: 1.78 kH/s
[2022-04-04 08:32:26] Total: 7.15 kH/s
[2022-04-04 08:32:31] CPU #0: 1.81 kH/s
[2022-04-04 08:32:31] CPU #1: 1.78 kH/s
[2022-04-04 08:32:31] CPU #3: 1.78 kH/s
[2022-04-04 08:32:31] Total: 7.15 kH/s
[2022-04-04 08:32:31] CPU #2: 1.78 kH/s
[2022-04-04 08:32:36] Total: 7.15 kH/s
[2022-04-04 08:32:41] CPU #0: 1.80 kH/s
[2022-04-04 08:32:41] CPU #1: 1.78 kH/s
[2022-04-04 08:32:41] CPU #3: 1.78 kH/s
[2022-04-04 08:32:41] Total: 7.15 kH/s
[2022-04-04 08:32:41] CPU #2: 1.78 kH/s
[2022-04-04 08:32:46] Total: 7.15 kH/s
[2022-04-04 08:32:51] CPU #0: 1.78 kH/s
[2022-04-04 08:32:51] CPU #1: 1.78 kH/s
[2022-04-04 08:32:51] CPU #3: 1.77 kH/s
[2022-04-04 08:32:51] Total: 7.11 kH/s
[2022-04-04 08:32:51] CPU #2: 1.78 kH/s
[2022-04-04 08:32:56] Total: 7.14 kH/s
[2022-04-04 08:33:01] CPU #0: 1.81 kH/s
[2022-04-04 08:33:01] CPU #1: 1.78 kH/s
[2022-04-04 08:33:01] CPU #3: 1.78 kH/s
[2022-04-04 08:33:01] Total: 7.14 kH/s
[2022-04-04 08:33:01] CPU #2: 1.78 kH/s
[2022-04-04 08:33:06] Total: 7.14 kH/s
[2022-04-04 08:33:11] CPU #0: 1.80 kH/s
[2022-04-04 08:33:11] CPU #1: 1.78 kH/s
[2022-04-04 08:33:11] CPU #3: 1.78 kH/s
[2022-04-04 08:33:11] Total: 7.14 kH/s
[2022-04-04 08:33:11] CPU #2: 1.78 kH/s
[2022-04-04 08:33:16] Total: 7.14 kH/s
[2022-04-04 08:33:21] CPU #0: 1.80 kH/s
[2022-04-04 08:33:21] CPU #1: 1.78 kH/s
[2022-04-04 08:33:21] CPU #3: 1.78 kH/s
[2022-04-04 08:33:21] Total: 7.14 kH/s
[2022-04-04 08:33:21] CPU #2: 1.78 kH/s
[2022-04-04 08:33:26] Total: 7.14 kH/s
[2022-04-04 08:33:31] CPU #0: 1.80 kH/s
[2022-04-04 08:33:31] CPU #1: 1.78 kH/s
[2022-04-04 08:33:31] CPU #3: 1.78 kH/s
[2022-04-04 08:33:31] Total: 7.14 kH/s
[2022-04-04 08:33:31] CPU #2: 1.78 kH/s
[2022-04-04 08:33:36] Total: 7.11 kH/s
[2022-04-04 08:33:41] CPU #0: 1.80 kH/s
[2022-04-04 08:33:41] CPU #1: 1.78 kH/s
[2022-04-04 08:33:41] CPU #3: 1.78 kH/s
[2022-04-04 08:33:41] Total: 7.14 kH/s
[2022-04-04 08:33:41] CPU #2: 1.78 kH/s
[2022-04-04 08:33:46] Total: 7.15 kH/s
[2022-04-04 08:33:51] CPU #0: 1.80 kH/s
[2022-04-04 08:33:51] CPU #1: 1.78 kH/s
[2022-04-04 08:33:51] CPU #3: 1.78 kH/s
[2022-04-04 08:33:51] Total: 7.14 kH/s
[2022-04-04 08:33:51] CPU #2: 1.78 kH/s
[2022-04-04 08:33:56] Total: 7.11 kH/s
[2022-04-04 08:34:01] CPU #0: 1.80 kH/s
[2022-04-04 08:34:01] CPU #1: 1.78 kH/s
[2022-04-04 08:34:01] CPU #3: 1.78 kH/s
[2022-04-04 08:34:01] Total: 7.14 kH/s
[2022-04-04 08:34:01] CPU #2: 1.78 kH/s
[2022-04-04 08:34:06] Total: 7.14 kH/s
[2022-04-04 08:34:11] CPU #0: 1.80 kH/s
[2022-04-04 08:34:11] CPU #1: 1.78 kH/s
[2022-04-04 08:34:11] CPU #3: 1.78 kH/s
[2022-04-04 08:34:11] Total: 7.14 kH/s
[2022-04-04 08:34:11] CPU #2: 1.78 kH/s
[2022-04-04 08:34:16] Total: 7.11 kH/s
[2022-04-04 08:34:21] CPU #0: 1.80 kH/s
[2022-04-04 08:34:21] CPU #1: 1.78 kH/s
[2022-04-04 08:34:21] CPU #3: 1.78 kH/s
[2022-04-04 08:34:21] Total: 7.14 kH/s
[2022-04-04 08:34:21] CPU #2: 1.78 kH/s
[2022-04-04 08:34:26] Total: 7.14 kH/s
[2022-04-04 08:34:31] CPU #0: 1.80 kH/s
[2022-04-04 08:34:31] CPU #1: 1.78 kH/s
[2022-04-04 08:34:31] CPU #3: 1.78 kH/s
[2022-04-04 08:34:31] Total: 7.14 kH/s
[2022-04-04 08:34:31] CPU #2: 1.78 kH/s
[2022-04-04 08:34:36] Total: 7.14 kH/s
[2022-04-04 08:34:41] CPU #0: 1.80 kH/s
[2022-04-04 08:34:41] CPU #1: 1.78 kH/s
[2022-04-04 08:34:41] CPU #3: 1.78 kH/s
[2022-04-04 08:34:41] Total: 7.14 kH/s
[2022-04-04 08:34:41] CPU #2: 1.78 kH/s
[2022-04-04 08:34:46] Total: 7.14 kH/s
[2022-04-04 08:34:51] CPU #0: 1.80 kH/s
[2022-04-04 08:34:51] CPU #1: 1.78 kH/s
[2022-04-04 08:34:51] CPU #3: 1.78 kH/s
[2022-04-04 08:34:51] Total: 7.14 kH/s
[2022-04-04 08:34:51] CPU #2: 1.78 kH/s
[2022-04-04 08:34:56] Total: 7.11 kH/s

Total Scores: 7.15,7.14,7.13,7.11,7.09

##########################################################################

Testing clockspeeds again. System health now:

Time        CPU    load %cpu %sys %usr %nice %io %irq   Temp
08:34:55: 1992MHz  4.05 100%   0%  99%   0%   0%   0%  54.4°C

Checking cpufreq OPP (Cortex-A55):

Cpufreq OPP: 1992    Measured: 1910 (1905.517/1906.394/1907.634)
Cpufreq OPP: 1800    Measured: 1745 (1743.660/1725.136/1728.424)
Cpufreq OPP: 1608    Measured: 1555 (1554.717/1569.857/1394.598)
Cpufreq OPP: 1416    Measured: 1400 (1396.498/1393.108/1398.934)
Cpufreq OPP: 1104    Measured: 1005 (1002.066/772.792/1001.357)
Cpufreq OPP:  816    Measured:  805 (804.855/804.307/539.671)
Cpufreq OPP:  600    Measured:  600 (596.347/595.434/595.025)
Cpufreq OPP:  408    Measured:  405 (401.081/402.751/402.943)

##########################################################################

Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal)

System health while running tinymembench:

Time        CPU    load %cpu %sys %usr %nice %io %irq   Temp
08:17:21: 1992MHz  1.00  21%   2%  18%   0%   0%   0%  42.5°C
08:18:01: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  43.1°C
08:18:41: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  43.8°C
08:19:21: 1992MHz  1.00  25%   0%  24%   0%   0%   0%  43.1°C
08:20:01: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  41.9°C
08:20:41: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  42.5°C
08:21:21: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  42.5°C

System health while running OpenSSL benchmark:

Time        CPU    load %cpu %sys %usr %nice %io %irq   Temp
08:21:57: 1992MHz  1.00  23%   1%  21%   0%   0%   0%  43.1°C
08:22:13: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  42.5°C
08:22:29: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  41.9°C
08:22:45: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  42.5°C
08:23:01: 1992MHz  1.00  25%   0%  24%   0%   0%   0%  42.5°C
08:23:18: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  41.9°C
08:23:34: 1992MHz  1.00  25%   0%  25%   0%   0%   0%  42.5°C

System health while running 7-zip single core benchmark:

Time        CPU    load %cpu %sys %usr %nice %io %irq   Temp
08:23:45: 1992MHz  1.00  23%   1%  22%   0%   0%   0%  44.4°C
08:23:55: 1992MHz  1.00  25%   0%  24%   0%   0%   0%  43.1°C
08:24:06: 1992MHz  1.00  25%   0%  24%   0%   0%   0%  44.4°C
08:24:16: 1992MHz  1.00  25%   0%  24%   0%   0%   0%  43.1°C
08:24:26: 1992MHz  1.00  25%   0%  24%   0%   0%   0%  43.8°C
08:24:36: 1992MHz  1.00  25%   0%  24%   0%   0%   0%  43.1°C
08:24:46: 1992MHz  1.00  25%   0%  24%   0%   0%   0%  44.4°C
08:24:56: 1992MHz  1.00  25%   0%  24%   0%   0%   0%  43.1°C
08:25:06: 1992MHz  1.00  25%   0%  24%   0%   0%   0%  43.1°C
08:25:16: 1992MHz  1.00  25%   0%  24%   0%   0%   0%  43.1°C
08:25:26: 1992MHz  1.00  25%   0%  24%   0%   0%   0%  43.1°C

System health while running 7-zip multi core benchmark:

Time        CPU    load %cpu %sys %usr %nice %io %irq   Temp
08:25:36: 1992MHz  1.00  23%   1%  22%   0%   0%   0%  44.4°C
08:25:56: 1992MHz  1.92  91%   1%  90%   0%   0%   0%  47.2°C
08:26:16: 1992MHz  2.57  93%   1%  91%   0%   0%   0%  46.7°C
08:26:36: 1992MHz  2.98  91%   1%  90%   0%   0%   0%  47.8°C
08:26:57: 1992MHz  3.35  96%   2%  94%   0%   0%   0%  51.2°C
08:27:19: 1992MHz  3.54  94%   0%  93%   0%   0%   0%  52.5°C
08:27:39: 1992MHz  3.71  93%   0%  92%   0%   0%   0%  48.9°C
08:27:59: 1992MHz  3.85  94%   1%  93%   0%   0%   0%  46.7°C
08:28:19: 1992MHz  3.91  92%   2%  90%   0%   0%   0%  47.8°C
08:28:40: 1992MHz  3.73  92%   1%  91%   0%   0%   0%  48.9°C
08:29:01: 1992MHz  3.88  94%   0%  93%   0%   0%   0%  53.1°C
08:29:22: 1992MHz  3.92  94%   1%  93%   0%   0%   0%  53.8°C
08:29:44: 1992MHz  3.88  91%   1%  89%   0%   0%   0%  48.9°C

System health while running cpuminer:

Time        CPU    load %cpu %sys %usr %nice %io %irq   Temp
08:30:03: 1992MHz  4.17  40%   1%  39%   0%   0%   0%  52.5°C
08:30:45: 1992MHz  4.09 100%   0%  99%   0%   0%   0%  53.1°C
08:31:27: 1992MHz  4.08 100%   0%  99%   0%   0%   0%  53.8°C
08:32:08: 1992MHz  4.04  99%   0%  99%   0%   0%   0%  53.8°C
08:32:50: 1992MHz  4.06 100%   0%  99%   0%   0%   0%  54.4°C
08:33:32: 1992MHz  4.03 100%   0%  99%   0%   0%   0%  54.4°C
08:34:14: 1992MHz  4.01 100%   0%  99%   0%   0%   0%  55.0°C
08:34:55: 1992MHz  4.05 100%   0%  99%   0%   0%   0%  54.4°C

##########################################################################

dmesg output while running the benchmarks:

[  363.080271] perf: interrupt took too long (3142 > 3128), lowering kernel.perf_event_max_sample_rate to 63600
[  543.165382] perf: interrupt took too long (3935 > 3927), lowering kernel.perf_event_max_sample_rate to 50700
[  857.255856] perf: interrupt took too long (4922 > 4918), lowering kernel.perf_event_max_sample_rate to 40500

##########################################################################

Linux 4.19.219-realtek-odroid-arm64 (server) 	04/04/22 	_aarch64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          52.89    0.01    0.96    0.00    0.00   46.14

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1          11.33       252.86       161.90         0.00     350196     224214          0

              total        used        free      shared  buff/cache   available
Mem:          7.3Gi       237Mi       7.0Gi       1.0Mi        94Mi       7.0Gi
Swap:            0B          0B          0B


CPU sysfs topology (clusters, cpufreq members, clockspeeds)
                 cpufreq   min    max
 CPU    cluster  policy   speed  speed   core type
  0        0        0     1000    1992   Cortex-A55 / r2p0
  1        0        0     1000    1992   Cortex-A55 / r2p0
  2        0        0     1000    1992   Cortex-A55 / r2p0
  3        0        0     1000    1992   Cortex-A55 / r2p0

Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
Vendor ID:                       ARM
Model:                           0
Model name:                      Cortex-A55
Stepping:                        r2p0
CPU max MHz:                     1992.0000
CPU min MHz:                     408.0000
BogoMIPS:                        48.00
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Not affected
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp

SoC guess: Rockchip RK3568 (35682000)
 Compiler: /usr/bin/gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1/aarch64-linux-gnu)
 Userland: arm64
   Kernel: 4.19.219-realtek-odroid-arm64/aarch64
           CONFIG_HZ=300
           CONFIG_HZ_300=y
           CONFIG_PREEMPT_VOLUNTARY=y


| Hardkernel ODROID-M1 | 1992 MHz | 4.19 | Focal arm64 | 5010 | 185660 | 898610 | 3070 | 6220 | 7.14 |


odroid@server:~$ 
https://github.com/ThomasKaiser/sbc-bench#execution

User avatar
rooted
Posts: 9723
Joined: Fri Dec 19, 2014 9:12 am
languages_spoken: english
Location: Gulf of Mexico, US
Has thanked: 767 times
Been thanked: 526 times
Contact:

Re: Odroid M1 sbc_bench

Post by rooted »

@tkaiser the benchmark you wanted

zupet
Posts: 213
Joined: Tue Dec 26, 2017 11:13 pm
languages_spoken: korean,english
ODROIDs: HC1
Has thanked: 8 times
Been thanked: 57 times
Contact:

Re: Odroid M1 sbc_bench

Post by zupet »

rooted wrote:
Mon Apr 04, 2022 5:42 pm
@tkaiser the benchmark you wanted
I ran test with custom built kernel. I'm running it again.

zupet
Posts: 213
Joined: Tue Dec 26, 2017 11:13 pm
languages_spoken: korean,english
ODROIDs: HC1
Has thanked: 8 times
Been thanked: 57 times
Contact:

Re: Odroid M1 sbc_bench

Post by zupet »

http://ix.io/3Ugo

tested with stock odroid kernel .

this time test uploaded automatically. good !!

tkaiser
Posts: 781
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1
Has thanked: 2 times
Been thanked: 25 times
Contact:

Re: Odroid M1 sbc_bench

Post by tkaiser »

Thank you!

Both runs show identical performance so let's compare with other RK3568 boards:
  • same performance as RK3568-ROC-PC (35681000): max cpufreq at ~1960 MHz, http://ix.io/3Rsg
  • Rock 3A with flawed DRAM initialization for whatever reasons (latency almost 3 times higher) shows lower 7-zip scores as expected: 35682000 @ ~1970 MHz http://ix.io/3Oz8
All three boards run with same 4.19 BSP kernel and vendor defaults (e.g. CONFIG_HZ=300). RK3566 based Quartz64 though running already last summer with mainline kernel and limited to 1.8 GHz shows similar memory performance: http://ix.io/3rUb

So comparing with C4 (S905X3 with similar cores at slightly higher speeds) memory performance currently is not that great (C4 shows especially lower latency) but maybe Hardkernel will get better DRAM initialization BLOBs from RK in the future so numbers might improve.

tkaiser
Posts: 781
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1
Has thanked: 2 times
Been thanked: 25 times
Contact:

Re: Odroid M1 sbc_bench

Post by tkaiser »

Maybe an interesting observation are the maximum clockspeeds of the RK3568 A55 cores compared to temperatures measured when benchmark started:
  • 35682000, 36.1°C: 1965 MHz (1966.096/1964.278/1965.330)
  • 35681000, 38.3°C: 1959 MHz (1962.701/1952.327/1962.797)
  • 35682000, 42.5°C: 1929 MHz (1927.475/1929.203/1928.857)
  • 35682000, 44.4°C: 1928 MHz (1928.465/1928.603/1928.419)
(last 2 entries those of zupet's M1).

So in case someone with a large fan can cool down his M1 prior to benchmark execution gets slightly higher clockspeeds (they're measured using Willy Tarreau's mhz utility)? And if it's possible to heat up the M1 prior to benchmark execution measured clockspeeds are lower? Would then be a sign that the RK BLOB in charge of DRAM initialization also does some 'thermal management' not under kernel's control...

User avatar
mctom
Posts: 2253
Joined: Wed Nov 11, 2020 4:44 am
languages_spoken: english, polish
ODROIDs: OGA, XU4, C2, M1, H3+, SP3, Vu8M
Location: Gdansk, Poland
Has thanked: 279 times
Been thanked: 368 times
Contact:

Re: Odroid M1 sbc_bench

Post by mctom »

I think the temperature rise on this chip is so low that its absolute temperature largely depends on ambient temperature.
If what you're suggesting is right, a few identical M1 units would perform faster in colder climate.
Or the same unit would achieve higher clock speed standing upwards rather than lying on a heatsink, assuming identical initial conditions.
Or to make stuff even more scientific, the test could be reproduced with a fan at different speeds.

Too bad this clock speed cannot be measured in real time, I suppose?

But that'd be good news nonetheless, that would mean this chip is fully protected against dying. Doesn't matter what causes that behavior, hardware mechanism or blob.
Attachments
2022-04-04-135716_493x352_scrot.png
2022-04-04-135716_493x352_scrot.png (15.5 KiB) Viewed 3363 times
Punk ain't no religious cult, punk means thinking for yourself!

Maintainer of PiStackMon

tkaiser
Posts: 781
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1
Has thanked: 2 times
Been thanked: 25 times
Contact:

Re: Odroid M1 sbc_bench

Post by tkaiser »

mctom wrote:
Mon Apr 04, 2022 9:10 pm
Too bad this clock speed cannot be measured in real time, I suppose?
It can. Once you've let sbc-bench run once (to install the various stuff) the utility is there below /usr/local/src.

The procedure to test whether a MCU inside the SoC silently adjusts max ARM clock speeds is actually quite simple and requires just 3 minutes even without modifying environment via fan, device position or whatever:

Code: Select all

# measure idle and 'cool' system
taskset -c 1 /usr/local/src/mhz/mhz 3 100000

# now heat system up
/usr/local/src/cpuminer-multi/cpuminer --benchmark --cpu-priority=2

# [ctrl]-[c] after 3 minutes and directly measure again
taskset -c 1 /usr/local/src/mhz/mhz 3 100000
Of course it's necessary to stay with Hardkernel defaults (performance cpufreq governor) and it's always a good idea to run 'sbc-bench -m' in parallel to see what's really going on (especially checking temperatures/clockspeeds). Maybe maximum (specced) cpufreq is only possible below 35°C or even 25°C –- don't know since lacking any RK356x hardware :)

User avatar
mctom
Posts: 2253
Joined: Wed Nov 11, 2020 4:44 am
languages_spoken: english, polish
ODROIDs: OGA, XU4, C2, M1, H3+, SP3, Vu8M
Location: Gdansk, Poland
Has thanked: 279 times
Been thanked: 368 times
Contact:

Re: Odroid M1 sbc_bench

Post by mctom »

Well if it can be measured in real time then indeed no special setup is necessary - I was just exploring ways if it took a few minutes to determine actual clock speed.
Punk ain't no religious cult, punk means thinking for yourself!

Maintainer of PiStackMon

zupet
Posts: 213
Joined: Tue Dec 26, 2017 11:13 pm
languages_spoken: korean,english
ODROIDs: HC1
Has thanked: 8 times
Been thanked: 57 times
Contact:

Re: Odroid M1 sbc_bench

Post by zupet »

Image

start cooling !!
(my room temp is 24C)

zupet
Posts: 213
Joined: Tue Dec 26, 2017 11:13 pm
languages_spoken: korean,english
ODROIDs: HC1
Has thanked: 8 times
Been thanked: 57 times
Contact:

Re: Odroid M1 sbc_bench

Post by zupet »

Code: Select all

 CPU    cluster  policy   speed  speed   core type
  0        0        0     1000    1992   Cortex-A55 / r2p0
  1        0        0     1000    1992   Cortex-A55 / r2p0
  2        0        0     1000    1992   Cortex-A55 / r2p0
  3        0        0     1000    1992   Cortex-A55 / r2p0

Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
Vendor ID:                       ARM
Model:                           0
Model name:                      Cortex-A55
Stepping:                        r2p0
CPU max MHz:                     1992.0000
CPU min MHz:                     408.0000
BogoMIPS:                        48.00
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Not affected
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp

SoC guess: Rockchip RK3568 (35682000)
 Compiler: /usr/bin/gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1/aarch64-linux-gnu)
 Userland: arm64
   Kernel: 4.19.219-realtek-odroid-arm64/aarch64
           CONFIG_HZ=300
           CONFIG_HZ_300=y
           CONFIG_PREEMPT_VOLUNTARY=y


| Hardkernel ODROID-M1 | 1992 MHz | 4.19 | Focal arm64 | 5090 | 185540 | 907470 | 3260 | 6240 | 7.36 |
where is my benchmark result?

cat /sys/devices/virtual/thermal/thermal_zone0/temp

thermal report 27777 at start, 38888 at finish.

zupet
Posts: 213
Joined: Tue Dec 26, 2017 11:13 pm
languages_spoken: korean,english
ODROIDs: HC1
Has thanked: 8 times
Been thanked: 57 times
Contact:

Re: Odroid M1 sbc_bench

Post by zupet »

Code: Select all


CPU sysfs topology (clusters, cpufreq members, clockspeeds)
                 cpufreq   min    max
 CPU    cluster  policy   speed  speed   core type
  0        0        0     1000    1992   Cortex-A55 / r2p0
  1        0        0     1000    1992   Cortex-A55 / r2p0
  2        0        0     1000    1992   Cortex-A55 / r2p0
  3        0        0     1000    1992   Cortex-A55 / r2p0

Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
Vendor ID:                       ARM
Model:                           0
Model name:                      Cortex-A55
Stepping:                        r2p0
CPU max MHz:                     1992.0000
CPU min MHz:                     408.0000
BogoMIPS:                        48.00
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Not affected
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp

SoC guess: Rockchip RK3568 (35682000)
 Compiler: /usr/bin/gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1/aarch64-linux-gnu)
 Userland: arm64
   Kernel: 4.19.219-odroid-arm64/aarch64
           CONFIG_HZ=300
           CONFIG_HZ_300=y
           CONFIG_PREEMPT_VOLUNTARY=y


| Hardkernel ODROID-M1 | 1992 MHz | 4.19 | Focal arm64 | 5070 | 186460 | 907880 | 3210 | 6250 | 7.35 |
with stock kernel.

tkaiser
Posts: 781
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1
Has thanked: 2 times
Been thanked: 25 times
Contact:

Re: Odroid M1 sbc_bench

Post by tkaiser »

zupet wrote:
Mon Apr 04, 2022 11:43 pm
where is my benchmark result?
According to http://ix.io/user/ most likely this: http://ix.io/3UhL

Yes, seems like your benchmark run so we're talking about 1948 MHz (1948.509/1948.109/1947.240) at below 30°C (the 2nd clockspeed test at the end of the result listing is a bit flawed since in parallel another 7-zip benchmark is running).
  • 1928 MHz / 44.4°C, 5010 7-ZIP MIPS, 898150 aes-256-cbc's, 7.26 kH/s
  • 1929 MHz / 42.5°C, 5010 7-ZIP MIPS, 898610 aes-256-cbc's, 7.14 kH/s
  • 1948 MHz / 30°C, 5090 7-ZIP MIPS, 907470 aes-256-cbc's, 7.36 kH/s
Even result variation aside the differences are too small to draw conclusions. And even if clockspeeds weren't affected by temperature overall performance is. A chip that is operated hotter performs slightly slower than a cooler one: https://github.com/longsleep/build-pine ... -264680901

superpowter77
Posts: 389
Joined: Mon Sep 09, 2019 9:14 pm
languages_spoken: english,french,spanish
ODROIDs: N2(x2),N2+,C4,HC4,M1
Has thanked: 150 times
Been thanked: 66 times
Contact:

Re: Odroid M1 sbc_bench

Post by superpowter77 »

Image
Image

Odroid-M1 CPU Temps at full load.
These users thanked the author superpowter77 for the post:
odroid (Tue Apr 05, 2022 8:12 am)

User avatar
odroid
Site Admin
Posts: 40074
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English, Korean
ODROIDs: ODROID
Has thanked: 2841 times
Been thanked: 1602 times
Contact:

Re: Odroid M1 sbc_bench

Post by odroid »

Thank you for sharing the various test results.
I think your board temperature is higher than our test result because you use a PCIe 3.0 and a SATA 3.0 storage devices/interfaces together which consume a much more power.

tkaiser
Posts: 781
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1
Has thanked: 2 times
Been thanked: 25 times
Contact:

Re: Odroid M1 sbc_bench

Post by tkaiser »

odroid wrote:
Tue Apr 05, 2022 9:35 am
I think your board temperature is higher than our test result because you use a PCIe 3.0 and a SATA 3.0 storage devices/interfaces together which consume a much more power.
You must be talking to @zupet, right? Since @superpowter77 shows no SATA storage but only an NVMe SSD obviously in an attempt to either destroy SSD or M1 or maybe even both (not fixing the SSD with a screw and operating it in a crazy angle – or were his both pictures not related to each other?).

Anyway: @zupet reports an ambient temperature of 24°C and when allowing some airflow below the heatsink also talks about 'thermal report 27777 at start, 38888 at finish'. 4°C difference in idle compared to ambient temp (perfectly fine), 15°C difference when running cpuminer for 5 minutes (even more fine and a confirmation that RK3568 is really made in an efficient process).

That's exactly the same 15°C difference you were reporting: 'The CPU core temperature was near 50°C with a heavy computing load at a relatively high 35°C ambient temperature'

Don't you think the higher temperatures reported by zupet's first sbc-bench runs can be explained by the heatsink's own huge thermal mass and 'stuff that happened before'? Once the heatsink has been heated up it will dissipate heat back into the SoC for a rather long time. Unfortunately your graphs at the M1 introduction don't show this (only the heating phase under full load).

User avatar
odroid
Site Admin
Posts: 40074
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English, Korean
ODROIDs: ODROID
Has thanked: 2841 times
Been thanked: 1602 times
Contact:

Re: Odroid M1 sbc_bench

Post by odroid »

@tkaiser,
Both users.

The M1 temperature test condition in the announcement was just using an eMMC without any other extra devices.
Once the NVMe storage device detects in the booting proccess, the PCIe 3.0 host controller in the SoC is activated until the system shutdown.
It will add additional 3°C~6°C of core temperature increasing roughly even we don't access the NVMe storage device.
We could observe around 0.5~1Watt additional power consumption once we installed an NVMe device.
Note that NVMe storage itself power consumption could be slightly over 5Watt by intensive writing tasks and I'm talking about the power and heat of the host controller and interface(PHY & clock) in the SoC.
This behavior have been existing in the ODROID-H2/H2+ too.

Therefore, you might need to run a heavy computing load test without the NVMe storage if you are referring to the temperature graph in the announcement material.

Anyway, we need to capture the temperature and power consumption transient curves with NPU - GPU - VPU - CPU - HDMI - MIPI_DSI - MIPI_CSI - ISP - NVMe - SATA - USB combined heavy loads to learn the thermal-power characteristics for wider applications soon.

User avatar
mctom
Posts: 2253
Joined: Wed Nov 11, 2020 4:44 am
languages_spoken: english, polish
ODROIDs: OGA, XU4, C2, M1, H3+, SP3, Vu8M
Location: Gdansk, Poland
Has thanked: 279 times
Been thanked: 368 times
Contact:

Re: Odroid M1 sbc_bench

Post by mctom »

odroid wrote:
Tue Apr 05, 2022 3:15 pm
Anyway, we need to capture the temperature and power consumption transient curves with NPU - GPU - VPU - CPU - HDMI - MIPI_DSI - MIPI_CSI - ISP - NVMe - SATA - USB combined heavy loads to learn the thermal-power characteristics for wider applications soon.
If that is meant to be an information for end users, something tells me all these trials should be done in controlled environment (no airflow and ambient temperature registered for reference). No need to get fancy with environmental chamber. ;)

That'd be super interesting to take all that data and use good old Excel solver to find a formula coefficients to calculate power consumption in any possible combination.
Punk ain't no religious cult, punk means thinking for yourself!

Maintainer of PiStackMon

User avatar
odroid
Site Admin
Posts: 40074
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English, Korean
ODROIDs: ODROID
Has thanked: 2841 times
Been thanked: 1602 times
Contact:

Re: Odroid M1 sbc_bench

Post by odroid »

In fact, I have no firm idea how to make logical test conditions for any possible practical use cases.
I just guess some major applications I've heard from many of our B2B customers.

1. Digital signage : GPU driven Qt GUI OSD + VPU driven 4K video playback + contents from local NVMe/eMMC + contents via Internet/Ethernet
2. Kiosk machine : GPU driven Chromium browser in kiosk mode + Web app by Flutter + HDMI + MIPI-DSI Vu8M + WiFi 11AC and Bluetooth connectivity
3. Vending or POS machine : MIPI-DSI Vu8M + UART connected NFC for virtual payment + paper money or coin scanning ISP camera + many actuators/sensors using GPIO/PWM/SPI/I2C ports + UART connected credit card IC reader
4. Security monitoring : Multiple IP cameras via external network PoE Switch + OpenCV + NPU powered object detection and tracking + NVMe for caching + SATA for 2.5" HDD backup storage + 4G/5G connectivity

Therefore, it is not easy to build a test bed for various conditions.
But, we can try finding a very close test conditions for the real world applications hopefully.


Otherwise,
Just make a near full load condition something like this on Android to maximize the hardware accelerations.
- HDMI display shows multi-tab browsing with Chrome browser
- Vu8M display shows a 1080p or 4K video
- NVMe : continuous dd reading in background
- SATA : continuous dd reading in background
- MIPI Camera : video streaming or recording
- RTL8821CU module : WiFi 11AC communication with Bluetooth sound playback
- Ethernet : loop of iperf test
- stress-ng NDK for CPU and DRAM heavy loads

While running above items in parallel, keep logging the CPU/GPU temperature nodes and the power transients with SmartPower3 together.
I guess it might be very close to the worst case scenario which eats over 20Watt power certainly.

User avatar
mctom
Posts: 2253
Joined: Wed Nov 11, 2020 4:44 am
languages_spoken: english, polish
ODROIDs: OGA, XU4, C2, M1, H3+, SP3, Vu8M
Location: Gdansk, Poland
Has thanked: 279 times
Been thanked: 368 times
Contact:

Re: Odroid M1 sbc_bench

Post by mctom »

I think it would make sense to capture total input power and register CPU temperature difference vs ambient in various conditions, I think engineers would be the most interested in that.

Possibly with all these features enabled separately, so it could be estimated how much SATA operation may draw, for example. Unless some features share common resources, then these pairs should be enabled together and measured again.

I realize it's a complex matter, and perhaps the "ideal solution" is not strictly necessary. Maybe your B2B customers will be happy with example measurements of these four setups that you described, to get a rough estimate. A respectable business would make their own measurements anyway, and home users won't care that much.

I'm the exception who wants to make a battery powered M1 device :roll:
Punk ain't no religious cult, punk means thinking for yourself!

Maintainer of PiStackMon

User avatar
odroid
Site Admin
Posts: 40074
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English, Korean
ODROIDs: ODROID
Has thanked: 2841 times
Been thanked: 1602 times
Contact:

Re: Odroid M1 sbc_bench

Post by odroid »

I agree.

BTW, it seems to be too much off-topic.
Please create a new topic for more efficient discussion.

tkaiser
Posts: 781
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1
Has thanked: 2 times
Been thanked: 25 times
Contact:

Re: Odroid M1 sbc_bench

Post by tkaiser »

Back to benchmarks. If any of the M1 owners can run a quick 'cryptsetup benchmark' I would believe @elatllat would be happy to list M1 (most probably with a 525 score) at his cryptsetup aes-xts 512b list.
These users thanked the author tkaiser for the post:
elatllat (Sat Aug 13, 2022 4:44 am)

User avatar
mctom
Posts: 2253
Joined: Wed Nov 11, 2020 4:44 am
languages_spoken: english, polish
ODROIDs: OGA, XU4, C2, M1, H3+, SP3, Vu8M
Location: Gdansk, Poland
Has thanked: 279 times
Been thanked: 368 times
Contact:

Re: Odroid M1 sbc_bench

Post by mctom »

Code: Select all

odroid@gnome-desktop:~/git/sbc-bench$ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       570498 iterations per second for 256-bit key
PBKDF2-sha256    1032062 iterations per second for 256-bit key
PBKDF2-sha512     473184 iterations per second for 256-bit key
PBKDF2-ripemd160  338250 iterations per second for 256-bit key
PBKDF2-whirlpool  120029 iterations per second for 256-bit key
argon2i       4 iterations, 399609 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 402904 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b       542.6 MiB/s       647.8 MiB/s
    serpent-cbc        128b               N/A               N/A
    twofish-cbc        128b        51.7 MiB/s        52.4 MiB/s
        aes-cbc        256b       474.6 MiB/s       592.7 MiB/s
    serpent-cbc        256b               N/A               N/A
    twofish-cbc        256b        52.2 MiB/s        52.5 MiB/s
        aes-xts        256b       570.5 MiB/s       576.1 MiB/s
    serpent-xts        256b               N/A               N/A
    twofish-xts        256b        54.9 MiB/s        55.0 MiB/s
        aes-xts        512b       536.6 MiB/s       536.4 MiB/s
    serpent-xts        512b               N/A               N/A
    twofish-xts        512b        56.2 MiB/s        54.9 MiB/s
These users thanked the author mctom for the post (total 2):
brad (Wed Apr 06, 2022 7:58 am) • elatllat (Sat Aug 13, 2022 4:44 am)
Punk ain't no religious cult, punk means thinking for yourself!

Maintainer of PiStackMon

tkaiser
Posts: 781
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1
Has thanked: 2 times
Been thanked: 25 times
Contact:

Re: Odroid M1 sbc_bench

Post by tkaiser »

tkaiser wrote:
Mon Apr 04, 2022 7:04 pm
  • Rock 3A with flawed DRAM initialization for whatever reasons (latency almost 3 times higher) shows lower 7-zip scores as expected: 35682000 @ ~1970 MHz http://ix.io/3Oz8
New Rock 3A number, this time with proper DRAM initialization but mainline kernel (5.15): http://ix.io/3UXa (it's not just mainline (5.15) vs. BSP kernel (4.19) but also CONFIG_HZ=100 vs. CONFIG_HZ=300 which makes comparing the tinymembench results difficult since directly influenced by this setting).

Anyway: the more important point is still RK3568 not clocking at 2.0 GHz but running here with 1960 MHz dropping down to 1910 during benchmark execution (most probably based on SoC temperature).

tkaiser
Posts: 781
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1
Has thanked: 2 times
Been thanked: 25 times
Contact:

Re: Odroid M1 sbc_bench

Post by tkaiser »

For anyone with an M1 and sbc-bench installed (just to meet prerequisits for testing: /usr/bin/7zr and /usr/local/src/mhz/mhz binaries in place) and interested into the 'thermal theory'.

This little script should help:

Code: Select all

#!/bin/bash

InstallLocation=/usr/local/src
TempFile="$(mktemp /tmp/${0##*/}.XXXXXX)"

ReportClockSpeedandTemperature() {
	MeasuredSpeed=$(( $(taskset -c 1 "${InstallLocation}"/mhz/mhz 3 100000 | awk -F" cpu_MHz=" '{s+=$2} END {printf "%.0f", s}') / 3 ))
	CPUTemp=$(awk '{printf ("%0.1f",$1/1000); }' </sys/devices/virtual/thermal/thermal_zone0/temp)
	if [ -s "${TempFile}" ]; then
		MIPS="$(awk -F" " '/^Tot:/ {print $4}' <${TempFile} | tail -n1 | tr '\n' ', ' | sed 's/,$//') 7-ZIP MIPS"
	else
		MIPS="(now starting the benchmark)"
	fi
	echo -e "${CPUTemp}°C\t${MeasuredSpeed} MHz\t${MIPS}"
} # ReportClockSpeedandTemperature

while true ; do
	ReportClockSpeedandTemperature
	7zr b >>"${TempFile}"
done
Should produce something like this:

Code: Select all

35.0°C	1980 MHz	(now starting the benchmark)
41.0°C	1950 MHz	5030 7-ZIP MIPS
44.0°C	1930 MHz	5010 7-ZIP MIPS
48.0°C	1910 MHz	4995 7-ZIP MIPS
^C
And if the 'thermal theory' is right, then rising temperatures should clearly correlate with lower MHz values and also lower 7-Zip MIPS scores.

For any real insights of course the more extreme the temperatures the better. I for example in my climate zone would simply drop M1 on the balcony: now in the early morning ambient temperature below 5°C, in 1.5 hours with the sun coming around the corner the M1 could be in serious trouble with the black heatsink fully exposed to sunlight :)

marmenmu
Posts: 1
Joined: Thu Apr 28, 2022 8:05 pm
languages_spoken: english, finnish
ODROIDs: M1
Has thanked: 0
Been thanked: 1 time
Contact:

Re: Odroid M1 sbc_bench

Post by marmenmu »

I just want to confirm that 980 PRO is working
Image

Sorry, I didn't make much effort.
Image
These users thanked the author marmenmu for the post:
mctom (Thu Apr 28, 2022 9:21 pm)

tkaiser
Posts: 781
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1
Has thanked: 2 times
Been thanked: 25 times
Contact:

Re: Odroid M1 sbc_bench

Post by tkaiser »

tkaiser wrote:
Mon Apr 04, 2022 8:38 pm
Maybe an interesting observation are the maximum clockspeeds of the RK3568 A55 cores compared to temperatures measured when benchmark started:
  • 35682000, 36.1°C: 1965 MHz (1966.096/1964.278/1965.330)
  • 35681000, 38.3°C: 1959 MHz (1962.701/1952.327/1962.797)
  • 35682000, 42.5°C: 1929 MHz (1927.475/1929.203/1928.857)
  • 35682000, 44.4°C: 1928 MHz (1928.465/1928.603/1928.419)
In the meantime a few more results have been collected that invalidate my 'thermal theory' but point more to general issues with clock generation on RK3568 (and RK3588/RK3588s too BTW –– see Rock 5A / RK3558s numbers for example):

The following lists individual sbc-bench runs and there the measured clockspeeds for the highest 1992 MHz cpufreq OPP and the 1st recorded '/sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal)' thermal value:
So there is no direct relation between SoC temperature and real clockspeeds (varying between 1930 MHz and 2010 MHz where it should be 1992 or ~2000 MHz).

tkaiser
Posts: 781
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1
Has thanked: 2 times
Been thanked: 25 times
Contact:

Re: Odroid M1 sbc_bench

Post by tkaiser »

And another update...

Lowest real clockspeeds so far are now the domain of another RK3568 board: FriendlyELEC R5S, which clocks as low as ~1840 MHz while the cpufreq driver reports 1992 MHz:

Code: Select all

tk@gaia:~/sbc-bench-results$ grep 'SoC guess' *.txt | grep RK3568 | cut -f1 -d':' | while read ; do echo -e "$(tail -n1 "${REPLY}" | awk -F"|" '{print $2}')/ $(awk -F": " '/^SoC guess/ {print $2}' "${REPLY}" | sed 's/Rockchip //') ($(grep '^Linux' "${REPLY}" | head -n1 | awk -F" " '{print $2}' | cut -f1 -d'-')): $(grep -i 'measured' "${REPLY}" | head -n1)"; done | egrep -v " 0 |No cpufreq support"
 Radxa ROCK 3 Model A / RK3568 (35682000) (4.19.193): Cpufreq OPP: 1992    Measured: 1970 (1966.096/1964.278/1965.330)
 Firefly RK3568-ROC-PC HDMI (Linux) / RK3568 (35681000) (4.19.219): Cpufreq OPP: 1992    Measured: 1965 (1962.701/1952.327/1962.797)
 Hardkernel ODROID-M1 / RK3568 (35682000) (4.19.219): Cpufreq OPP: 1992    Measured: 1930 (1927.475/1929.203/1928.857)
 Hardkernel ODROID-M1 / RK3568 (35682000) (4.19.219): Cpufreq OPP: 1992    Measured: 1930 (1928.465/1928.603/1928.419)
 Hardkernel ODROID-M1 / RK3568 (35682000) (4.19.219): Cpufreq OPP: 1992    Measured: 1950 (1948.509/1948.109/1947.240)
 Hardkernel ODROID-M1 / RK3568 (35682000) (4.19.219): Cpufreq OPP: 1992    Measured: 1950 (1946.371/1939.775/1951.572)
 Hardkernel ODROID-M1 / RK3568 (35682000) (4.19.219): Cpufreq OPP: 1992    Measured: 1940 (1935.240/1933.455/1939.472)
 Radxa ROCK 3 Model A / RK3566 or RK3568 (5.15.32): Cpufreq OPP: 1992    Measured: 1960 (1955.852/1955.473/1955.781)
 Hardkernel ODROID-M1 / RK3568 (35682000) (4.19.219): Cpufreq OPP: 1992    Measured: 1935 (1934.451/1933.131/1929.895)
 Firefly RK3568-ROC-PC HDMI (Linux) / RK3568 (35681000) (4.19.219): Cpufreq OPP: 1992    Measured: 2010 (2008.644/2009.094/2008.969)
 Firefly RK3568-ROC-PC HDMI (Linux) / RK3568 (35681000) (4.19.219): Cpufreq OPP: 1992    Measured: 1995 (1991.715/1998.398/1985.981)
 Hardkernel ODROID-M1 / RK3568 (35682000) (4.19.219): Cpufreq OPP: 1992    Measured: 1955 (1951.289/1953.272/1943.021)
 Radxa ROCK 3 Model A / RK3568 (35682000) (4.19.193): Cpufreq OPP: 1992    Measured: 1940 (1936.633/1936.075/1934.405)
 Radxa ROCK 3 Model A / RK3566 or RK3568 (4.19.193): Cpufreq OPP: 1992    Measured: 2000 (1998.447/1997.359/1996.742)
 Hardkernel ODROID-M1 / RK3568 (35682000) (4.19.219): Cpufreq OPP: 1992    Measured: 1947 (1948.039/1947.827/1947.592)  (-2.3%)
 Mrkaio M68S / RK3568 (35682000) (4.19.219): Cpufreq OPP: 1992    Measured: 1904 (1911.021/1909.236/1892.758)     (-4.4%)
 FriendlyElec NanoPi R5S / RK3568 (35682000) (5.10.66): Cpufreq OPP: 1992    Measured: 1872 (1872.991/1872.926/1872.230)     (-6.0%)
 FriendlyElec NanoPi R5S / RK3568 (35682000) (5.10.66): Cpufreq OPP: 1992    Measured: 1870 (1870.560/1870.495/1870.430)     (-6.1%)
 Hardkernel ODROID-M1 / RK3568 (35682000) (4.19.219): Cpufreq OPP: 1992    Measured: 1949 (1949.969/1949.898/1949.709)     (-2.2%)
 FriendlyElec NanoPi R5S / RK3568 (35682000) (5.10.66): Cpufreq OPP: 1992    Measured: 1845 (1846.338/1845.663/1844.967)     (-7.4%)
 Hardkernel ODROID-M1 / RK3566/RK3568 (5.18.0): Cpufreq OPP: 1992    Measured: 1960 (1961.819/1960.699/1960.461)     (-1.6%)
All the RK3568 devices so far either used the old Rockchip BSP from last year (kernel 4.19 based) or mainline kernel (5.15 upwards). In the meantime Rockchip released a newer BSP for RK356x/RK3588 based on a forward ported 5.10.66 kernel and FriendlyELEC chose this one.

I guess this BSP version also uses a different u-boot and boot BLOBs (doing DRAM initialization and loading a firmware to RK3568's internal MCU that controls real cpufreq behaviour) and this is the real reason for these clockspeed mismatches we see on almost all RK3568 devices so far (Firefly's RK3568-ROC-PC and Radxa's Rock 3A being the only exceptions with clockspeeds at or above the 'advertised' 1992 MHz).
Last edited by tkaiser on Tue Jun 07, 2022 2:08 pm, edited 1 time in total.
These users thanked the author tkaiser for the post:
drolid (Mon Jun 06, 2022 8:29 pm)

back2future
Posts: 314
Joined: Sun Jul 23, 2017 3:19 pm
languages_spoken: english
Has thanked: 14 times
Been thanked: 12 times
Contact:

Re: Odroid M1 sbc_bench

Post by back2future »

might be related to an internal power provision difficulty, since a smaller increase in frequency is done with 'bigger' 0.1 volts increase (what is higher voltage increase for a ~190MHz cpu cores clock addition)?
Same 0.1 volts (or even included in base voltage level) can enable >300MHz on a mid cpu frequency level (with power voltage set to leveling ~0.3 volts lower compared to highest clock frequencies) and might be reported to be fully established voltage levels, but measured (possible implications of openssl?) having lower effective cpu frequency (on a <7% differences)?
Difference between a ROC-PC and NanoPi R5S might translate to only 0.075 volts, even lower for smaller decreases.
Last edited by back2future on Tue Jun 07, 2022 6:24 pm, edited 1 time in total.

tkaiser
Posts: 781
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1
Has thanked: 2 times
Been thanked: 25 times
Contact:

Re: Odroid M1 sbc_bench

Post by tkaiser »

back2future wrote:
Mon Jun 06, 2022 7:47 pm
power provision
Why/how is this behaviour related to power / supply voltage?

back2future
Posts: 314
Joined: Sun Jul 23, 2017 3:19 pm
languages_spoken: english
Has thanked: 14 times
Been thanked: 12 times
Contact:

Re: Odroid M1 sbc_bench

Post by back2future »

For a maybe 0.075V that's variation of (<)25mΩ¹ for power supply paths from converted input 5/12V before?
( Without some knowledge on transient power draw and sustained values, we will stay with guessing how this might be related to internal supply voltage variations. Having all boards for benchmarking, one could limit cpu clock frequency on a lower 1800/1608MHz while capturing power input and going into detail about activated peripherals for each board, well that even might be academical study? )
(IIUC there is no thermal throttling with tested rk3568 boards, that keeps that questions difficult.)

[customers interests: Smarter power-consumption analysis for embedded system developers
1) example for a pcb conductor: Cu, t=0.035mm, w=1mm, l=50mm, R = 0.49 x ( 2"/(40mil) ) x ( 35/35µm ) = 24.9mΩ @ 25°C, ~75mV@~3A (voltage decr./resistance &~30% @ 100°C)
1mm vs. '22nm' = 45000:1, (early) rk3399 trended towards higher temps compared to previous gens (same for rpi4s)?

keeping this balanced as possible, (tbf) actually 'sbc_bench' compares SoC's (including memory/storage) within relation to current available system distributions (?)
("SBC is a shortcut for single-board computer and [this whole repository] is about performance considerations around those devices (with an initial focus on energy efficient server tasks).")

Hardkernel ODROID-M1
"ODROID-M1

The ODROID-M1 is a single board computer with a wide range of useful peripherals developed for use in a variety of embedded applications.
To achieve this goal, we have developed various hardware accessories and device driver software over the past 10 months.
In addition, RK3568B2, the core brain of ODROID-M1, is considered suitable for embedded system use as the SoC manufacturer (Rockchip) guarantees supply for the next 15 years.
Therefore, we expect we can supply the ODROID-M1 boards to our important B2B customers until the year 2036 or beyond.
Note that RK3568B2 is a slightly modified version of the RK3568 to overcome the IC supply chain problem these days.
The previous RK3568 metal-can type packaging lead time is much longer than the more common plastic package of the RK3568B2."
viewtopic.php?f=29&t=44218
https://wiki.odroid.com/odroid-m1/odroid-m1
https://www.hardkernel.com/shop/odroid- ... gbyte-ram/ ]

tkaiser
Posts: 781
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1
Has thanked: 2 times
Been thanked: 25 times
Contact:

Re: Odroid M1 sbc_bench

Post by tkaiser »

Mystery resolved. Different RK3568 get different real clockspeeds based on silicon quality. There's something called PVTM at work and this is responsible for the clockspeeds to vary.

Found out when playing around with RK3568's bigger sibling: https://github.com/ThomasKaiser/Knowled ... .md#rk3588

j.fikar
Posts: 59
Joined: Tue Dec 08, 2020 9:32 pm
languages_spoken: english
ODROIDs: HC4
Has thanked: 10 times
Been thanked: 6 times
Contact:

Re: Odroid M1 sbc_bench

Post by j.fikar »

It looks like the M1 is doing the thermal throttling without reporting the lower frequency to /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq, is that right? I'm using kernel 5.19.0-odroid-arm64 #1 SMP PREEMPT Ubuntu 5.19.3-202208241738~jammy (2022-08-24), if it matters.

I was doing HPL test on my new M1 and with a 10cm USB fan pointed on the M1 heatsink I got 15.08 GFLOPS, temperature was at max 47C. Without the fan, only passive cooling, with the heatsink pointing upwards I'm getting only 13.23 GFLOPS. Temperature is at max 69C. But the /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq still reports the default frequency of 1.992GHz. From the GFLOPS we can calculate the actual CPU frequency to be 1.748GHz.

More details, the compiled HPL binaries for ARM64 and a manual, how to compile it yourself, can be found here:
https://github.com/jfikar/xhpl-aarch64#odroid-m1

Conclusion: when benchmarking M1 CPU, better use a fan

Post Reply

Return to “Ubuntu”

Who is online

Users browsing this forum: No registered users and 1 guest