tkaiser

Do a web search for 'ejolson openblas linpack' or visit directly: https://www.raspberrypi.org/forums/viewtopic.php?t=208167 Number crunching benchmark when done correctly (read as: NOT using distro packages). Close to irrelevant for anything normal (since memory bandwidth/latency always matters)

First attempt on sbc-bench.sh (I'll put this later on Github) In case you still have the RPi 3B+ around it would be really great if you could let the script run without a fan (I need the throttling situation to see whether everything is reported well). The script is designed to work on normal ARM SBC as well as on the crippled Raspberries (VideoCore main CPU controlling the hardware and all the proprietary TheadX stuff). Basic requirement is either Debian Stretch or Ubuntu Bionic (or something similar with somewhat recent packages) Output from a RPi 2 with Raspbian Stretch I had access to: root@raspberrypi:/home/pi# /usr/local/bin/sbc-bench.sh Installing needed tools. This may take some time... Done. Executing tinymembench. This will take a long time... Done. Executing 7-zip benchmark. This will take a long time... Done. Executing OpenSSL benchmark. This will take a long time... Done. Below benchmark results: Memory performance: memcpy: 1013.7 MB/s memset: 1167.9 MB/s 7-zip total scores (three runs): 2134,2129,2125 OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 14216.59k 19191.70k 21097.90k 21513.56k 21793.45k 21785.26k aes-128-cbc 14147.59k 19138.28k 21094.49k 21632.68k 21673.30k 21796.18k aes-192-cbc 12802.24k 16565.27k 18059.09k 18446.34k 18352.81k 18568.53k aes-192-cbc 12807.21k 16660.76k 17955.16k 18443.61k 18557.61k 18459.31k aes-256-cbc 11806.24k 14964.78k 16007.42k 16251.22k 16460.46k 16465.92k aes-256-cbc 11738.95k 14962.37k 16062.21k 16279.21k 16455.00k 16460.46k Full results uploaded to http://ix.io/1irc. Please check the log for anomalies (e.g. swapping or throttling happenend) and otherwise share this URL. Output from a heavily throttled NanoPC-T4 with some preliminary Armbian I built few weeks ago: root@nanopct4:/tmp# /usr/local/bin/sbc-bench.sh Installing needed tools. This may take some time... Done. Executing tinymembench. This will take a long time... Done. Executing 7-zip benchmark. This will take a long time... Done. Executing OpenSSL benchmark. This will take a long time... Done. ATTENTION: Throttling occured on CPU cluster 4. Check the uploaded log for details. Below benchmark results: Memory performance (on big.LITTLE systems measured individually): memcpy: 2060.7 MB/s (0.3%) memset: 8440.3 MB/s (0.6%) memcpy: 4000.9 MB/s (0.6%) memset: 9011.0 MB/s (0.7%) 7-zip total scores (three runs): 4496,3980,3837 OpenSSL results (on big.LITTLE systems measured individually): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 91970.98k 292346.01k 630755.93k 914955.95k 1053515.78k 1065336.83k aes-128-cbc 272534.69k 638176.02k 956555.26k 1068235.78k 1137390.93k 1144930.30k aes-192-cbc 92993.86k 274024.58k 532484.78k 715422.38k 794593.96k 797059.75k aes-192-cbc 260573.74k 581688.00k 797185.54k 940168.87k 982846.12k 981581.82k aes-256-cbc 90710.94k 257319.98k 466747.22k 601770.33k 656547.84k 654611.80k aes-256-cbc 235117.07k 531296.70k 735206.31k 807839.74k 850635.43k 852792.66k Full results uploaded to http://ix.io/1irf. Please check the log for anomalies (e.g. swapping or throttling happenend) and otherwise share this URL. To let it run it's as easy as: wget -O /usr/local/bin/sbc-bench.sh https://raw.githubusercontent.com/ThomasKaiser/sbc-bench/master/sbc-bench.sh chmod 755 /usr/local/bin/sbc-bench.sh sudo /usr/local/bin/sbc-bench.sh (unfortunately needs root privileges to manipulate cpufreq governor and access monitoring data)

LOL! And once again: http://www.brendangregg.com/activebenchmarking.html

LOL, the Moronix Test Suite: https://forum.pine64.org/showthread.php?tid=389&pid=3259#pid3259 https://haydenjames.io/linux-benchmark-scripts-tools/ Unixbench: http://www.brendangregg.com/blog/2014-05-02/compilers-love-messing-with-benchmarks.html Bonnie: http://www.brendangregg.com/ActiveBenchmarking/bonnie++.html And so on... all those tools usually recommended are popular since they're easy to execute, do not care about correct benchmarking but people are happy with numbers without meaning. Good luck...

Most probably related to OOM killer settings (see here). The problem is that Debian and Ubuntu love to keep horribly outdated program versions in their repos (nice rant again). Version 9.20 that's used by Ubuntu Xenial and Debian Jessie is from 2010 (see changelog -- it's a shame to not package a more recent version). Version 16.02 now used by more recent distros is 'just' 2 years old. So to get a 'bigger picture' execution with Debian Stretch on every board would be needed.

