tkaiser

Me neither. Maybe @guidol can help?

Since A1 or A2 rated cards are the only reasonable choice any more for SD and TF cards here a dynamic link to a German price comparison portal that allows for filtering of results. Only A1 rated cards with at least 10 years warranty shown: https://geizhals.de/?cat=sm_sdhc&xf=5531_10~5963_A1&sort=p#productlist (Google Translate version).
 
At the time of this writing only some SanDisk A1 and Strontium A1 cards are listed there but I hope this will change soon.
 
Please remember: Only with cards that claim to be compliant to A1 or A2 specifications it's ensured that random IO performance doesn't suck. It's important to have an eye on A1 and A2 logos since why buying SD cards any more that perform worse?

Actually it's nice. It simply suffers from what almost all other tools trying to display 'CPU utilization' in some way or the other also suffer from: ignoring reality.
 
With cpufreq scaling 'CPU utilization' alone doesn't tell that much any more especially on systems where all this stuff happens very dynamically (e.g. TurboBoost on x86 where CPU cores clock from 1.2 GHz to 2.2 GHz when just one core is busy, but as soon as a second core processes stuff immediately downclock to 1.8 GHz and stuff like that. Same situation with ARM especially with big.LITTLE and/or on boards where a cheating firmware controls what's happening and the kernel not even has any clue at which clockspeeds the CPU cores are running --> fortunately only applies to Raspberry Pi and Amlogic SBC)
 
I thought several times about an utility both being correct and providing nice looking output. But apart from enhancing RPi-Monitor with templates for some ARM SoC families our armbianmonitor approach is all we came up with. Ugly but at least providing real information and not illusions:
 
root@rock64:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 10:25:43: 1392MHz 0.39 9% 2% 3% 0% 2% 0% 41.4°C 0/6 10:25:49: 600MHz 0.36 0% 0% 0% 0% 0% 0% 40.9°C 0/6 10:25:54: 1392MHz 0.41 2% 0% 1% 0% 0% 0% 45.5°C 0/6 10:25:59: 1392MHz 0.46 37% 9% 16% 0% 10% 0% 48.2°C 0/6 10:26:04: 1392MHz 0.50 29% 8% 10% 0% 11% 0% 48.2°C 0/6 10:26:09: 1392MHz 0.70 36% 8% 18% 0% 9% 0% 45.0°C 0/6 10:26:14: 1392MHz 1.37 40% 1% 0% 0% 38% 0% 44.1°C 0/6 10:26:19: 1392MHz 1.34 27% 3% 17% 0% 6% 0% 50.0°C 0/6 10:26:24: 1392MHz 1.31 25% 0% 24% 0% 0% 0% 51.7°C 0/6 10:26:29: 1392MHz 1.28 25% 0% 25% 0% 0% 0% 51.7°C 0/6 10:26:34: 1392MHz 1.26 26% 3% 22% 0% 0% 0% 51.2°C 0/6 10:26:39: 1392MHz 1.64 25% 6% 19% 0% 0% 0% 49.5°C 0/6 10:26:44: 600MHz 2.07 2% 2% 0% 0% 0% 0% 42.7°C 0/6 10:26:49: 1392MHz 1.98 24% 0% 0% 0% 22% 0% 47.7°C 0/6 Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 10:26:55: 1392MHz 1.91 24% 0% 0% 0% 24% 0% 46.4°C 0/6 10:27:00: 1392MHz 1.83 22% 1% 10% 0% 10% 0% 46.4°C 0/6 10:27:05: 600MHz 1.69 0% 0% 0% 0% 0% 0% 44.1°C 0/6 10:27:10: 600MHz 1.55 2% 0% 1% 0% 0% 0% 44.1°C 0/6^C  
This is a Rock64 running off a really crappy 4GB SD card (I got a bunch of them recently when replacing them with SanDisk Ultra A1 at a customer) doing an 'apt update'. We see cpufreq increasing, average load increasing and even overall %cpu utilization increasing. But by looking at %io we see that the whole system is often stuck in IO simply because the SD card performs horribly low when it's about random IO. See the '10:26:14' entry: 40% CPU that are in reality only waiting for the crappy SD card finishing its work.
 
That's the problem with 'CPU monitoring' on Linux in general and especially on SBC where 'crappy storage' is more rule than exception. When looking at load or CPU utilization it's all the time misleading as soon as slow performing storage is involved. Since 'Linux waiting for IO' counts as 'CPU busy / increased load'.
 
