tkaiser

And funnily your new fanclub here is proving you right. Armbian's dead

@Lion Wang This is a benchmark. How you as the CEO take it seriously that you hired an absolute idiot providing your 'technical documentation'

This high amount of stupidity/ignorance is really impressive I really hope this @Lion Wang guy can convince other Armbians to support his false advertising campaigns.

Adding 'systemctl --user start psd 2>/dev/null' to a profile file that gets copied from skeleton dir at user creation?

Too funny: BPi R2 users buying USB WWAN modems in mPCIe form factor just to realize later that they can't use the cards since SinoVoip 'forgot' to connect pins 36/38 on the mPCIe header (pins 36/38 on mPCIe compliant devices carry the USB2 data lines necessary for all 3G/4G modems in mPCIe format)

Is NVMe exposing a PCIe 3.0 x4 interface. On SBC currently -- with some RK3399 expections (soon) -- you have either SATA or PCIe 2.x x1 (that's just 10 times slower). As already said I doubt the M.2 slot on Clearfogs can be switched to PCIe so you need SATA anyway (and you don't need to buy M.2 SSDs, the cheap M.2-SATA adapters cost less than 2 bucks) and for boot support you need SATA anyway (or a bleeding edge u-boot with PCIe storage support -- most probably not existing anytime soon or ever). Any Samsung 840/850 EVO/PRO should be ok. To be able to really make use of NVMe you need a very powerful multi-core host otherwise PCIe/AHCI or 'good old' SATA will do the job...

This is Marvell (since 'Hyper Duo' being mentioned) but you can use this thing only in PCIe M.2 slots. The Clearfogs have SATA by default routed to the M.2 slot there but I don't know whether the SERDES voodoo that's possible with the mPCI slots (switching between mPCIe and mSATA). But even if it would be possible to switch from SATA to PCIe you would get only one PCIe lane so really better use the M.2 slot for SATA (M.2 SSD or with a cheap mechanical adapter any affordable SATA device you can imagine). If you see M.2 slots you always have to check what's available at the connector (can be PCIe, SATA or even just USB only)

That's not PCIe, this is just USB2-to-SATA but of course capable of exceeding 'Class-10' speed requirements (mentioned earlier by @lvmc -- I just wanted to warn all those people who believe for whatever reasons eMMC would always be superiour since on many SBC the eMMC is just 'Class-6' and sometimes 'Class-8' so good luck if you want to write for example a video stream with 7MB/s since you will fail! BTW: Adding USB-to-SATA is easy on boards that expose their USB ports. Well, eMMC even if showing such low sequential write performance might be faster than most SD cards if it's about random IO (though when choosing a good SD card like EVO/EVO+ this is not necessarily true) but it's important to keep in mind that what we get on BPi boards is not even compliant to SD card associations 'Class-8' speed class. But given how flash memory prices still rise such low-end eMMC will spread most probably more and more (see Xunlong example above, latest OPi Plus revision only 12.5 MB/s and not 40 MB/s any more)