BPi Zero means: Allwinner H2+ with 16-bit memory interface. So results should be almost the same as with NanoPi NEO (Allwinner H3 which is the same as H2+ and also 16-bit memory interface): https://forum.armbian.com/topic/7776-benchmarking-cpus-not-yet-a-research-article/?do=findComment&comment=58554 (what also matters is DRAM clockspeed and kernel version). Your BPi Zero scores 2109 while my NEO limited to 1.1 GHz scores 2088 --> same numbers. So most probably your Zero started to throttle down (quite common with small boards if they don't wear huge heatsinks) There's a reason I asked for the output of '7zr b ; 7zr b' above (executing the benchmark at least 2 times -- 'fire and forget' benchmarking is bad). Since users obviously hate monitoring (so only generating numbers without meaning) the 2nd 7z execution would show actual clockspeeds. The new 7-zip versions contain a clockspeed measuring algorithm producing something like this at the start of the benchmark: CPU Freq: 765 1192 1193 1193 1191 1193 1193 1193 1193 This confirms that the CPU cores were running at 1.2 GHz when starting the benchmark. The 2nd 7z call would run this again so if the RPi firmware in the meantime started to throttle it would be obvious by looking at these numbers. Also 2nd benchmark run would produce lower numbers so 'throttling had happened' can not be overlooked. Your RPi 3 scored 3277, my Rock64 scored 3594. Both times 4 Cortex-A53 cores. RPi 3 set to 1.2 GHz, Rock64 set to 1.4 GHz. Results more or less as expected. The RPi 3+ when really clocking with 1.4 GHz will perform also better. But as explained above RPi Trading guys rolled out a new ThreadX release (AKA 'firmware') that cripples all RPi 3+ around to throttle down to 1200 MHz even with medium loads. BTW: I'm asking here for 7-zip numbers not since I'm interested in 'RPi 3+ performance' (this is predictable since it's just a boring quad-core A53) but to demonstrate that MONITORING is important when benchmarking and that passive benchmarking always only generates numbers without meaning

The old 7-zip versions did not cope that good with low memory conditions. As we all know Debian and Ubuntu package update policies could be best described as crap 'outdated as hell' (nice rant). So only with Debian Stretch or Ubuntu Bionic distros we get reasonable results.

I would prefer to use upstream mechanisms: Altering contents of /etc/defaults/cpufrequtils when creating images but not overwriting this file afterwards as part of updates. Possible?

As expected. Personally not experienced with any RK3328 device (since never attached displays to them) but with older Allwinner SoCs I measured a ~5°C difference with HDMI active or not. It's just as adding a GPU to a PC: Wastes more energy and generates more heat. With SoCs it's more IP blocks active and HDMI PHY inside the SoC so more or less as expected (or an indication for a driver doing things correctly: detecting a display and if none present disabling stuff that's not needed)

Just curious: are you able to provide output from the 7-zip benchmark on the new RPi 3 B+? Since you're using Raspbian (judging by crappy sysbench numbers that indicate you're running a 32-bit distro on this 64-bit board) it's as easy as: sudo apt install p7zip 7zr b ; 7zr b Full output would be great. In case you updated all packages to latest version probability that you're affected by throttling (lowering sustained performance) is very high since the RPi Trading guys decided to cripple performance on all RPi 3+ to hide instability issues a few users experience: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=217056 It's also explained there that the 'firmware' is now cheating even more and even if throttling occured it can not be read out later with the 'vcgencmd' command (the cpufreq values obtained by reading /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq on any RPi 2, 3 or 3+ can never be trusted since they are faked). As usual monitoring in parallel is the most basic requirement for benchmarking (since otherwise it's just generating numbers without meaning) so you might want to think about downloading my raspimon tool and running it in parallel: wget https://raw.githubusercontent.com/ThomasKaiser/OMV4_for_Raspberries/master/overlay/raspimon /bin/bash ./raspimon This tool allows to check for real clockspeeds and throttling occuring. Output looks similar to what's shown here in the right column or in the above referenced thread in RPi forum (@jahboater is using my code from raspimon)

To keep other readers informed: The sysbench approach is BS since this pseudo benchmark does not test 'CPU performance' at all. It's a compiler benchmark but not a hardware benchmark. When using a distro on the RPi 3B+ that brings up the ARMv8 cores in ARMv8/64-bit mode the funny numbers sysbench spits out are 15 times better so naive users even think the hardware would perform 15 times faster. See results with Fedora here, see changing sysbench scores when switching/upgrading distros there, see explanation already posted again: https://www.raspberrypi.org/forums/viewtopic.php?t=208314&start=25 Sysbench's 'cpu test' is not a 'CPU performance' benchmark. It's producing only numbers without meaning. What we need instead is Active Benchmarking generating insights and not silly numbers that are wrong anyway.

