tkaiser

So you got the recommendation to buy a RealTek RTL8811AU based dongle (since supported by Armbian according to @Igor), decided to ignore this trying to buy a MT7601U thingy instead that is based on (unsupported) RTL8188FTV and are now complaining that you do not get this thing to work. Why exactly?

Fine. But please always again grab latest version. I continually try to improve things resulting in better reporting. To stay focused on sbc-bench -- such cheating behaviour on some platforms like Raspberries or Amlogic SBC other than ODROID-C2 is the reason it needs detailed monitoring about what's going on. Something that should be addressed in sbc-bench from the very beginning.

Since you seem to be fine with letting your SD card wear out way too fast you could also install RPi-Monitor which will allow you to monitor your system even after crashes (RPi-Monitor constantly writes its monitoring databases to disk/card). Installation on Armbian is a one-liner: https://www.cnx-software.com/2016/03/17/rpi-monitor-is-a-web-based-remote-monitor-for-arm-development-boards-such-as-raspberry-pi-and-orange-pi/ Info wrt 'Write amplification': Edit: Monitoring write activity at the block device layer is sudo armbianmonitor -c mmcblk0

LOL, jamesh's excuse for the RPi always showing only faked cpufreq readings is really funny ('Due to using upstream code for CPU frequency reporting...'). Here his colleague Phil is explaining the real cause (their mailbox interface simply returning requested instead of real values): https://github.com/raspberrypi/linux/issues/2512#issuecomment-382703153

This is kernel functionality. For the H3 legacy kernel we had to add a mini patch (contained in our kernel by default since more than 2 years now): https://forum.armbian.com/topic/1417-g_ether-driver-h3-device-as-ethernet-dongle/ With mainline kernel it also should 'just work': see comments here: https://github.com/armbian/build/issues/538 You just need to make sure to disable g_serial module since only one USB gadget module can be active at the same time and by default we provide a serial console on the Micro USB port by default. More info can be found by using Google Site Search for 'g_ether'.

OMFG! Please calm down, grab a beer and then read here: https://www.olimex.com/wiki/A20-OLinuXino-LIME2 Especially the ALWAYS FIRST TEST WITH LATEST OFFICIAL IMAGE, NEWER HARDWARE REVISIONS OF THE BOARD MIGHT NOT WORK WITH OLDER IMAGES!!! part. Then download their latest image, burn it with Etcher and report back. You have a brand new Rev K. Lime2 and I'm not entirely sure whether Armbian boots on those (yet). BTW: It's not Olimex fault that you're unable to do some research prior to buying products ('not enough information about NAND boot on the first') and it's also not Olimex fault that Allwinner SoCs always look like refurbished parts.

@TonyMac32 do you have a /sys/devices/system/cpu/cpu0/cache node on those platforms? Seems support to report ARM cache info on 64-bit systems has been added a long time ago but needs 'next-level-cache' DT nodes. In the meantime I consolidated kernel settings so that all our kernels are able to be queried for throttling. And starting with sbc-bench v0.5 cache reporting (if available) is enabled.

They're the same from a software point of view. Most probably H2+ and H3 originate from the same wafer in the factory, then QC differentiates those SoCs that can cope with high memory bandwidths (important to display 4K video contents) and those who don't. The latter get the Gigabit MAC disabled by software, are marked as H2+ and sold for a few cents less. Maybe 4K is working flawlessly with H2+ too. Only users of Sunvell R69, BPi M2 Zero or Libre Computer Tritium H2+ owning a 4K display could tell (since the popular H2+ boards do not feature HDMI output)

Yep. But to get a better understanding of some stuff it would be highly appreciated if you could run the following test on the T3+: making the SoC quad-core: for i in 7 6 5 4 ; do echo 0 >/sys/devices/system/cpu/cpu${i}/online done sbc-bench.sh neon This will kill CPU cores 4-7 and might provide insights as how different A53 cores perform with the cpuminer stuff (that's considered optional for a reason). For example we see that S905X and RK3328 are outperformed here by S905 (without X) but have no idea yet why: https://forum.armbian.com/topic/7819-sbc-bench/?do=findComment&comment=59185 Same test with S912/Vim2 (running Debian Stretch arm64 -- otherwise it's useless) would be interesting too...

There is no 'better' It's still about generating insights and not numbers. The octa-core Nexell SoC with appropriate cooling is able to run certain demanding tasks that make use of all CPU cores in parallel faster than other SoCs. But that's it. The Samsung on the XU4 shows way better single threaded performance on a big core so most typical SBC tasks perform a lot better on the XU4 instead. Sure but why? Some numbers will improve by 4 percent and that's it.

Yep, my code gets confused by those overclock OPPs but the detailed results show clearly that execution happened all the time at the '1800 MHz' OPP that is 1730 MHz in reality (how I love all this firmware cheating ) Wrt NanoPi K2 vs. Le Potato: It's S905 (no ARMv8 Crypto Extensions) vs. S905X (there Amlogic licensed the stuff). So numbers as expected, simply compare with ODROID-C2. But it's obvious that only Hardkernel got a BS free BLOB from Amlogic whereas FriendlyELEC has to use the cheating BLOB faking cpufreqs above 1480) The cpuminer numbers for Le Potato are in sync with another A53 running at 1400 MHz (see Rock64 and Renegade based on RK3328 -- we can only compare numbers that were generated with exactly identical GCC/distro version: Stretch arm64). What's surprising is that S905 outperforms S905X and RK3328 here (maybe related to L1/L2 cache sizes or something like this) I added the new numbers to https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md -- thank you!

So why don't you run 'sbc-bench neon' then? The problem with all those benchmark numbers is that the most important information is always missing: what has really happened (other activity in the background, cpufreq behaviour, throttling, killing CPU cores and so on). You showed zero information about this (especially thermal readouts). Why not running sbc-bench to get this information? And then apply the 1.8 GHz patch, use heatsink and fan and run the test again?

