tkaiser

Just remembered what I often did to force throttling while testing thermal issues: putting a pillow on the board. Should work in your setup within minutes

Hehe, sysbench is obviously too light since temperature remains below throttling treshold. Let's stop since only useful next test would be to remove the heatsink and that's not worth the efforts. Thank you anyway! To really test out the firmware's behaviour we would need also some GPU stuff since I would assume that once one or more GPU cores are busy the CPU cores are downclocked even more (while still reporting bogus cpufreq values through sysfs).

None exactly (I've to admit that my question was somewhat stupid). Background info: we've seen this not just once that better kernel and settings lead to higher performance which in turns leads to higher consumption which on devices with powering issues will then trigger instabilities. That's not Armbian related but a general observation (eg. the community Android builds for devices like Pine64 suffer from the 'same' problem since enabling all performance tweaks possible: users report instabilities on their board running the community Android while the vendor Android runs flawlessly). The reason can be observed by both looking at benchmark scores and a Powermeter between wall and device. Not entirely but now I think more about software issues. If you try again can you please first exchange contents of /usr/bin/armbianmonitor with https://raw.githubusercontent.com/armbian/build/master/packages/bsp/common/usr/bin/armbianmonitor and then open two more shells and execute in one armbianmonitor -m 0.5 And in the other watch -n 0.1 "dmesg | tail -n $((LINES-6))" Edit: those two shells should be via SSH to have the messages present when the board reboots again.

Which kernel version and which settings used there? Well, if I hear about spontaneous reboots my first try would be to check for underpowering. What does happen if you do the following: sudo armbianmonitor -p minerd --benchmark (this will install cpuminer we use here as tool to test for throttling and also underpowering issues)

Since almost all ARM SBC use SoCs that were made with Android or very special purposes in mind. So each SoC maker is doing his own things and we need for every chip family own software. Besides that there's optimizations needed, when you take a vendor (Android) kernel with vendor (Android) settings and combine it with a Linux userland performance will simply suck (well, today same is even true when using community's mainline stuff). That's one of the reasons Armbian exists since we did a lot of research here and ship with 'per device' optimized settings. So even if some (64-bit) SBC now start to ship with an universal bootloader I doubt you get the same overall performance booting an OpenSUSE compared to an optimized Armbian build. But things will improve but not with all SBC but only starting with ARMv8 and it will need a few more years until dedicated distros like ours aren't necessary any more. As a starting point: https://www.cnx-software.com/2014/01/31/arm-unveils-system-base-architecture-specification-to-standardize-arm-based-servers/

Is it easily possible to temporarely disable the fan? Just to verify the results and to get another probably very important insight: does the firmware also cheat on us if throttling really happens? If you have another 3 minutes then switching off the fan and trying this script would be great: #!/bin/bash echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 1512000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq while true ; do read cur_freq </sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq read cur_temp </etc/armbianmonitor/datasources/soctemp echo -e "$(( $cur_freq / 1000)) @ $(( $cur_temp / 1000)): \c" sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=8 2>&1 | grep 'execution time' done (this time with shebang line forcing bash, now the output should be correct -- my mistake before). As soon as execution time exceeds 5 seconds please stop with <ctrl>-<c> and report results. Thank you so much!

@balbes150 did you had a heatsink on the SoC? Since numbers prove that no throttling happened: 4 threads at '1.5 GHz' took 7.5821 seconds with a standard deviation of 0.00 8 threads at '1.5 GHz' took 3.7980 seconds with a standard deviation of 0.01 The results differ by factor 1.996340179 which is caused by some minor background activity but it can't be throttling since otherwise execution time with 8 threads has to be longer compared to benchmarking just on 4 cores So we're really talking about the firmware controlling the CPU (and most probably also GPU) cores behaviour being driven by some policy to lower max clockspeeds depending on the load profile (count of busy CPU cores).