Just a quick snippet below. The 'video surveillance' use case is the only one where we still use Raspberries. The encoding job is done on the proprietary VideoCore IV VPU, raspivid gets the raw h.264 stream, sends it through the network with netcat (lowest latency) and on some Armbian box the streams are received via netcat and then both recorded to disk and 'transcoded' via VLC so that they can be viewed by any RTP capable client (VLC for example): # sender raspivid -b 4000000 -t 3600000 -fps 30 -w 960 -h 540 -br 55 -co 25 -sh 25 -o - | nc -k -l 2222 # receiver (needs /bin/zsh) setopt MULTIOS nc 192.168.2.108 2222 >/sata/camera/test-3.h264 | cvlc -vvv stream:///dev/stdin --sout '#rtp{sdp=rtsp://:8554/camera1/}' :demux=h264 The slowest devices Armbian supports (Allwinner A20 boards) can cope with up to 8 or 9 streams at the same time.

Sorry, too tired of dealing with user hardware problems all the time... You can force Ethernet to Fast Ethernet (only 2 cable pairs used then) by adding 'ethtool -s eth0 speed 100 duplex full autoneg on' to /etc/rc.local above the 'exit 0' line. If this improves situation it's the cable.

Sorry, parted user here -- can't even remember what I did with fdisk last century

If 'armbianmonitor -v' reports corrupted packages then something went already horribly wrong and usually there's no easy way to recover from this other than starting from scratch. Seriously: if you have corrupted packages what should be the result if any other software calls such a corrupted library? It will just cause more and more harm.

That was my intention (to split everything starting from post #5 above to a new thread I'm preparing an intro post for within the next 2 weeks). Top post will then focus on an overview about CPU performance capabilities of different boards and when (or with which use cases) this matters. No need to hurry

Sure. That's for example one of the many symptoms of burning OS images not with Etcher when some slight data corruption happened (Etcher would've catched). Some bit flips somewhere in libraries and code jumps to wrong addresses and so on. But that's what 'armbianmonitor -v' is for (see explanation and example output above) and IIRC you also tested for this and got no corrupted packages reported?

Clearfog Pro based on Marvell Armada 388 SoC (dual core A9): Results need an explanation since 7-zip reports the board running at 1600 MHz ('CPU Freq: 793 1372 1559 1521 1584 1590 1584 1587 1586') while cpufreq driver tells us switching between 666MHz and 1332MHz Even if the CPU cores were running at 1600 MHz the numbers are still too high compared to the i.MX6 numbers generated above with a Wandboard (i.MX6 is also Cortex-A9). So maybe someone with one of the i.MX6 boards supported by Armbian can provide recent results with 'armbianmonitor -z'? Edit: Trying to confirm clockspeeds using @wtarreau's mhz tool (git clone http://git.1wt.eu/git/mhz.git/ ; cd mhz ; make ; ./mhz): root@clearfogpro:~/mhz# cpufreq-set -g performance root@clearfogpro:~/mhz# ./mhz count=645643 us50=20196 us250=100998 diff=80802 cpu_MHz=1598.087 root@clearfogpro:~/mhz# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 1332000 So for whatever reasons we have a nice mismatch between clockspeeds reported via sysfs and real clockspeeds with Armada 38x BTW: there is more stuff that needs an explanation, for example behaviour with Amlogic S912: https://forum.khadas.com/t/cpu-frequency-up-to-2ghz/2010/20?u=tkaiser

If you're a developer and build your own Armbian images/packages then yes (if you want to go the developer route maybe start here). It's a one-time change, after u-boot has been updated the new MAC address will be persistent again.

Sure. 'Browsing the web' especially if video is involved is something entirely different since this needs either really beefy CPU cores or an engine where this stuff can be offloaded to (so called 'video engine' or VPU). Situation is different on every single ARM platform and this is not related to GPU (check this link and the references there to get the difference). With Armbian legacy images for H3 boards it's possible to watch video HW accelerated since 2 years. But this only works in mpv, smplayer or smtube. Not in any browser today. Situation with Rockchip? Neither know nor care since never attached a display to any RK device lying around

Updated bootloader (u-boot). The majority of SBC does not have non-volatile storage (EEPROM or NOR flash) to store MAC addresses so these are generated dynamically from other data like 'CPU serial number' which is on Allwinner chip's derived from the so called SID. The algo to generate MAC addresses from SID changed some time ago for whatever reasons and that's why MAC addresses change (once) too when upgrading u-boot.

You would need to deactivate log2ram and most probably also adjust the commit interval in /etc/fstab. Does this also occur when running Hardkernel's 'official' Ubuntu? But first step would be to check hardware: that's the LAN cable and of course power supply (the RTL8153 USB-Ethernet chip should not be affected by voltage drop issues but who knows?). Replacing both would be the first step. Also plugging in the cable to another port on the switch/router.

Just to be clear: this was on Rock64 and you fiddled around with SD cards in an external USB card reader? Is the card reader SuperSpeed capable ('USB 3.0')?

Care to provide 'armbianmonitor -u' output to get SD card metadata? Would also be interesting if using SD Association's 'SD Formatter' can cure the card (unfortunately only available for macOS and Windows)

Ah, ok. You were really running the 'armbianmonitor -c' check testing for data integrity (I thought about a fsck first). Yeah, then the SD card is at fault and corrupting data.