StarFive VisionFive 2 #10
Comments
|
A few thoughts on methodology with a new platform like RISC-V: Crypto performance:This is two times a JH7110 board (
The 1st is slightly overclocked which ends up with better 7-zip scores, better memset numbers and way better AES scores ( 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 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 benchmarkFor 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 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... |
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. |
|
For bringup, I used these instructions to flash the simpler (800 MB) buildroot image, I should note that for the -69 version, I was going to follow the getting started guide, which says to SSH into the user
But that with the password
Instead, I used |
|
For my Kioxia XG6 NVMe SSD, I see it appear as a x1 device at 5.0 GT/sec (so presumably PCIe gen 2): 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. |
|
First attempt at running the top500 benchmark (HPL) I ran into this error during I tried Putting that on pause for now. |
|
@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: I also re-ran Geekbench 5 after the script was up and running:
(Just as a point of reference) |
Can you please provide output of BTW: I've 15 JH7110 results collected but the only one where a thermal sensor below Though on all of them As such please also provide output from (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 |
|
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 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 That's all the results collected in sbc-bench standard mode (ignore 1st entry since this was @Icenowy doing reliability testing)
|
|
在 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`
|
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: Note, a few results: 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. |
How does |
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) |
At least tinymembench shows this wrt memory bandwidth on this board at 1.5 GHz (see above): Unfortunately not a single execution for the HiFive Unmatched has been submitted for my sbc-bench results list. |
|
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? |
|
@brucehoult - Have you gotten your board yet? After my initial stab, I've been following some of the progress for support for hardware video encode/decode among other things, and I may pull it out for some more testing next week. I necessarily have to unplug and stash away the board when I am trying to get some other work done, otherwise I get sucked in for a day or two at a time :D |
|
I'm also trying to get HDMI working. Right now my monitor doesn't show anything at all (and doesn't even flash to indicate something was being output or tested), and I get the following with Reading through this post I will try to debug it and get HDMI. |
|
Created a forum post on RVSpace: Can't get HDMI Out on Debian image (modetest either) |
|
Re-testing things with the -69 (latest) image, it seems there are more annoyances, like |
|
Going to attempt to get the AMD Radeon HD 7470 working on this board using these instructions. Supposedly no patches required. Neofetch shows it if I have it connected via my PCIe 1x to 16x M.2 to slot adapter: Recompiling the kernel |
|
lspci now shows That forum post says:
Didn't see any instructions and I'm less familiar with Mesa than I'd like to admit, so I'll do a little digging. |
|
Trying to manually copy the firmware in place: And after a reboot (and
I'm not sure why, but I can't get any window manager. Looks like this might be a known issue:
|
|
I switched from my HP EliteDisplay E231 to an Atomos Ninja V, and now I can get the internal GPU to output to the display, but it's quite slow, and almost all frames are dropped trying to watch a YouTube video at 1080p. It seems like OpenGL is not supported at all, and Vulkan may be but I haven't been able to get any demos running at all yet. |
|
I also compiled The system went into some sort of lockup loop at this point—over on the main screen if I would move the mouse it would move for a fraction of a second every three seconds or so. Typing was impossible, as it would erratically accept a few letters here then discard a few later, resulting in typing "starfive" outputting to screen things like "sterve" and "sf" and "ve" and such. |
|
Here's a detailed guide from @Opvolger on how he got a Radeon 5450 running Quake II! https://github.com/Opvolger/Opvolger/blob/master/starfiveVisionFive2/FedoraATIRadeon5450.md |
|
I had the same error "pcie_plda 2c000000.pcie: AXI post error". My problem was the power supply to the PCIe board. It was not powerful enough... So put a complete ATX power supply on it. |
|
For the errors for the AMD video card. You need to add the firmware blobs to the kernel (see my readme from GitHub). Took my minimum 2 hours to figure that out. |
Ah... that makes sense—I only had my little spare 20W adapter hooked up, and the 750 Ti can draw up to 60W I think. I'll have to have another go. And for AMD, I did put the firmware in place (see comment a few above), but I am running into conflicts with the default xorg setup in the -69 Debian image. Apparently others have just switched to another userland to get around it (like you did with Fedora!). I just didn't have time to dig in further yet. Plenty to test in the future :D |
Yes! On Friday 10th. And then on the 12th Tropical Cyclone Gabrielle arrived and I was without electricity or internet for four days. And then on the 19th-26th I was away from home at a company "all hands" conference. Now trying to catch up on everything. I'll hope to have some time to look at the VF2 in the weekend. And a new image dropped today... This probably doesn't match your schedule :-( |
|
@brucehoult - Ah, just noticed the forum post (https://forum.rvspace.org/t/visionfive-2-debian-image-202302-released/2132/12) when I glanced at the forums. Looks like a few little annoyances are fixed (like Also, the fact the little boot mode switch now works could throw a lot of people off guard (having to switch the dip switches to the right configuration for SD, eMMC, etc. boot). |
|
Yes, this image is under a 700 MB download. A lot of people will be happy about the "bonus" WIFI dongle they sold us for 8 (?) SGD now working. The "What's Next - WIP" section in https://rvspace.org/en/project/VisionFive2_Debian_Wiki_202302_Release lists Firefox hardware acceleration and other GUI / GPU improvements. Give them a month for the next image with improvements in those areas? That would be quick work. |
|
The status of patches for mainline Linux support: https://rvspace.org/en/project/JH7110_Upstream_Plan Give them some time and it will be all mainline. |
|
Check out https://github.com/zhaofengli/nixos-riscv64, He is able to run more software on nixos |
|
Armbian on VF2 https://www.armbian.com/visionfive2/ Currently only two variants with Ubuntu user-land. HW support wise, similar to stock. |
|
I see that my solution with a PCIe VGA is not working on the latest JH7110_VisionFive2_devel branch. I have findout why... commit 59cf9af678dbfa3d73f6cb86ed1ae7219da9f5c9 is still working (before last week update). |
|
It is working again on the latest commit. So maybe find an AMD Radeon 200 Series, the last chipset with the old Ati kernel drivers? I keep a eye open :) |
The hostname is ubuntu, but I am running openSUSE, with an AMD ATI Radeon R9 290/390. using the amdgpu drivers no the radeon (radeon drivers gives errors). Browsing (Chromium) and Quake2 are running much better now. This comment is written on a RISC-V :) |
|
This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution! Please read this blog post to see the reasons why I mark issues as stale. |
|
You should do a retest (and maybe a new video) once this is all green (e.g. everything has been upstreamed): https://rvspace.org/en/project/JH7110_Upstream_Plan Also, watch out for this series of patches, as those enable the GPU of the JH7110: |
That series would support a series first, then b series that used on JH7110. Besides, retest should be performed on GCC13 or newer. A great performance boost was noticed (1/7 improvement on coremark score) |
|
@geerlingguy Gb v6 results if you want to add: https://browser.geekbench.com/v6/cpu/3784701 |
|
@platima - Excellent, thank you! |
Basic information
Linux/system information
Benchmark results
CPU
Power
stress-ng --matrix 0): 5.3 Wtop500HPL benchmark: TODO WDisk
SanDisk Extreme 128GB microSD
KIOXIA XG6 1GB NVMe SSD
curl https://raw.githubusercontent.com/geerlingguy/pi-cluster/master/benchmarks/disk-benchmark.sh | sudo bashRun 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 runsudo DEVICE_UNDER_TEST=/dev/sda DEVICE_MOUNT_PATH=/mnt/sda1 ./disk-benchmark.sh(assuming the device issda).Also consider running PiBenchmarks.com script.
Network
iperf3results:iperf3 -c $SERVER_IP: 937 Mbpsiperf3 --reverse -c $SERVER_IP: 774 Mbpsiperf3 --bidir -c $SERVER_IP: 941 Mbps up / 262 Mbps downI tested both 1 Gbps interfaces, and they both worked with similar results, and I could connect to two different IPs at once.
GPU
Memory
The text was updated successfully, but these errors were encountered: