StarFive VisionFive 2

[geerlingguy]

Basic information

• Board URL (official): https://www.starfivetech.com/en/site/boards
• Board purchased from: youyeetoo
• Board purchase date: 2023-01-05
• Board specs (as tested): Dual Gigabit Ethernet
• Board price (as tested): $85.10

Linux/system information

# output of `neofetch`
       _,met$$$$$gg.          user@starfive 
    ,g$$$$$$$$$$$$$$$P.       ------------- 
  ,g$$P"     """Y$$.".        OS: Debian GNU/Linux bookworm/sid riscv64 
 ,$$P'              `$$$.     Host: StarFive VisionFive V2 
',$$P       ,ggs.     `$$b:   Kernel: 5.15.0-starfive 
`d$$'     ,$P"'   .    $$$    Uptime: 6 mins 
 $$P      d$'     ,    $$P    Packages: 1035 (dpkg) 
 $$:      $$.   -    ,d$$'    Shell: bash 5.1.16 
 $$;      Y$b._   _,d$P'      Resolution: 1920x1080 
 Y$$.    `.`"Y$$$$P"'         Terminal: /dev/pts/0 
 `$$b      "-.__              CPU: (4) @ 1.500GHz 
  `Y$$                        Memory: 262MiB / 7927MiB 
   `Y$$.
     `$$b.                                            
       `Y$$b.                                         
          `"Y$b._
              `"""

# output of `uname -a`
Linux starfive 5.15.0-starfive #1 SMP Mon Dec 19 07:56:37 EST 2022 riscv64 GNU/Linux

Benchmark results

CPU

• Geekbench 6: (74 single / 218 multi - https://browser.geekbench.com/v6/cpu/3784701)
• Geekbench 5: (78 single / 276 multi - https://browser.geekbench.com/v5/cpu/20379272)
• TODO Gflops (geerlingguy/top500-benchmark HPL result)

Power

• Idle power draw (at wall): 3.1 W
• Maximum simulated power draw (stress-ng --matrix 0): 5.3 W
• During Geekbench multicore benchmark: 5.2 W
• During top500 HPL benchmark: TODO W

Disk

SanDisk Extreme 128GB microSD

Benchmark	Result
fio 1M sequential read	23.6 MB/s
iozone 1M random read	21.02 MB/s
iozone 1M random write	19.40 MB/s
iozone 4K random read	5.82 MB/s
iozone 4K random write	2.83 MB/s

KIOXIA XG6 1GB NVMe SSD

Benchmark	Result
fio 1M sequential read	149 MB/s
iozone 1M random read	237.35 MB/s
iozone 1M random write	242.66 MB/s
iozone 4K random read	27.87 MB/s
iozone 4K random write	72.73 MB/s

curl https://raw.githubusercontent.com/geerlingguy/pi-cluster/master/benchmarks/disk-benchmark.sh | sudo bash

Run benchmark on any attached storage device (e.g. eMMC, microSD, NVMe, SATA) and add results under an additional heading. Download the script with curl -o disk-benchmark.sh [URL_HERE] and run sudo DEVICE_UNDER_TEST=/dev/sda DEVICE_MOUNT_PATH=/mnt/sda1 ./disk-benchmark.sh (assuming the device is sda).

Also consider running PiBenchmarks.com script.

Network

iperf3 results:

• iperf3 -c $SERVER_IP: 937 Mbps
• iperf3 --reverse -c $SERVER_IP: 774 Mbps
• iperf3 --bidir -c $SERVER_IP: 941 Mbps up / 262 Mbps down

I tested both 1 Gbps interfaces, and they both worked with similar results, and I could connect to two different IPs at once.

GPU

• TODO: Haven't determined standardized benchmark yet. See Issue #2.

Memory

• TODO: Haven't determined standardized benchmark yet. See Issue #2.

[ThomasKaiser]

A few thoughts on methodology with a new platform like RISC-V:

Crypto performance:

This is two times a JH7110 board (Star64 and StarFive VisionFive V2) running exactly same OS image but different kernel config / device-tree settings:

Clockspeed	Kernel	Distro	7-zip multi	7-zip single	AES	memcpy	memset
1750 MHz	5.15	Sid riscv64	4820	1396	28970	1170	1120
1500 MHz	5.15	Sid riscv64	4040	1182	6830	1150	860

The 1st is slightly overclocked which ends up with better 7-zip scores, better memset numbers and way better AES scores (openssl speed -elapsed -evp aes-${bytelength}-cbc). At 1750 MHz (17% higher cpufreq) the crypto score gain is an impressive 424%! Or is it the hardware Star64 vs. StarFive VisionFive V2 (both boards being almost the same)?

Is that even possible? Of course not, it's 'OpenSSL 3.0.5, built on 5 Jul 2022' vs. 'OpenSSL 1.1.1f, built on 31 Mar 2020' (and that's why sbc-bench -j will always print the OpenSSL version since it might explain differing numbers).

On every 'new' platform software needs to be optimized. Even if the platform isn't that new any more – see this refreshing bit about a few lines NEON optimizations needed on ARM to really outperform x86 where this level of optimization was standard for a decade already: link to cnx-software)

Same with crypto stuff. On x86 and ARM we have optimized assembler routines since ages or even AES-NI and ARMv8 Crypto Extensions.

While on RISC-V we had only generic C routines but "scalar crypto" extension ratified in the meantime (of course not part of JH7110's silicon since basing on old U74 21G1 cores that predate the ratification). So my assumption is OpenSSL 3.0.5 now making use of optimized (assembler) code and/or the SHA and AES hardware accelerators that these U74 cores provide.

Still being a RISC-V noob I'm trying to ask @brucehoult for clarification (since your review will get a massive target audience compared to other RISC-V reviews).

While your target audience wrt 'SBC performance' most probably just wants a single score and 'less is better' or 'more is better' as only information they deserve better. IMO it's important when reviewing stuff to explain that new hardware usually gets faster over time since software matures and gradually makes use of hardware features. That's why listing a crypto score of 6830 is a bit unfair when comparing with ARM or x86 since those platforms are way older and the software side of things already received much more love. Even if JH7110 will never compete with recent x86 or ARMv8/ARMv9 CPUs due to lack of real crypto extensions.

Benchmarking the benchmark

For whatever reason people blindly trust into the numbers spitten out by a specific benchmark tool. And consumers as usually don't care about individual scores but want one single score or at least one for single-threaded and another for multi-threaded (IMO a horrible choice since those combined scores hide too much and are pretty much worthless).

Let's check Geekbench vs. another benchmark. When measuring the JH7110 at 1.5 GHz with 7-zip then it achieves a ~4000 score. 7-zip is all about Integer performance and memory (latency). When choosing a quad-core ARM board with similar score we end up at a Khadas VIM1S for example (based on Amlogic S905Y4: quad A35 @ 2.0 GHz).

Geekbench when looking at total scores tells us JH7110 is only at 60% the S905Y4's performance: https://browser.geekbench.com/v5/cpu/compare/19322441?baseline=17155111

When looking at the individual results view, the board's 'Integer Score' difference is 96 vs. 140 (68%) and 'Crypto Score' is listed as 11 vs. 167 (6.5%). I'm fine with the crypto score but highly doubt the others especially when looking through the individual scores.

Do these benchmark scores represent real-world performance? Or does the rule 'software needs to mature on a new hardware platform' also apply to benchmark software? Most probably yes.

Maybe this is also a hint in the same direction: GB not running on a bunch of RISC-V CPUs due to a problematic instruction.

IMO your target audience deserves these explanations: software needs time and this also applies to benchmarks (maybe once the Primatelabs guy got a bit more familiar with RISC-V the benchmark scores magically improve?). And this fact makes maintaining a 'table of benchmark scores' so problematic since software optimization efforts happening in the meantime automagically outdate such a table...

[geerlingguy]

IMO it's important when reviewing stuff to explain that new hardware usually gets faster over time since software matures and gradually makes use of hardware features.

This is quite true—and any RISC-V board will get a lot more of that treatment / extra caveats in my reviews, so don't worry about that! Even with the Pi, every few months some random bug gets squashed that can boost a number here or there (like kernel PTP timing... few people had even tested it until a few months ago), though most of the basics are pretty stable and well-tested at this point.

With the VisionFive 2, very few people have really built anything with it outside of the hardcore tinkerers, so it's going to need a lot of caveats.

[geerlingguy]

For bringup, I used these instructions to flash the simpler (800 MB) buildroot image, scp over the appropriate firmware files, flash them using flashcp, then I could run the latest (-69) version of the official OS release.

I should note that for the -69 version, I was going to follow the getting started guide, which says to SSH into the user root:

But that with the password starfive never worked. I got "Permission denied" every time:

Instead, I used user for the username and starfive for the password... and that actually did work. Thanks to this blog post for helping me figure that out!

[geerlingguy]

For my Kioxia XG6 NVMe SSD, I see it appear as a x1 device at 5.0 GT/sec (so presumably PCIe gen 2):

0001:01:00.0 Non-Volatile memory controller: Toshiba Corporation XG6 NVMe SSD Controller (prog-if 02 [NVM Express])
	Subsystem: Toshiba Corporation XG6 NVMe SSD Controller
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 59
	Region 0: Memory at 38000000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [40] Express (v2) Endpoint, MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0.000W
		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- FLReset-
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 8GT/s, Width x4, ASPM L1, Exit Latency L1 <32us
			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
		LnkCtl:	ASPM Disabled; RCB 64 bytes, Disabled- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 5GT/s (downgraded), Width x1 (downgraded)
			TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Range AB, TimeoutDis+ NROPrPrP- LTR+
			 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt+ EETLPPrefix-
			 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
			 FRS- TPHComp- ExtTPHComp-
			 AtomicOpsCap: 32bit- 64bit- 128bitCAS-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+ LTR- OBFF Disabled,
			 AtomicOpsCtl: ReqEn-
		LnkCap2: Supported Link Speeds: 2.5-8GT/s, Crosslink- Retimer- 2Retimers- DRS-
		LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete- EqualizationPhase1-
			 EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
			 Retimer- 2Retimers- CrosslinkRes: unsupported
	Capabilities: [80] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [90] MSI: Enable- Count=1/32 Maskable+ 64bit+
		Address: 0000000000000000  Data: 0000
		Masking: 00000000  Pending: 00000000
	Capabilities: [b0] MSI-X: Enable+ Count=33 Masked-
		Vector table: BAR=0 offset=00002000
		PBA: BAR=0 offset=00003000
	Capabilities: [100 v2] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
		AERCap:	First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn-
			MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
		HeaderLog: 00000000 00000000 00000000 00000000
	Capabilities: [260 v1] Latency Tolerance Reporting
		Max snoop latency: 0ns
		Max no snoop latency: 0ns
	Capabilities: [300 v1] Secondary PCI Express
		LnkCtl3: LnkEquIntrruptEn- PerformEqu-
		LaneErrStat: 0
	Capabilities: [400 v1] L1 PM Substates
		L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+
			  PortCommonModeRestoreTime=60us PortTPowerOnTime=100us
		L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
			   T_CommonMode=0us LTR1.2_Threshold=0ns
		L1SubCtl2: T_PwrOn=10us
	Kernel driver in use: nvme

But in benchmarks (see OP, and also: https://pibenchmarks.com/benchmark/66979/), I'm only seeing about 200 MB/sec sequential read/write, much less than the 350-400 I'd expect.

[geerlingguy]

First attempt at running the top500 benchmark (HPL) I ran into this error during pip3 install ansible:

Collecting cryptography
  Downloading cryptography-39.0.1.tar.gz (603 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 603.6/603.6 kB 5.7 MB/s eta 0:00:00
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  error: subprocess-exited-with-error
  
  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> [29 lines of output]
      
              =============================DEBUG ASSISTANCE==========================
              If you are seeing an error here please try the following to
              successfully install cryptography:
      
              Upgrade to the latest pip and try again. This will fix errors for most
              users. See: https://pip.pypa.io/en/stable/installing/#upgrading-pip
              =============================DEBUG ASSISTANCE==========================
      
      Traceback (most recent call last):
        File "/usr/lib/python3/dist-packages/pip/_vendor/pep517/in_process/_in_process.py", line 363, in <module>
          main()
        File "/usr/lib/python3/dist-packages/pip/_vendor/pep517/in_process/_in_process.py", line 345, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
        File "/usr/lib/python3/dist-packages/pip/_vendor/pep517/in_process/_in_process.py", line 130, in get_requires_for_build_wheel
          return hook(config_settings)
        File "/usr/lib/python3/dist-packages/setuptools/build_meta.py", line 162, in get_requires_for_build_wheel
          return self._get_build_requires(
        File "/usr/lib/python3/dist-packages/setuptools/build_meta.py", line 143, in _get_build_requires
          self.run_setup()
        File "/usr/lib/python3/dist-packages/setuptools/build_meta.py", line 158, in run_setup
          exec(compile(code, __file__, 'exec'), locals())
        File "setup.py", line 18, in <module>
          from setuptools_rust import RustExtension
        File "/tmp/pip-build-env-o89jx04a/overlay/local/lib/python3.10/dist-packages/setuptools_rust/__init__.py", line 1, in <module>
          from .build import build_rust
        File "/tmp/pip-build-env-o89jx04a/overlay/local/lib/python3.10/dist-packages/setuptools_rust/build.py", line 23, in <module>
          from setuptools.command.build import build as CommandBuild  # type: ignore[import]
      ModuleNotFoundError: No module named 'setuptools.command.build'
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

I tried pip3 install --upgrade pip, and installed Ansible again... now getting another error about missing a rust compiler:

      running build_rust
      
          =============================DEBUG ASSISTANCE=============================
          If you are seeing a compilation error please try the following steps to
          successfully install cryptography:
          1) Upgrade to the latest pip and try again. This will fix errors for most
             users. See: https://pip.pypa.io/en/stable/installing/#upgrading-pip
          2) Read https://cryptography.io/en/latest/installation/ for specific
             instructions for your platform.
          3) Check our frequently asked questions for more information:
             https://cryptography.io/en/latest/faq/
          4) Ensure you have a recent Rust toolchain installed:
             https://cryptography.io/en/latest/installation/#rust
      
          Python: 3.10.5
          platform: Linux-5.15.0-starfive-riscv64-with-glibc2.33
          pip: n/a
          setuptools: 67.2.0
          setuptools_rust: 1.5.2
          rustc: n/a
          =============================DEBUG ASSISTANCE=============================
      
      error: can't find Rust compiler
      
      If you are using an outdated pip version, it is possible a prebuilt wheel is available for this package but pip is not able to install from it. Installing from the wheel would avoid the need for a Rust compiler.
      
      To update pip, run:
      
          pip install --upgrade pip
      
      and then retry package installation.
      
      If you did intend to build this package from source, try installing a Rust compiler from your system package manager and ensure it is on the PATH during installation. Alternatively, rustup (available at https://rustup.rs) is the recommended way to download and update the Rust compiler toolchain.
      
      This package requires Rust >=1.48.0.
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for cryptography
  Building wheel for MarkupSafe (setup.py) ... done
  Created wheel for MarkupSafe: filename=MarkupSafe-2.1.2-cp310-cp310-linux_riscv64.whl size=24451 sha256=7fbd78192601d02b42ecc28c0b76d24ecfcefac99a36accc953ec7249179a3e0
  Stored in directory: /home/user/.cache/pip/wheels/54/8e/98/3c8a462676f35ac84e7e2a886d2e90c50c796b73f4cd1f351f
Successfully built PyYAML MarkupSafe
Failed to build cryptography
ERROR: Could not build wheels for cryptography, which is required to install pyproject.toml-based project

Putting that on pause for now.

[geerlingguy]

@ThomasKaiser - I ran your sbc-bench script (downloaded lastest revision from GitHub) and it looks like it's not able to pull the CPU temps:

user@starfive:~$ sudo /bin/bash ./sbc-bench.sh -j 
sudo: unable to resolve host starfive: Name or service not known
Starting to examine hardware/software for review purposes...

Average load and/or CPU utilization too high (too much background activity). Waiting...

Too busy for benchmarking: 22:36:25 up 19 min,  2 users,  load average: 0.13, 0.36, 0.31,  cpu: 8%
Too busy for benchmarking: 22:36:30 up 19 min,  2 users,  load average: 0.12, 0.36, 0.30,  cpu: 0%
Too busy for benchmarking: 22:36:35 up 20 min,  2 users,  load average: 0.11, 0.35, 0.30,  cpu: 0%
Too busy for benchmarking: 22:36:40 up 20 min,  2 users,  load average: 0.10, 0.34, 0.30,  cpu: 0%
Too busy for benchmarking: 22:36:45 up 20 min,  2 users,  load average: 0.09, 0.34, 0.30,  cpu: 0%

sbc-bench v0.9.13

Installing needed tools: apt -f -qq -y install lm-sensors sysstat mbw p7zip, tinymembench, ramlat, mh (can't build cpuminer) Done.
Checking cpufreq OPP. Done.
Executing RAM latency tester. Done.
Executing OpenSSL benchmark. Done.
Checking cpufreq OPP again. Done (2 minutes elapsed).

It seems neither throttling occured nor too much background activity.

Full results uploaded to http://ix.io/4npK





# StarFive VisionFive V2

Tested on Tue, 07 Feb 2023 22:40:33 +0000. Full info: [http://ix.io/4npK](http://ix.io/4npK)

## General information:

    StarFive JH7110, Kernel: riscv64, Userland: riscv64
    
    CPU sysfs topology (clusters, cpufreq members, clockspeeds)
                     cpufreq   min    max
     CPU    cluster  policy   speed  speed   core type
      0       -1        0      375    1500   sifive,u74-mc
      1       -1        0      375    1500   sifive,u74-mc
      2       -1        0      375    1500   sifive,u74-mc
      3       -1        0      375    1500   sifive,u74-mc

## Governors (tradeoff between performance and idle consumption):

Original settings:

    cpufreq-policy0: ondemand / 1500 MHz (conservative ondemand userspace powersave performance schedutil)

Tuned settings:

    cpufreq-policy0: performance / 1500 MHz

## Clockspeeds:

Before:

    cpu0 (sifive,u74-mc): OPP: 1500, Measured: 1499 

After:

    cpu0 (sifive,u74-mc): OPP: 1500, Measured: 1499 

## Software versions:

  * Debian GNU/Linux bookworm/sid
  * Compiler: /usr/bin/gcc (Debian 11.3.0-3) 11.3.0 / riscv64-linux-gnu
  * OpenSSL 1.1.1f, built on 31 Mar 2020
  * Kernel 5.15.0-starfive / CONFIG_HZ=100

Kernel 5.15.0 is not latest 5.15.91 LTS that was released on 2023-02-01.

Please check https://endoflife.date/linux for details. It is somewhat likely
that a lot of exploitable vulnerabilities exist for this kernel as well as
many unfixed bugs. Better upgrade to a supported version ASAP.

All known settings adjusted for performance. System now ready for benchmarking.
Once finished stop with [ctrl]-[c] to get info about throttling, frequency cap
and too high background activity all potentially invalidating benchmark scores.

Time        CPU    load %cpu %sys %usr %nice %io %irq   Temp
22:40:33: 1500MHz  1.10  10%   1%   8%   0%   1%   0%      °C
22:41:33: 1500MHz  0.45   0%   0%   0%   0%   0%   0%      °C
22:42:33: 1500MHz  0.16   0%   0%   0%   0%   0%   0%      °C
22:43:33: 1500MHz  0.60  13%   0%  11%   0%   1%   0%      °C
22:44:33: 1500MHz  0.80  24%   0%  24%   0%   0%   0%      °C
22:45:33: 1500MHz  0.93  23%   0%  23%   0%   0%   0%      °C
22:46:33: 1500MHz  0.94  23%   0%  23%   0%   0%   0%      °C
22:47:33: 1500MHz  0.98  24%   0%  24%   0%   0%   0%      °C
22:48:33: 1500MHz  1.06  25%   0%  25%   0%   0%   0%      °C
22:49:33: 1500MHz  1.02  25%   0%  25%   0%   0%   0%      °C
22:50:34: 1500MHz  1.00  25%   0%  25%   0%   0%   0%      °C
22:51:34: 1500MHz  1.00  24%   0%  23%   0%   0%   0%      °C
22:52:34: 1500MHz  1.04  23%   0%  23%   0%   0%   0%      °C
22:53:34: 1500MHz  1.04  25%   0%  25%   0%   0%   0%      °C
22:54:34: 1500MHz  1.01  25%   0%  25%   0%   0%   0%      °C
22:55:34: 1500MHz  1.00  24%   0%  24%   0%   0%   0%      °C
22:56:34: 1500MHz  1.00  24%   0%  24%   0%   0%   0%      °C
22:57:35: 1500MHz  2.69  92%   0%  92%   0%   0%   0%      °C
22:58:37: 1500MHz  3.01  85%   0%  85%   0%   0%   0%      °C
22:59:37: 1500MHz  3.80  88%   0%  87%   0%   0%   0%      °C
23:00:40: 1500MHz  3.80  93%   0%  93%   0%   0%   0%      °C
23:01:41: 1500MHz  2.84  51%   0%  50%   0%   0%   0%      °C
23:02:42: 1500MHz  3.37  91%   0%  91%   0%   0%   0%      °C
23:03:43: 1500MHz  3.77  98%   0%  97%   0%   0%   0%      °C
23:04:46: 1500MHz  3.92  99%   0%  99%   0%   0%   0%      °C
23:05:49: 1500MHz  3.72  86%   0%  85%   0%   0%   0%      °C
23:06:52: 1500MHz  3.89  96%   0%  96%   0%   0%   0%      °C
23:07:55: 1500MHz  3.99  96%   0%  96%   0%   0%   0%      °C
23:08:55: 1500MHz  1.73  14%   0%  13%   0%   0%   0%      °C
23:09:55: 1500MHz  0.67   0%   0%   0%   0%   0%   0%      °C
23:10:55: 1500MHz  0.28   0%   0%   0%   0%   0%   0%      °C
23:11:55: 1500MHz  0.14   0%   0%   0%   0%   0%   0%      °C
^C

Cleaning up. Done.
Checking cpufreq OPP again. Done.

Clockspeeds now:

    cpu0 (sifive,u74-mc): OPP: 1500, Measured: 1499 

I also re-ran Geekbench 5 after the script was up and running:

• Before: https://browser.geekbench.com/v5/cpu/20379272
• After: https://browser.geekbench.com/v5/cpu/20380267

(Just as a point of reference)

[ThomasKaiser]

I ran your sbc-bench script (downloaded lastest revision from GitHub) and it looks like it's not able to pull the CPU temps

Can you please provide output of cat /sys/devices/virtual/thermal/thermal_zone?/type?

BTW: I've 15 JH7110 results collected but the only one where a thermal sensor below /sys/devices/virtual/thermal/ could be determined was @Icenowy's submission: Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (cpu-thermal). But since she's a wizard I would assume she hacked DT or kernel prior to do any testings.

Though on all of them sensors listed the same 120e0000.tmon-isa-0000 node with something like temp1: +45.2 C

As such please also provide output from grep . /sys/class/hwmon/hwmon?/* 2>/dev/null

(based on some guesswork sbc-bench 0.9.14 might already contain a fix for the thermal readouts with StarVision's kernel. When running mainline kernel in the future the problem shouldn't exist any more since the SoC temperature will appear as the standard cpu-thermal node below /sys/devices/virtual/thermal/)

[ThomasKaiser]

As for the identical Geekbench scores 'before/after'... in general the GB scores since Nov 2022 look all pretty similar: https://browser.geekbench.com/search?q=5.15.0-starfive

That could be an indication this kernel keeping the CPU cores all the time up at highest clockspeed regardless of the governor (something a sbc-bench -m running in idle could maybe confirm – that's a simple monitoring mode reporting sysfs clockspeeds without changing anything). If that's the case consumption (monitoring) in idle is flawed.

Talking about clockspeeds we need to keep in mind that early benchmark results were done with settings limiting the CPU cores to 1250 MHz, the 1.5GHz were only enabled later. Unfortunately Geekbench doesn't measure clockspeeds but reports only sysfs values that might be off by a little or a lot.

That's all the results collected in sbc-bench standard mode (ignore 1st entry since this was @Icenowy doing reliability testing)

Date	Clockspeed	7-zip multi	memcpy	memset
28 Aug 2022	1750 MHz	4820	1170	1120
18 Oct 2022	~1250 MHz	3490	860	790
18 Oct 2022	~1250 MHz	3470	830	790
09 Jan 2023	1500 MHz	4040	1150	860
05 Jan 2023	1500 MHz	4040	900	830
05 Jan 2023	1500 MHz	4060	910	790
30 Jan 2023	1500 MHz	4040	900	780
30 Jan 2023	1500 MHz	4040	880	770
31 Jan 2023	1500 MHz	4140	1140	850
31 Jan 2023	1500 MHz	4080	1020	820
31 Jan 2023	1500 MHz	4110	970	780
31 Jan 2023	1500 MHz	4040	990	780

[Icenowy]

在 2023-02-08星期三的 01:42 -0800，ThomasKaiser写道：

> I ran your sbc-bench script (downloaded lastest revision from > GitHub) and it looks like it's not able to pull the CPU temps Can you please provide output of `cat /sys/devices/virtual/thermal/thermal_zone?/type`? BTW: I've 15 JH7110 results collected but the only one where a thermal sensor below `/sys/devices/virtual/thermal/` could be determined was @Icenowy's submission: [Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (cpu- thermal)](http://ix.io/4a3s). But since she's a wizard I would assume she hacked DT or kernel prior to do any testings.

They made their thermal sensor driver inside hwmon subsystem, although it seems to be registering thermal zone. I built my own kernel (and my board is Star64 instead of VisionFive2).

…

Though on all of them `sensors` listed the same `120e0000.tmon-isa- 0000` node with something like `temp1:        +45.2 C` As such please also provide output from `cat /sys/class/hwmon/hwmon?/name`

[brucehoult]

Still being a RISC-V noob I'm trying to ask @brucehoult for clarification (since your review will get a massive target audience compared to other RISC-V reviews).

I don't really know exactly what is implemented in this version of the U74 core. The B extension I'm pretty is there. Scalar crypto I don't know.

Unlike prominent youtube reviewers such as Jeff, Christopher, Gary I don't yet have a board. I put in my order on Kickstarter in the first hour or so it was open, back in August. As backer #14 I have a "Super Early Bird 4 GB" coming (supposedly in November but it wasn't), and as backer #18 (I made a new account with a different email) I have an "Early Bird 8 GB coming (supposed to be in February). I don't have either yet, but they both shipped together (I mean the same day, different packages) on .. well, tracking was created on Jan 6, "shipment arrived at facility on Jan 21". They are both now in NZ with status "in transit to local depot". All timestamps are within 5 minutes of each other (usually the same minute) for both packages. Maybe I'll have them tomorrow, but surely sometime next week.

And then I can try to get them going and do some probing. I'm probably going to have to write boot loader code to give them a proper probe in their back doors and see what is really there. No promises it will be right away, especially as I'm preparing for a business trip 18-26.

As for the point about individual Geekbench benchmarks. I agree. With early boards and early CPU cores such as these, you get far more insight into looking at each result individually, not the headline number.

If you don't have AES and SHA instructions then, yes, those benchmarks are going to really really suck. RISC-V as an ISA has those instructions, but they won't be in chips on boards until probably next year.

Is it fair to include AES and SHA benchmarks in your evaluation of this board? Well, if what you do all day is SHA because you're mining bitcoin, then yes, sure. Otherwise, it's only really fair to look at the effect that slow AES or whatever has on things that normal people actually do, such as ssh/scp/https. Which might well be quite minor. Why not benchmark those?

The same for benchmarks that use SIMD, which again we need to wait 12 months or so for RISC-V chips to arrive with. If your use-case is heavy media processing then, yeah, buy something else. (although maybe there will eventually be support for the GPU doing that ... does PowerVR even support GPGPU stuff? I don't know.)

The benchmark I personally care about is basically ... compiling code. autoconf -> cmake -> ninja -> gcc -> as -> ld etc.

My two year old HiFive Unmatched does pretty well on that against a Pi 4, and I expect this board to also.

Also, I have my own stupid little primes benchmark, which I created to compare various x86 and Arm machines before I'd heard of RISC-V and before any RISC-V chips existed. Like all micro-benchmarks it's kind of crappy, but it's I think just as representative of a CPU core's performance (out to L1 cache, not including RAM or disk etc) as the similar Dhrystone and Coremark. But with the benefit of being smaller and simpler code, easy to build, deliberately quite resistant to compiler optimisation tricks. I've collected results for quite a few machines:

https://hoult.org/primes.txt

Note, a few results:

 11.190 sec Pi4 Cortex A72 @ 1.5 GHz T32          232 bytes  16.8 billion clocks
 11.445 sec Odroid XU4 A15 @ 2 GHz T32            204 bytes  22.9 billion clocks
 12.115 sec Pi4 Cortex A72 @ 1.5 GHz A64          300 bytes  18.2 billion clocks
 12.605 sec Pi4 Cortex A72 @ 1.5 GHz A32          300 bytes  18.9 billion clocks
 14.111 sec Beagle-X15 A15 @ 1.5 GHz A32          348 bytes  21.2 billion clocks
 14.341 sec Beagle-X15 A15 @ 1.5 GHz T32          224 bytes  21.5 billion clocks
 15.298 sec HiFive Unmatched RISC-V U74 @ 1.5 GHz 250 bytes  22.9 billion clocks
 19.500 sec Odroid C2 A53 @ 1.536 GHz A64         276 bytes  30.0 billion clocks
 23.940 sec Odroid C2 A53 @ 1.536 GHz T32         204 bytes  36.8 billion clocks
 27.196 sec Teensy 4.0 Cortex M7 @ 960 MHz        228 bytes  26.1 billion clocks
 27.480 sec HiFive Unleashed RISCV U54 @ 1.45 GHz 228 bytes  39.8 billion clocks
 30.420 sec Pi3 Cortex A53 @ 1.2 GHz T32          204 bytes  36.5 billion clocks
 36.652 sec Allwinner D1 C906 RV64 @ 1.008 GHz    224 bytes  36.9 billion clocks
 39.840 sec HiFive Unl RISCV U54 @ 1.0 GHz        228 bytes  39.8 billion clocks
 43.516 sec Teensy 4.0 Cortex M7 @ 600 MHz        228 bytes  26.1 billion clocks
 47.910 sec Pi2 Cortex A7 @ 900 MHz T32           204 bytes  42.1 billion clocks
112.163 sec HiFive1 RISCV E31 @ 320 MHz           178 bytes  35.9 billion clocks

It's quite interesting to me how divergent the three different Arm ISAs are on the same chip. But looking at A64 as the thing you want to compare to RV64, the HiFive Unmatched is 0.792 as fast as a Pi 4, and 1.99 as fast as a Pi 3 (sadly I don't have an A64 time for Pi 3). It's 1.27 times as fast as an Odroid C2 (a much better board than Pi 3).

I'd love to have figures for an A55 board, which is the most similar Arm microarchitecture, but don't have one.

[ThomasKaiser]

But in benchmarks (see OP, and also: https://pibenchmarks.com/benchmark/66979/), I'm only seeing about 200 MB/sec sequential read/write

How does /sys/module/pcie_aspm/parameters/policy look like?

[brucehoult]

But in benchmarks (see OP, and also: https://pibenchmarks.com/benchmark/66979/), I'm only seeing about 200 MB/sec sequential read/write

How does /sys/module/pcie_aspm/parameters/policy look like?

Note that the RAM speed might not be much more than 200 MB/sec. It's not on the HiFive Unmatched. L2 cache stream detection & prefetch were implemented (from memory) in the December 2021 version of the U74, while we believe this uses the March 2021 version.

The AllWinner D1 is a slower CPU, but actually has a decent DRAM interface, and manages 1100 MB/s on large RAM to RAM memcpy().

Well, hopefully I can try it soon. Current status "With courier for delivery 08:07am, 10 February 2023 , Whangarei". The rural delivery usually comes by here around 4 PM, so ... (11 AM now)

[ThomasKaiser]

Note that the RAM speed might not be much more than 200 MB/sec.

At least tinymembench shows this wrt memory bandwidth on this board at 1.5 GHz (see above):

standard memcpy                                      :   1154.1 MB/s (0.8%)
standard memset                                      :    858.7 MB/s (1.2%)

Unfortunately not a single execution for the HiFive Unmatched has been submitted for my sbc-bench results list.

[brucehoult]

I can't figure out from http://ix.io/4kHv what the buffer size is for those copies.

[ThomasKaiser]

I can't figure out from http://ix.io/4kHv what the buffer size is for those copies.

Me neither, can only link to project page / sources: https://github.com/ssvb/tinymembench

Do you have a tool recommendation for quick and reliable bandwidth measurements? tinymembench is orphaned and takes ages...