Thank you! I added your results. Overall better performance but it's really interesting to see Xenial/armhf outperforming everything else again with AES crypto performance at small data chunks. Eagerly waiting for more results (from other boards) since we start to get some understanding why common benchmark results are that weird.

Please check the output. It reads 'No space left on device' multiple times. Can you provide output from 'df -h' or even 'armbianmonitor -u' please?

Yep. Funnily this kernel reports /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies in descending order so after checking the cpufreq OPPs the lowest frequency is set. Please check out latest release, I hope this and that fixed it.

https://linux-sunxi.org/H2+#Variants

FYI: 1st link got somehow corrupted and points now to https://github.com/ThomasKaiser/sbc-ben (404) @TonyMac32: are you able to provide 'sbc-bench neon' numbers for Le Potato and the Tinkerboard if time permits (using Stretch or Bionic)? And in case we have working DVFS with H5 and get with a board close to 1.4GHz (NanoPi K1 Plus? OrangePi Prime?) numbers would also be nice.

Interesting My 1.16V were just copy&paste from this entry, just realized that there is a second OPP table below with lower voltage values for higher OPP. Maybe Allwinner does chip selection after factory testing and then sells those that can cope with lower voltages at higher clockspeeds at slightly higher prices?

Suptronics/Geekworm sells RPi add-ons for a long time. They started with an add-on using the crappy/slow GL830 USB-to-SATA bridge but switched to a good JMS578 after some public complaints (see there also for the issues with GL830) Now they offer a metal box with fan kit and for their X830 USB-to-SATA board for less than 30 bucks. Power input: 14 to 40V DC via 5.5/2.5mm power barrel jack, the SBC can then be powered through GPIO header pins. Boards that should fit inside the enclosure: Any RPi Libre Computer Tritium H2+/H3/H5 Libre Computer Le Potato MiQi NanoPi K1 Plus NanoPi K2 ODROID C1/C1+ ODROID C2 Tinkerboard Rock64 Libre Computer Renegade PineH64 B NanoPi M4 (sufficient cooling will require mounting the fan not on top but next to the board) Caveats: With the 4 last boards you can either limit connection between board and the SATA-bridge to USB2 (the small adapter only transports the Hi-Speed data lines) or you need a standards violating USB3-A to USB3-A cable (which is said to be included with X830 -- no idea if it's also part of the kit). I'm not sure how a 3.5" HDD is mounted inside the enclosure and expressed my concerns about this and potential firmware issues (as well as how to solve them) with the X830 only here: https://www.cnx-software.com/2018/06/12/add-a-3-5-hard-drive-raspberry-pi-suptronics-x830-add-on-board/#comment-554303 (there you also find some more information and link to a wiki). Disclaimer: never used any of their products and not able to 'review' anything. I just thought this would be a nice combination if a 3.5" HDD should be used together with one of the supported SBC since usually 3.5" HDDs needing 5V and 12V at the same time is somewhat challenging. Edit: Just realized that it's only the enclosure + fan and you need to buy the X830 board separately. Then we're talking about a pretty expensive gadget which will be kinda ugly too with USB3 equipped boards since it needs an 80cm USB cable to externally connect SBC and disk inside the enclosure. Too bad.

If anyone manages to build a H6 kernel with ths/dvfs/cpufreq support (using @Icenowyh6-ths-ugly branch) I would be happy to receive sbc-bench numbers for PineH64... After applying this patch of course

https://forum.khadas.com/t/vim2-based-crypto-currency-miner-build/

@numbqq from Khadas executed sbc-bench on a Vim 2 with Bionic and kernel 4.17: https://forum.khadas.com/t/cpu-frequency-up-to-2ghz/2010/24?u=tkaiser I added your and his numbers + some potential insights to Results.md. So no need to re-test with Vim 2 (maybe only again with latest sbc-bench version since detailed results provide a lot more info. But I would still prefer Bionic/Stretch when testing with kernel 4.9 again )

Nope, this is not useful at all. See at the end of the thread you even referenced here! Conservative will trash storage performance. We need an appropriate method to define sampling_rate with ondemand on some platforms/kernels but as usual zero help and zero user feedback. Instead inappropriate recommendations are spread.

I added some of your numbers and insights to https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md -- IMO we're done with RPi measurements since most important lesson learned is: we always need to check firmware version first when talking about performance. The majority of performance relevant stuff on the RPi happens in the closed source domain on the VideoCore. On the other hand the average RPi user is not affected since pretty clueless and not interested in details anyway. All published RPi 3B+ benchmarks were made in March, April and May, only afterwards 1st firmware that trashed performance was released (4800f08a139d6ca1c5ecbee345ea6682e2160881 from Jun 7 2018). Now the boards in reality run as slow or even slower than the RPi 3B predecessor but as usual no one takes notice and users are happy since 'having bought the faster board' -- it's all about feelings and not reality @NicoD in case you want to visualize those 'cheating' effects in a video a nice way would be to install RPi-Monitor * and let it output in a browser windows while running 'sbc-bench.sh m' in a terminal window next to it while executing benchmarks. To my knowledge all performance monitoring solutions for the RPi rely on the Linux way of things (querying /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq) which only shows the fake clockspeeds but not the real ones. * https://rpi-experiences.blogspot.com/p/rpi-monitor.html

But please keep this stuff where it belongs to (in some of the R2 threads existing here and there). This thread is referenced from sbc-bench's README.md and already dead due to TL;DR. Can you please split everything including my post #5 above to an R2 thread (wrong thermal readouts here are not a sbc-bench problem but one of the platform or vendor software offerings)?