head -r355027 on Rock64: CPU staying at 600 MHz? (based on ArchLinuxARM benchmark comparison)

[Mark Millard]

On 2019-Nov-23, at 14:26, Mark Millard <marklmi at yahoo.com> wrote:

> I ran my C++ variation on the old HINT serial/threads benchmark
> on ArchLinuxARM (5.3.12 kernel) and FreeBSD -r355027 and got
> a surprise for the CPU/memory-cache dominated range.
> 
> The benchmark explores from small problems dependent primarily
> on CPU speed (and memory cache speed) to sizes/patterns dominated
> by RAM speed (the access pattern makes caches far less effective).
> (I do not normally use it to explore sizes that would involve
> paging and have not done so here.)
> 
> The RAM-speed dominated part is ball park similar, as expected.
> 
> BUT: For the CPU/cache-speed dominated part FreeBSD is near a
> factor of 2 slower than for ArchLinuxARM.
> 
> My guess is that the FreeBSD CPU frequency is staying at 600 MHz
> instead of going to the 1200MHz or 1296MHz that is listed as
> possible:
> 
> dev.cpufreq_dt.3.freq_settings: 408/-1 600/-1 816/-1 1008/-1 1200/-1 1296/-1
> dev.cpufreq_dt.3.%parent: cpu3
> dev.cpufreq_dt.3.%pnpinfo: 
> dev.cpufreq_dt.3.%location: 
> dev.cpufreq_dt.3.%driver: cpufreq_dt
> dev.cpufreq_dt.3.%desc: Generic cpufreq driver
> dev.cpufreq_dt.2.freq_settings: 408/-1 600/-1 816/-1 1008/-1 1200/-1 1296/-1
> dev.cpufreq_dt.2.%parent: cpu2
> dev.cpufreq_dt.2.%pnpinfo: 
> dev.cpufreq_dt.2.%location: 
> dev.cpufreq_dt.2.%driver: cpufreq_dt
> dev.cpufreq_dt.2.%desc: Generic cpufreq driver
> dev.cpufreq_dt.1.freq_settings: 408/-1 600/-1 816/-1 1008/-1 1200/-1 1296/-1
> dev.cpufreq_dt.1.%parent: cpu1
> dev.cpufreq_dt.1.%pnpinfo: 
> dev.cpufreq_dt.1.%location: 
> dev.cpufreq_dt.1.%driver: cpufreq_dt
> dev.cpufreq_dt.1.%desc: Generic cpufreq driver
> dev.cpufreq_dt.0.freq_settings: 408/-1 600/-1 816/-1 1008/-1 1200/-1 1296/-1
> dev.cpufreq_dt.0.%parent: cpu0
> dev.cpufreq_dt.0.%pnpinfo: 
> dev.cpufreq_dt.0.%location: 
> dev.cpufreq_dt.0.%driver: cpufreq_dt
> dev.cpufreq_dt.0.%desc: Generic cpufreq driver
> dev.cpufreq_dt.%parent: 
> dev.cpu.0.freq_levels: 1296/-1 1200/-1 1008/-1 816/-1 600/-1 408/-1
> dev.cpu.0.freq: 600
> 
> (The above was not from during a benchmark run: just showing the
> default and the alternatives listed.)
> 
> Is the reversal of ordering of freq_settings vs. freq_levels also
> interesting?
> 

Rerunning the benchmark after a manual
sysctl dev.cpu.0.freq=1296 got the
expected results, FreeBSD's context
happening to be somewhat faster for
some types of contexts.

For now I've added:

QUOTE
# The Rock64 does not seem to automatically adjust from 600MHz,
# so do so manually. (The specifics likely would not be
# appropriate to the RPi3.)
dev.cpu.0.freq=1296
END QUOTE

to the /etc/sysctl.conf on the Rock64.

(The Rock64 in question has heat sinks and a fan.)

The Rock64 is generally noticeably faster than the Pine64+ 2GB
across what the benchmark explores. The Rock64 has example has
4 GiByte of RAM, not 2 GiByte, and is smaller.

As for the e.MMC I/O, iozone -a -i0 -i1 -i2 -e -I shows the
Rock64 as getting, for example:

                                                              random    random                                 
              kB  reclen    write  rewrite    read    reread    read     write
. . .
            1024       4     2217     1637     4514     4458     4414     1817
            1024       8     5270     3105     9151     9206     8665     4283
            1024      16    14203     7487    19187    18554    17019     7511
            1024      32    22153    28046    41794    40762    33855    27390
            1024      64    22379    28149    40981    40857    36886    27628
            1024     128    22832    26292    42291    40557    27731    35227
            1024     256    22889    26296    42590    41648    31187    27848
            1024     512    22846    27489    41814    40564    40248    26159
            1024    1024    22070    28123    40743    40816    40114    26223
. . .

Looks like the Rock64 will displace the Pine64+ 2GB as my
primary CortexA53 example.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)