That's why I unfortunately can only recommend our ugly armbianmonitor to really get a clue what's going on...

Ah - thank you for this pointer!  This is great, exactly what I need!  

With 10,000 the kernel takes a look 100 hundred times each second, when set to 200,000 it's just 5 times any more. And this is all off-topic here as already said (but same applies to the other thread that talks about OPi Zero)
 
As a first step I tried to consolidate timer frequency settings accross all kernels since what we have today is just chaos.

Not relevant any more since it's 2018 (and we can buy A1 or even A2 rated cards). I added a dynamic link to the thread and adjusted first post accordingly:
 
 
Wrt Renegade: Currently our settings prevent using the faster modes so we're stuck on DDR50 (that's where the ~23 MB/s max originate from). Once SD card issues are resolved we can enable the faster modes and then those better cards will perform way better with the Renegade (only a few other SBC implement higher speed modes, e.g. Tinkerboard, the ODROIDs or Le Potato). Please keep in mind that my SanDisk Extreme Pro from almost 4 years ago can not be compared to something called 'SanDisk Extreme' from 2018 (since all this stuff improves)

Yesterday you only showed numbers and picture of a 'normal' SanDisk 8GB card. Those are horribly slow when it's about random IO especially at 16K block size (the SanDisk Extreme you tested later is over 100 times faster here). Usually just this makes the difference when comparing 'apt install' or 'apt update/upgrade' performance since apt does a lot of random reads and writes (and issues sync calls with the latter to ensure changes are committed to storage in the appropriate order so a crash while installing or updating won't screw up the whole package management).
 
See here for another nice report about 'random IO storage performance making the real difference'.

I'm an EE that did power optimization at Qualcomm a while back. I'll just say - if only it were that easy ! If everything lines up, yes, it's possible to drop power draw to ideal. But clearly the software (legacy vs new kernel) heavily influences actual physical temperatures on the same silicon/processor. So safe to assume the board (design, layout, components etc) is just about acceptable for this price point, even if not optimal.
 
Without a specific deep-dive into this issue, our efforts here are like band-aids the minimize the thermal performance problem with 4.x kernels rather than solve the problem at the root cause itself. IMHO, these are all 'toys' so I don't see anyone 'caring' enough to root-cause this (vs say, if this was my product line). Tinker on!

I just released some new code on github to play animated GIF files directly on a Linux framebuffer or SPI LCD (using my SPI_LCD code). It doesn't have any 3rd party dependencies and can easily be made to run on systems with no operating system or file system. This is part of my imaging library that I've been working on for more than 20 years. I'm slowly releasing parts of it as open-source. This code was sliced out of a much larger project which supports a whole bunch of image formats.
 
https://github.com/bitbank2/gif_play
 
Comments/feedback welcome.
 

Another one: https://forum.pine64.org/showthread.php?tid=6288
 

 
What can be seen at the enclosure top is a L shaped rail to be combined with thermal pads to dissipate heat away from SoC (and DRAM most probably too?) to the enclosure top cover. I think on this prototype the height of the rail is not sufficient but hey... it's a prototype most probably to check position of this rail thing (if you check the post carefully you see that it's designed for more than one board  )

Actually it's nice. It simply suffers from what almost all other tools trying to display 'CPU utilization' in some way or the other also suffer from: ignoring reality.
 
With cpufreq scaling 'CPU utilization' alone doesn't tell that much any more especially on systems where all this stuff happens very dynamically (e.g. TurboBoost on x86 where CPU cores clock from 1.2 GHz to 2.2 GHz when just one core is busy, but as soon as a second core processes stuff immediately downclock to 1.8 GHz and stuff like that. Same situation with ARM especially with big.LITTLE and/or on boards where a cheating firmware controls what's happening and the kernel not even has any clue at which clockspeeds the CPU cores are running --> fortunately only applies to Raspberry Pi and Amlogic SBC)
 
I thought several times about an utility both being correct and providing nice looking output. But apart from enhancing RPi-Monitor with templates for some ARM SoC families our armbianmonitor approach is all we came up with. Ugly but at least providing real information and not illusions:
 