Thank you. For whatever reason the executing shell seems not to be bash? Anyway, these are the numbers as table focusing on relevant cpufreq OPP: num-threads=1 100: execution time (avg/stddev): 43.1555/0.00 250: execution time (avg/stddev): 38.6359/0.00 500: execution time (avg/stddev): 36.7715/0.00 1000: execution time (avg/stddev): 36.6605/0.00 1512: execution time (avg/stddev): 25.8857/0.00 num-threads=4 100: execution time (avg/stddev): 12.2133/0.01 250: execution time (avg/stddev): 11.1908/0.00 500: execution time (avg/stddev): 10.4857/0.00 1000: execution time (avg/stddev): 9.1695/0.00 1512: execution time (avg/stddev): 7.5821/0.00 num-threads=8 100: execution time (avg/stddev): 8.8878/0.01 250: execution time (avg/stddev): 7.9328/0.01 500: execution time (avg/stddev): 6.6367/0.01 1000: execution time (avg/stddev): 4.7245/0.01 1512: execution time (avg/stddev): 3.7980/0.01 And this makes absolutely no sense (SoC running at 100 MHz being just half as fast as when on 1.5 GHz, it must be 15 times slower) Let's compare with the numbers @willmore generated on an ODROID-C2: num-threads=1 100: execution time (avg/stddev): 369.1851/0.00 250: execution time (avg/stddev): 146.8992/0.00 500: execution time (avg/stddev): 73.3360/0.00 1000: execution time (avg/stddev): 36.6221/0.00 1536: execution time (avg/stddev): 24.4123/0.00 num-threads=4 100: execution time (avg/stddev): 99.4764/0.02 250: execution time (avg/stddev): 37.7647/0.01 500: execution time (avg/stddev): 18.6581/0.00 1000: execution time (avg/stddev): 9.2395/0.00 1536: execution time (avg/stddev): 6.0117/0.00 And then let's look at what the S912 produces. Keep in mind that a task like this sysbench when running with 100 MHz has to take 10 times longer compared to running at 1000 MHz. But this doesn't happen here, Amlogic's firmware BLOB controls everything in the background and the cpu clockspeed we get displayed and we are setting are plain BS since their firmware is using different values in the background taking into account how many CPU cores are busy and most probably also throttling. That's what sysbench is telling us: fake 1 4 8 100 868 744 512 250 955 812 574 500 1000 866 686 1000 1000 992 964 1512 1448 1200 1200 So cpufreq OPP below 1000 MHz are usually (way) higher in reality but are adjusted based on $load (how many CPU cores are active). But as soon as there's heavy activity the higher cpufreq OPP are capped, S912 tells you it would be running at 1512 MHz while in reality it's at 1200 MHz. In other words: just like on Raspberry Pis we can not trust in the numbers we get/set which also makes our whole 'adjust cpufreq-utils settings' questionable (since the firmware decides on its own what's happening). Well done, Amlogic (again).

Please test both network and storage individually (iperf3 and iozone)

Any of the S912 device owners able to run the following simple benchmark on an Armbian Ubuntu Xenial image and provide complete output here? for o in 1 4 8 ; do 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=$o 2>&1 | grep 'execution time' done done Thank you! Background info: https://forum.armbian.com/topic/5570-some-basic-benchmarks-for-le-potato/?do=findComment&comment=42950 (would be interesting whether S912 is also cheating on us)

Thanks for letting us know. We always thought a distro should allow to operate a board reliably which is simply impossible when ignoring a few basic requirements (eg. avoiding crappy SD cards and underpowering issues): https://forum.armbian.com/announcement/1-1-check-power-supply-check-sd-card-and-check-other-people-experiences/ Yes, the distro should run to the next shop and buy a reliable PSU and a SD card that does not suck. That's the distro's and only the distro's job! Exactly. We (the few developers) are able to use the distro also with crappy SD cards (since we can set the magical 'boot from crap' switch). No one else can do this. Ah, almost forgot. There are also a few thousand users following the recommendations above who you use Armbian on these cheap Chinese boards without any issues. You might think about what's the difference between them and you. And now let's stop. Waste of time. Good luck with another distro

That's important to know. In fact we try to not be any popular just to avoid dealing with people rejecting reality and showing a bizarre attitude And now let's stop, you've been asked helping us diagnosing a rare issue, you refused to, now go choose another distro and be happy with whatever you will do. BTW: the only reason I answered is since the threads here in this subforum can help other users stop rejecting reality and to realize that low-level hardware issues (using ultra slow SD cards -- we block booting from such crap by intention and it's not that hard to understand why) can't be solved one layer above. Life's just too short to deal with this.

2 to be more precise: https://forum.armbian.com/topic/5617-loop-stuck/?do=findComment&comment=43265 Can now please a moderator move this thread and the other to the 'common problems' subforum?

That's great! We had a patch in the repo last year allowing users to use such very slow SD cards but we removed it by intention. Life is too short to deal with ignorants flooding the forum with weird questions that are all only related to them wanting to run their boards off of crappy SD cards. Better choose another distro if you're willing to ignore low-level hardware problems! Good luck! As soon as you can afford buying an SD card that does not suck you can give it a try again.