LOL. BPi in the meantime uses 8GB KLM8G1WEMB-B031 modules (search the web, check the specifications, do a test, realize that it's really just 6.5MB/s write). FriendlyELEC uses minimally faster eMMC (7.5 MB/s write) and on inexpensive boards only Xunlong in the past used really fast eMMC (even on the 8GB models we were talking about 40/80 MB/s write/read). But this has changed in the meantime, now Xunlong at least on the Orange Pi Plus also uses the same slow EOL eMMC FriendlyELEC uses already all the time.

Huh? The few script lines above are sufficient to 'detect' this sort of cheating. It's just that almost nobody is benchmarking correctly since people prefer Phoronix or Geekbench BS / pseudo benchmarks. See also http://wiki.ant-computing.com/Choosing_a_processor_for_a_build_farm#Devices (it's as easy as walking through all cpufreq opp and look whether a benchmark performs different or not at different clockspeeds, then you either have real throttling happening or some mechanism preventing to use some clockspeeds -- that's what we have on almost all Android kernels in the meantime)

Sysbench is pretty lightweight yes. If throttling would happen the stddev value would increase (in your case they're between 0.00 and 0.02, so that's just some background activity). And we can also do the math: 6.0117 / 5.2694 * 1536 --> 1752.3762099 24.4123 / 21.3559 * 1536 --> 1755.828263 So, thanks. Your numbers confirm that we can use sysbench in a very special mode to report real CPU clockspeeds comparing same CPU cores using same binaries where sysfs nodes and cpufreq drivers are cheating on us (really can't believe that we see this with Amlogic again after their S905/S912 desaster last year)

@willmore In case you've your 'overclocked' ODROID-C2 around running an arm64 Ubuntu Xenial (!!!) it might be worth to give the above simple sysbench run a try walking through the available cpufreq OPP and reporting results for '--num-threads=1' and '--num-threads=4'.

Yes. That's what the benchmarks are telling. I'll generate them only for ROCK64 since I tried this many times already in the past and sysbench's cpu test scales linearly with both count of CPU cores and clockspeed (in other words: it's a 'benchmark' that can not be used to model any real-world task out there since just calculating prime numbers inside the CPU cores/caches): 408: execution time (avg/stddev): 91.3720/0.00 600: execution time (avg/stddev): 61.7398/0.00 816: execution time (avg/stddev): 45.2492/0.00 1008: execution time (avg/stddev): 36.5560/0.00 1200: execution time (avg/stddev): 30.6810/0.00 1296: execution time (avg/stddev): 28.3843/0.00 I would suggest contacting Amlogic pretty soon since their next 'Amlogic is cheating on us!!1!!' drama is just around the corner (like last year when Willy Tarreau discovered that all reported S905 CPU clockspeeds above 1500 MHz were bogus)

That's 1200 MHz in reality.

Pinebook (A64) and ROCK64 (RK3328) also with Ubuntu Xenial arm64 sysbench distro package (that's important! Otherwise just numbers without meaning since sysbench is a compiler settings benchmark and not able to meausre hardware performance) echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor for i in $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies) ; do echo $i >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo -e "$(( $i / 1000)): \c" sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4 2>&1 | grep 'execution time' done Pinebook (no throttling happening -- just compare time_in_state before/after every run). CPU clockspeed above 1152 MHz are disabled by Allwinner's budget cooling settings that's why 1200 and 1344 results are the same as for the 1152, since that's the real clockspeed: 480: execution time (avg/stddev): 19.1398/0.01 600: execution time (avg/stddev): 15.2882/0.01 720: execution time (avg/stddev): 12.7485/0.01 816: execution time (avg/stddev): 11.2629/0.01 912: execution time (avg/stddev): 10.1254/0.01 960: execution time (avg/stddev): 9.5806/0.00 1008: execution time (avg/stddev): 9.0986/0.01 1056: execution time (avg/stddev): 8.6765/0.01 1104: execution time (avg/stddev): 8.3067/0.01 1152: execution time (avg/stddev): 7.9538/0.00 1200: execution time (avg/stddev): 7.9521/0.00 1344: execution time (avg/stddev): 7.9843/0.01 ROCK64 (no throttling happened): 408: execution time (avg/stddev): 23.4966/0.01 600: execution time (avg/stddev): 15.4553/0.00 816: execution time (avg/stddev): 11.3848/0.01 1008: execution time (avg/stddev): 9.1798/0.01 1200: execution time (avg/stddev): 7.6882/0.00 1296: execution time (avg/stddev): 7.1025/0.00 ROCK64 is slightly slower which most probably is related to L1 cache latencies or something like that. You'll find a lot of additional information here: https://forum.armbian.com/topic/1748-sbc-consumptionperformance-comparisons/ (see there especially that how the sysbench binary has been built is the most important factor and that sysbench numbers of devices with totally different DRAM configuration/performance show identical sysbench scores)

https://forum.armbian.com/ignore/?module=members gives me an error message (That page does not exist. Error code: 2S100/1). Can anyone confirm?

No idea, I only know that once cpufreq supports is enabled in any of the kernels we use this node should appear. Maybe it's at a different path (find /sys -name time_in_state)? Anyway: the most important information for me was: not ready yet so we have to take the above benchmark results with a huge grain of salt (@Tido's numbers look like slightly above 1.4GHz, yours like slightly below 1.5GHz, once you figured out how to reliably enable the desired clockspeeds and we can monitor the stuff through sysfs it gets interesting again).

At least I found no evidence for this. What about the output from find /sys -name "scaling_available_frequencies" cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state The sysbench numbers you generated indicate that the SoC's real clockspeed is slightly lower than 1.5GHz (the only good use case for sysbench since not depending on external memory bandwidth/latency). But we know from the past that 2 SoC vendors are cheating on us: Amlogic reporting bogus stuff through sysfs interface and same with RPi folks (where the same happens on RPi 2 and 3).

And according to sysbench it's even slightly lower (more like 1470 MHz but that is pretty close to the reported 1512 MHz). In other words: too early to do any benchmarking now

This file is original contents from RPi-Monitor. I never touched it since displaying 'free memory' is misleading anyway. The issue came up multiple times (use the google search box on the upper right please) and you might find some 'fixes', eg. https://forum.armbian.com/topic/4418-how-to-select-a-good-board-processor/?do=findComment&comment=34439

Thank you! Just to interpret the sysbench numbers: Which distro do you use, I need output from 'lsb_release -c' and 'file /usr/bin/sysbench'.

Good news: @zador.blood.stained imported (cherry-picked) vendor provided software support for Helios4 into our build system recently, I let on my host build an OMV image and it seems it's working out of the box: https://github.com/armbian/build/pull/812#issuecomment-342006038 (though some minor issues present we can focus now on).

No worries, already followed your suggestion You obviously haven't realized or read what I've written above (how easy it is to add support for this device). I had vendor fex and the optimized Armbian version as well as bananapim2zero.csc open in my editor since weeks just waiting for the company solving the mystery around voltage regulation (which for whatever reasons they aren't willing to do). I even added the gmac node correctly to 'our' fex file an hour ago but closed all 3 documents without saving now. How this thread went finally could convince me to just 'stop'.

Ask @Lion Wang, he is responsible for these designs, repeating this insane shit show even in 2017 with BPi M2 Berry. Good luck!

Thank you for confirming (and spreading more lies). I said it multiple times and hopefully I'll really learn the lesson now and start to ignore everything with BPi in its name: dealing with stupidity/ignorance is too annoying to further waste my spare time on it.