root@rock64:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 10:25:43: 1392MHz 0.39 9% 2% 3% 0% 2% 0% 41.4°C 0/6 10:25:49: 600MHz 0.36 0% 0% 0% 0% 0% 0% 40.9°C 0/6 10:25:54: 1392MHz 0.41 2% 0% 1% 0% 0% 0% 45.5°C 0/6 10:25:59: 1392MHz 0.46 37% 9% 16% 0% 10% 0% 48.2°C 0/6 10:26:04: 1392MHz 0.50 29% 8% 10% 0% 11% 0% 48.2°C 0/6 10:26:09: 1392MHz 0.70 36% 8% 18% 0% 9% 0% 45.0°C 0/6 10:26:14: 1392MHz 1.37 40% 1% 0% 0% 38% 0% 44.1°C 0/6 10:26:19: 1392MHz 1.34 27% 3% 17% 0% 6% 0% 50.0°C 0/6 10:26:24: 1392MHz 1.31 25% 0% 24% 0% 0% 0% 51.7°C 0/6 10:26:29: 1392MHz 1.28 25% 0% 25% 0% 0% 0% 51.7°C 0/6 10:26:34: 1392MHz 1.26 26% 3% 22% 0% 0% 0% 51.2°C 0/6 10:26:39: 1392MHz 1.64 25% 6% 19% 0% 0% 0% 49.5°C 0/6 10:26:44: 600MHz 2.07 2% 2% 0% 0% 0% 0% 42.7°C 0/6 10:26:49: 1392MHz 1.98 24% 0% 0% 0% 22% 0% 47.7°C 0/6 Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 10:26:55: 1392MHz 1.91 24% 0% 0% 0% 24% 0% 46.4°C 0/6 10:27:00: 1392MHz 1.83 22% 1% 10% 0% 10% 0% 46.4°C 0/6 10:27:05: 600MHz 1.69 0% 0% 0% 0% 0% 0% 44.1°C 0/6 10:27:10: 600MHz 1.55 2% 0% 1% 0% 0% 0% 44.1°C 0/6^C  
This is a Rock64 running off a really crappy 4GB SD card (I got a bunch of them recently when replacing them with SanDisk Ultra A1 at a customer) doing an 'apt update'. We see cpufreq increasing, average load increasing and even overall %cpu utilization increasing. But by looking at %io we see that the whole system is often stuck in IO simply because the SD card performs horribly low when it's about random IO. See the '10:26:14' entry: 40% CPU that are in reality only waiting for the crappy SD card finishing its work.
 
That's the problem with 'CPU monitoring' on Linux in general and especially on SBC where 'crappy storage' is more rule than exception. When looking at load or CPU utilization it's all the time misleading as soon as slow performing storage is involved. Since 'Linux waiting for IO' counts as 'CPU busy / increased load'.
 
That's why I unfortunately can only recommend our ugly armbianmonitor to really get a clue what's going on...

Fancy graphics that are totally useless (even on x86). On all the ARM boards and in the meantime everywhere on x86 as well the hardware + kernel implement cpufreq scaling. On some boards we allow min cpufreq to be as low as 240 MHz while under load when no throttling occurs cpufreq can climb up to 1200 MHz.
 
Graphs that do not visualize this important fact are... 100% meaningless.
 
An SBC with 20% CPU utilization at 1200 MHz is way more busy than the same SBC with 50% CPU utilization at 240 MHz while the fancy graph will show exactly the opposite.
 