No, since the main reason is that this isn't related to Armbian but to the kernel you use. With mainline kernel and H3 boards most probably disabling the respective ehci1 node while leaving ohci1 as "okay" might work. With legacy kernel... no idea and will never check Providing this as configurable option (eg. an overlay) would be weird, just throw away broken USB peripherals Wrong. It's doable this way on Raspberry Pis regardless of the distribution used with RPi standard kernel. It's not related to Raspbian at all (and therefore also won't work on Chinese boards that are advertised being capable to 'run Raspberry Pi image' -- I have not checked whether Xunlong provides a Raspbian image for OPi PC but even if they do it won't work there as with RPi kernel)

Easy, just accept that the way primitive SBC distros do all their stuff is weird/anachronistic. Check /etc/NetworkManager/system-connections -- you define stuff with NM and then deploy profiles.

Normally I would say: by following our documentation and that's using 'nmtui-connect' and stop to fiddle around with weird files and configurations. The log you provided (thank you) though looks a bit suspicious. So I would advise to revert all changes you did to /etc/network/interfaces (at least remove everything wlan0 related), reboot, check your AP whether it tried to play 'security by obscurity' (MAC address filter) and then simply use nmtui-connect and use Wi-Fi. BTW: You connected an antenna already?

Nice! Thank you for reacting so promptly on me complaining here and there . Which eMMC modules do you now use on the Air? BTW: this kernel is now somewhat outdated (ok, not that much as the 3.4 other H2+/H3 board makers use), please ensure that as soon as 4.14 is ready Weidong switches to this version since 4.14 will become an LTS release (long term support). IMO you should also overthink maintaining your own mainline kernel fork since it will be just PITA to merge in all upstream changes (I recommended it already to Weidong back in March: adopt Armbian's build system to your needs -- soooo easy -- and submit patches for your own devices here just like other responsible vendors do -- eg. Olimex) On a related note: Weidong chose to implement DRAM configuration in an incompatible way compared to how it's done upstream. This led already to a lot of confusion since Linux and u-boot maintainers now look into your sources and overtake settings that aren't valid. Please remind Weidong of the problem: https://github.com/armbian/build/commit/b57c9d767ead528a54001d8728d39470e9faf5e4#commitcomment-23045104 Upstream maintainers now use wrong settings (eg. just 408 MHz for NanoPi M1 Plus while choosing 672 MHz for NEO 2 and so on) and there's a lot of confusion. The best idea would be if he could simply join this thread here: https://groups.google.com/forum/#!topic/linux-sunxi/coQGctAipgI (telling he's from FriendlyELEC and explaining which DRAM clockspeeds are meant to be used for which board and maybe why you chose to go another route than the standard way defining RAM parameter definitions) Thank you a lot for the heads-up. Such feedback from vendors is always welcome!

If these streams require 8 MB/s or less an OPi Zero should work fine. But AFAIK for tvheadend mainline kernel is recommended so you would have to wait a few weeks for new Armbian release and supported mainline kernel config for H3 boards (then it's just armbian-monitor --> "Install TV headend"). Or you use so called nightly images in the meantime: https://dl.armbian.com/orangepizero/nightly/

No way, too slow, bootloader times out. Check this link and start to buy something reliable and fast enough: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card

One 'solution' might be to downgrade the eMMC as they did on OPi Plus 2 already: https://forum.armbian.com/topic/5333-orangepi-2-plus-storage-performance-query/?do=findComment&comment=40786 -- I hope that does not happen...

These pictures are not from me (Maybe Sven Kayser?) Anyway: creating an account over at the wiki is as easy as clicking on this here. Let's help @manuti!

We have a search function (in the upper right of this web site, eg. enter tvheadend there if you need information about tvheadend), we have some documentation, we have device pages like this where you should click on 'hardware details' that should be able to answer all those questions. If you expect Orange Pis to be 100% compatible to Raspberry Pis then better stay with what you have now. Also due to this here being a way smaller community you'll need to help yourself a bit to succeed (use the search function for example).

Yes, that's known since I wrote it already hours before, it's also known that you released an 'Armbian test image' not containing this and the other necessary fixes we mentioned already above. It's nice that you confirmed 'the SinoVoip problem' (your ignorance -- it's always like talking to a wall) so let's try another way: https://archive.fo/mB1HH (besides that as pointed out to you already more than ten times within the last years: editing files on Github doesn't solve the problems your OS images have, they need update mechanisms) I don't know whether RSB is used with H3 legacy kernel (most probably that's irrelevant since no PMIC to talk to) but as usual that's stuff 'armbianmonitor -u' is made for (and 'armbianmonitor -m' with some benchmarks to verify if voltage switching is working correctly or at all).

While I agree I see no solution (since we talked about this stuff way too often with no results other than everyone is doing what he wants)