tkaiser

Why do you think so? Most probably it's just a fake card with Kingston printed on the surface and copied flash metadata from a Toshiba card. Kingston was pretty popular amongst fraudsters some time ago: https://www.bunniestudios.com/blog/?page_id=1022 Also how should such an app help detecting fake flash that simply reads out some (faked) metadata, looks up in a database and then displays $something? Fake cards use faked metadata. It's pointless to trust in this metadata at all (see my above link). My personal take on avoiding faked flash: Only buy A1 rated cards any more (since for the 'SBC use case' buying anything else is just a mistake) Immediately after purchase check them with either F3 or h2testw. This test will not identify modern fakes who do not fake capacity any more but use real capacity but are made out of inferior components compared to genuine cards After flashing an Armbian image with Etcher the first thing to test is 'iozone -e -I -a -s 100M -r 4k -r 16384k -i 0 -i 1 -i 2' Why? Since fake cards suck wrt especially random IO performance. The result of such an iozone test might look like this: root@rock64:~# iozone -e -I -a -s 100M -r 4k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.429 $ Compiled for 64 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner, Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone, Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root, Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer, Vangel Bojaxhi, Ben England, Vikentsi Lapa. Run began: Thu Jul 19 12:36:21 2018 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random kB reclen write rewrite read reread read write 102400 4 1272 1303 7799 7865 6380 140 102400 16384 9837 9640 15924 14124 15921 8077 The 4k number for random writes (here 140) must exceed 2000 since A1 specs require at least 500 IOPS with 4k block size, iozone reports KB/s and with 4K that means we need to multiply 500 IOPS with 4K to get at least 2000 KB/s displayed. So if iozone reports anything below 2000 here I immediately ask the seller for return/refund since the card sold is not compliant to A1 performance class. Of course it's important to buy SD cards only from sellers who have a 'no questions asked' return/refund policy.

Most boards only support DDR50 mode, some also SDR104: https://forum.armbian.com/topic/5864-librecomputer-renegade-rk3328/?do=findComment&comment=58319 (you won't exceed 80 MB/s, for more you need boards with fast eMMC interfaces: ODROIDs for example or RK3399 boards). 'Powerful' is a bit meaningless. Are you searching for 'CPU performance', for fast IO, for GPU acceleration? Do you keep in mind that some use cases require also certain amounts of RAM?

The usual underpowering syndrome is undervoltage so amperage ratings are most of the time pretty useless. Almost all those USB3 host controllers in ARM SoCs are somewhat limited (e.g. count of maximum endpoints) and putting an USB hub between disk and host is something I would try to avoid.

Me neither. Maybe @guidol can help?

Same on smartphones (at least on iOS). Pretty unusable on a small screen with this large logo hiding so much

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)

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?

Of course not. The A64 SoC is pretty limited wrt fast external interfaces (Gigabit Ethernet is the fastest). Only way to add more USB ports is adding an internal USB hub like it's done on BPi M64 (ports having to share bandwidth so not exactly an improvement).

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'.

Pressing the thumb on an idle H3 SoC without heatsink and then seeing reported temperatures decreasing by just 5°C IIRC means the SoC is at around 45°C. But I might be wrong. Anyway: the numbers you can read out via software are bogus, can not be trusted and not 'calibrated' by any means other than a hardware mod described in the other thread.

Random IO performance of the rootfs is usually the problem. I would use the iozone call from here, test SD card performance and report back.

40°C - 50°C is nothing to worry about. Glue an el cheapo heatsink like my standard one on it and it's usually 10°C less: https://linux-sunxi.org/Orange_Pi_Plus_2E#Pictures (you get them on Aliexpress: 10 piece for 5 bucks in total). Wrt voltage regulation you might want to enjoy our journey from 'H3 is overheating crap' (general opinion in 2015) to 'works just fine': https://github.com/armbian/build/issues/298#issuecomment-223659625 (especially OPi Plus 2E shows pretty good heat dissipation compared to almost all other H3 boards, just check the screenshots above)

You know that you can transfer the installation to the onboard eMMC by simply calling 'sudo nand-sata-install'? Onboard eMMC on Orange Pis is magnitudes faster than average SD cards wrt random IO.

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...

With HW acceleration this will only work with mpv, smplayer and smtube. Not in any browser due to fragmentation of the ARM VPU ecosystem. Laggy desktop is usually due to crappy SD card (Kingston is a synonym for this, their normal cards are horribly slow wrt random IO which is all that matters -- see here). And no, you can not remove voltage regulators, the OPi Plus 2E has superiour voltage regulation and is not known to overheat badly. Check with 'sudo armbianmonitor -m' for CPU utilization, CPU clockspeeds and temperatures. With a good A1 rated SD card (or after transferring the system to eMMC with nand-sata-install) the system will perform much smoother and as long as you can accept to watch YT videos only in other tools than a browser you can enjoy HW accelerated video too.

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)

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 )

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. It's just numbers without meaning. We reference the thread where everyhing is explained even from download page: https://forum.armbian.com/topic/4313-new-opi-zero-yet-another-high-temperature-issue/?do=findComment&comment=45585

As expected. As long as the DVFS settings keep the SoC at the lower voltage (1.1V) temperatures won't differ significantly regardless whether the CPU cores idle at 816 MHz, 240 MHz or 0.1 MHz. Quoting linux-sunxi wiki: 'Modern processors implement advanced clock gating for power saving purposes and if the processor is sitting on a WFI instruction, then the power consumption is already significantly reduced regardless of the CPU clock speed.' Please remember that with OPi Zero rev 1.4 thermal readouts are wrong. DRAM on OPi Zero is already downclocked to 408 MHz with Armbian so there's not much you could do to really lower temperatures (the real ones, not the wrong readouts).

Yeah, we deleted it already: https://forum.openmediavault.org/index.php/Thread/23065-Call-for-testers-OMV4-for-ARM-boards/?postID=178986#post178986 Thank you for your help though.

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.

Just had a quick look: https://github.com/friendlyarm/u-boot/commits/5532d5e641a990595156e83952049dd34cf838c0/common/board_r.c ?

Boards and even SoCs are irrelevant. It's only about kernel family and settings. See chapter 2.4 here: https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt I tested around with next branch on NanoPi Fire3, Clearfog Pro and RK3328. With those kernel settings 20,000 is way too low.

Libre Computer chose to not implement any voltage regulation on these boards so no DVFS is working, the SoC is fed with a low voltage so no higher clockspeeds possible without crashing/freezing. https://forum.armbian.com/topic/5863-librecomputer-tritium-h3/?do=findComment&comment=54927 https://forum.armbian.com/topic/5051-nanopi-neo2-cpu-frequency-issue/?do=findComment&comment=58184 BTW: there's a search function implemented in this forum...