@lex' htop is better but if you really want to get a clue what's going on in Armbian you need to open a few windows and run htop, 'iostat 5' and 'armbianmonitor -m' in parallel (though with most recent armbianmonitor version you don't need iostat any more since armbianmonitor is able to display where 'average load' originates from -- on SBC the amount of %iowait percentage is crucial)
 
BTW: the concept of 'average load' especially on Linux and especially on SBC running off horribly slow storage is mostly misunderstood.

No idea what you're talking about. The cpufreq governor 'just works' (or not as expected -- see this thread). The gotop tool has no clue at which frequency the CPU cores are running so it simply graphs numbers without meaning.
 
Just tried it out on an idle Lime2. First try with our default cpufreq settings: the tool is that demanding that it already influences the system's behaviour. The Lime2 usually idles stable at 528 MHz but wenn running gotop the governor often decides to enter higher cpufreq OPP since 'too much demand'. So this is just another example of 'monitoring gone wrong' since monitoring negatively affects the system's behaviour. You watch stuff that wouldn't happen if you were not watching.
 
To test how bad the graphing is it as easy as using a fixed cpufreq. I switched to performance governor and set max cpufreq to 912 MHz, then started gotop, then waited few seconds and adjusted cpufreq to 144 MHz just to switch back to 912 MHz after some more seconds:

The system was idle all the time, it's just gotop being both pretty heavy wrt CPU usage and not caring about something that happens everywhere around since almost a decade: cpufreq scaling.
 
BTW: on ARM big.LITTLE systems gotop's output will be even more misleading.
 
I know that people will love this utility since people love colorful graphics and always prefer (meaningless) data over information. Users might have fun staring at these misleading graphs but at least for developers this tool is of no use at all (so wrong forum -- most probably the 'eye candy and fancy stuff' subforum would be better suited , SCNR)

Yes, it's only available what's defined in DT. This is related to this topic.
 
But please be careful: setting minimum cpufreq to really low values is counterproductive with some cpufreq governors since it will take a high amount of time to increase cpufreq when needed. @zador.blood.stained and me tested extensively two years ago with a lot of H3 boards and back then we found that setting boards to ~500 MHz minimum was the best compromise. When looking at temperatures or consumption there's literally zero difference between idling at 240 MHz or 480 MHz. The only important thing is DVFS (entering a state where the CPU is fed with lowest voltage possible -- so on those H3 boards with primitive voltage regulation most probably idle behaviour at 240 MHz and 816 MHz doesn't differ that much or at all).
 
Keeping minimum clockspeed at a sensible high value is especially important when thinking about storage performance since some cpufreq governors don't count I/O activity as an indication to increase CPU clockspeeds. For example SD card performance on Tinkerboard with TinkerOS sucked but not with Armbian. Only real difference: the kernel allows to downclock to 200 MHz while with Armbian our cpufrequtils package keeps minimum clockspeed at 600 MHz.
 
In Armbian we have special precautions for the ondemand governor: https://github.com/armbian/build/blob/52c71aba807f28e8325f324fba39f25e6991f7f2/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization#L59-L70
 
It seems I need to add something to tune sampling_rate as @BRSS suggested above (seems something changed with 4.14). Currently testing with
if [ -f /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency ]; then echo $(($(cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency) / 10 )) >${i}/sampling_rate fi Feedback welcomed! Anyone willing to help please edit /etc/init.d/armhwinfo and add the above after the 'echo 10 >${i}/sampling_down_factor' line, reboot and report back.
 

I actively rebase my kernel on top of rockchip-linux to keep a list of patches somehow compact. My current workflow is not very good for community contribution, still: this is rebase of commit history, but I'm happy to change that.
One thing that is probably unique about my kernel that I release a new kernel version after every: https://gitlab.com/ayufan-repos/rock64/linux-kernel/ and https://github.com/ayufan-rock64/linux-kernel and this is released as debian packages that you can put on any distro and apt-get install: http://deb.ayufan.eu/ayufan-rock64/linux-kernel. In my latest builds, I effectively moved from building kernel each time to installing kernel/u-boot package for simplicity and split of responsibility (single resp repository).
 
Anyway. I don't want to be a bottleneck, so I would say that the best would be to start a new common repo branch and rebase all our work on this branch, give a few people review/merging capabilities and based the work on the good will of people. I know that being alone and reviewing/accepting is a job that can get boring, as you also need to ensure the quality, splitting the responsibility here is desirable. Now, I do all the stuff there myself, but also I only have to check rock64/rockpro64 which is to be fair not a lot of hurdle for me, but with more dependence on this work we simply need more people.
 
I somehow like the rebase workflow that we always keep a small number of patches, but I'm fine with merge workflow too
 

With 10,000 the kernel takes a look 100 hundred times each second, when set to 200,000 it's just 5 times any more. And this is all off-topic here as already said (but same applies to the other thread that talks about OPi Zero)
 
As a first step I tried to consolidate timer frequency settings accross all kernels since what we have today is just chaos.

If @jscax is using a default/legacy image it's pretty easy to lower DRAM clockspeed with 'h3consumption -D'. And yes, undervoltage might be the culprit (the Micro USB nightmare).

If a board crashed or freezes nothing will be written to syslog so searching for the strings that appeared in the logfile long before the crash/freeze happened is pretty much useless.
 
We provide diagnosis tools, check the output of 'armbianmonitor -m' yourself (maybe post a few lines after an hour of operation) and please post the output from 'armbianmonitor -u' (since without no one has a clue which branch and kernel you're running and so on).
 
@Igor: Is this patch not applied any more? https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/adjust-default-dram-clockspeeds.patch#L244

The way both demo videos are produced it could be fakes (statically overlaying different display contents). @Da Xue just as a suggestion (from someone who had to learn to spot faked SBC demo videos): IMO it would be better if there's a little bit of human interaction overlapping the display contents at least for a short time.

OPi Zero and all the other smaller H3 boards implement DVFS with just two voltages: 1.1V and 1.3V (some interesting stuff wrt this)
 
These 912 MHz are the value we chose with legacy kernel to remain on the lower voltage but with mainline kernel it's 816 MHz instead (with legacy we used our own optimized 'Armbian settings' while with mainline we rely on 'upstream settings'). So if you want to ensure lowest consumption and heat possible with mainline kernel this needs to be adjusted to MAX_SPEED=816000 instead. The 96 MHz difference isn't important, remaining on 1.1V is.
 
Should be pretty easy to test for by setting both min and max speed one time to 816 and the other to 912MHz and then compare temperatures in idle.

Thank you for updating the post with this second picture!
 
So I would assume we have either:
one USB3 port directly connected to RK3399 and three USB3 ports behind the internal VL817 hub sharing bandwidth or all 4 USB3 ports behind the internal VL817 hub sharing bandwidth (then OTG is routed to USB-C but only as Hi-Speed?) Same Wi-Fi chip as NanoPC-T4, optional eMMC, 2 PCIe lanes available on a header... nice! I really hope NanoPi M4 and NanoPC-T4 will be as compatible as possible so we can support them with a single image

Working on NanoPi M4 these days,  almost done, Here is the other side(not final version), would be available  in August, price is $79/99 (2GB/4GB RAM).
 
 
 

 

Already available: The official NAS enclosure which opens up plenty of opportunities for specific server and NAS use cases:
 

 
Please check the product page for details (e.g. what's included and what you need to purchase separately)
 
My understanding is that the drive cage can accomodate 2 x 3.5" disks and 2 x 2.5" disks though you can only use 2 of them at the same time with Pine's own SATA card (relying on an ASM1061 -- check performance numbers here, the tests were made on an ODROID-N1 which uses same SoC and SATA chip). The ASM1061 only provides 2 SATA ports (so eSATA and SATA can't be used at the same time) and is attached with just a single PCIe lane which is fine when connecting spinning rust but will already bottleneck two SSDs since PCIe will limit overall bandwidth then.
 
Performance fanatics might skip Pine's cheap ASM1061 card and search for a PCIe card based on either ASM1062 or Marvell's 88SE9230 (both using 2 PCIe 2.x lanes, the latter providing 4 SATA ports). If it's just about attaching 4 SATA devices cards based on Marvell 88SE9215 will also do it (for performance numbers see here)
 
External powering with one single 12V PSU (it's the common barrel plug with 5.5/2.1mm, centre positive) is sufficient. For 2 3.5" disks you should choose 5A.
 
If you want to add Wi-Fi to this setup you most probably need to drill 2 holes to attach good external antennas (recommended since Pine's Wi-Fi module is a pretty decent one: AP6359SA is dual-band and dual-antenna and even RSDB capable which allows to use both bands at the same time so providing more bandwidth but especially lower latency if the AP also supports it)

That's irrelevant since it happens above the filesystem layer.
 
It's all about partition alignment. I changed this last year to 4MB boundaries.
 
This resulted in a partition alignment at 4 MB boundaries (before we were using 1 MB) so after this change less wear on SD card but '3 MB wasted'.
 
Since unlike other projects we do not promote the use of old, small and crappy SD cards and the minimum card size you get today is 16GB* I think 'wasting' 3MB on a 16GB card is nothing to care about.
 
* (personal recommendation: SanDisk Ultra A1 16GB -- but always check prices of the larger variants since at least 32GB are not that much more expensive than the 16GB variant)

You just need to understand where the bootloader on ARM boards lives and how to transfer this to an image or another SD card. Usually all this stuff lives inside the 1st MB of the SD card so cloning the first MB with dd the first time should just work. But if then later u-boot updates are provided via our Armbian repo you won't get updates on your backup image.
 
Most probably the best idea is to merge the functionality present in our nand-sata-install tool with your backup script (since nand-sata-install has to take care about writing this bootloader stuff you can study there how it works -- it's the /usr/lib/u-boot/platform_install.sh include)