Breaking News: Choosing Armbian speeds up your Orange Pi multiple times!

[tkaiser]

It's important to believe blindly in numbers! At least when you try to be mislead as much as possible!

 

Yesterday Michael Larabel from Phoronix fired up his usual set of passive benchmarking tests for the new Raspberry Pi 3 and he still uses rather questionable results for other boards to compare with (he claims that it would be sufficient to use a board with 'factory settings', run a set of synthetic benchmarks, don't analyse the results or even think about whether they could be wrong and treat the results as the truth)

 

 

RPi 3 is 4 times faster than OPi PC and 6 times faster than OPi Plus? Really?

 

If you just try to think about these graphs for a second it's obvious that there must be something wrong: Testing Orange Pi PC and Plus individually already makes no sense at all (same SoC, same settings --> same performance results to be expected) and publishing results that vary that much is alarming: either your benchmark must be wrong or the conditions or the tester. If you just think a second it's obvious that Orange Pi PC and Plus have to be faster than Banana Pi M2 (also an Allwinner ARMv7 SoC clocked a bit slower) and that you should drop any results if you experience a difference of more than 10% between both boards that must perform identical.

 

So I took our Armbian 5.05 release candidate and tested 2 of Phoronix' benchmarks on an H3 based Orange Pi (and then stopped this waste of time):

 

C-Ray: 340 with Armbian vs. 1425 according to Phoronix. Using Armbian increased the performance by over 400% (if you're dumb enough to rely on 'benchmarking gone wrong')

John the Ripper: 558 with Armbian vs. 315 according to Phoronix. Using Armbian increased the performance by 77% (if you're dumb enough to rely on 'benchmarking gone wrong')

 

Confusing! Why is Armbian way faster?! And why does choosing Armbian speeds up your Orange Pi in one case over 4 times and in the other case just by 77%? Let's have a closer look:

 

How does Armbian differ:

• We are able to use 1.3GHz as CPU clockspeed (might speed things up)
• For reliability reasons we clock the DRAM lower (might slow things down)
• Most importantly: We don't use braindead thermal throttling settings (and I used a heatsink/fan)

And the latter is the most important issue that Michael Larabel seems to miss at all when he uses the 'benchmark' results he collected sometimes ago to compare between different hardware. It's 2016 now! Each and every more recent SoC is a throttling candidate. This has to be taken into account if you want to benchmark a SoC or a board. If you ignore this your results are plain bullshit (just like Michael's).

 

When he tried to 'benchmark' Orange Pi PC and Plus he obviously ran into the problem that the vendor's budget cooling settings favoured killing CPU cores instead of thermal throttling so he obviously ended up with just one active CPU core left after some time of testing. And while this was an important finding (OS images for Orange Pis all crap more or less back then and negatively influencing performance) it's also important that this is nothing the hardware has to be blamed for.

 

The very same board running with Armbian performs more than four times faster! Think about. So obviously the benchmarks Phoronix recommends do not test the hardware but something else instead.

 

To be clear: the Phoronix test suite is fantastic when used correctly. That means ACTIVE BENCHMARKING and not collecting meaningless numbers and then relying on these worthless numbers to draw the wrong conclusions. When using the Phoronix test suite correctly you can identify performance bottlenecks and boundary conditions that affect performance easily (wrong cpufreq governor, killed CPU cores, thermal throttling, wrong settings, whatever). And also what to do to increase performance (tweaking compiler/scheduler settings, constantly trying out to optimise things until it works better).

 

The worst thing you could do with the Phoronix test suite is to collect numbers without meaning (passive benchmarking) and then use them to draw the wrong conclusions (that's what most of Phoronix' users including the author of the test suite do all the times).

 

Back to the origin again: We started with the Raspberry Pi 3 and 'benchmarking gone wrong' the Phoronix way. You really should take the numbers Michael/Phoronix published with a grain of salt since he neither mentioned whether throttling happened nor he commented on the consequences for the RPi 3 if the RPi foundation understands that it's necessary to provide a Raspbian version that is ARMv8 optimised.

 

The RPi foundation claimed the new RPi 3 would outperform the RPi 2 by 50% using questionable sysbench results. If they would've optimised their Raspbian code base for ARMv8 they could claim the RPi 3 would be at least 15 times faster. Why? Because benchmarks are always wrong and using sysbench (that calculates prime numbers) can't be used any more to compare between different ARM architectures (or architectures in general): http://forum.odroid.com/viewtopic.php?f=136&t=19158(I'm really curious whether Phoronix gets that when 'benchmarking' ODROID C2)

 

TL;DR: Benchmarking is fine as long as you use it to optimise software and to rule out insufficient hardware. When used wrong it's misleading (unfortunately that happens most of the time)

[Tido]

Testing Orange Pi PC and Plus individually already makes no sense at all (same SoC, same settings --> same performance results to be expected) and publishing results that vary that much is alarming: either your benchmark must be wrong or the conditions or the tester.

Well, I didn't look at the device, but if the PCB design is better or worse (PC vs. Plus) it can influence the performance.

What I want to say, it can make sense to test both to see how they compare.

 

Beside, I protect Michael Larabel that he cannot have deep knowledge in every IT topic i.e. ARM.

Again, I didn't look but did you leave a comment on his website about ARM v7 / v8 and throttling - I guess you did.

So he can pickup from your knowledge and do it better next time.

However, considering how broad he is reporting about IT - it is impossible to tweak all the devices.

 

In conclusion, like on the website of SinoVoip people will believe in 8cores and 2GHz and buy the shit!

Shit happens

 

Thank you for this detailed posting, it will help beginners - if they see it before they purchase on Aliexpress

[tkaiser]

Well, I didn't look at the device, but if the PCB design is better or worse (PC vs. Plus) it can influence the performance.

 

Nope, what he ran into is just thermal throttling and different strategies to deal with. The benchmark results he uses show clearly that Allwinner's kernel killed CPU cores (on the Plus more early than on the PC and that's where the 'performance' difference originates from -- it could've been also the other way around and then the PC would be slower than the Plus according to his numbers, this alone disqualifies using these numbers as indicators for hardware performance).

 

And while this finding is useful to be able to blame the software (the throttling strategy encoded into script.bin in this case) it's just weird to use these results as a performance index for the hardware. But that's what happens all the time, as Brendan Gregg calls it:

 

     Casual benchmarking: you benchmark A, but actually measure B, and conclude you've measured C.

 

 

And BTW the stuff end users are interested in (HW accelerated video decoding, GPU acceleration for gaming) isn't covered by these general purpose benchmarks at all. So relying on benchmarks that solve exotic mathematical problems is inappropriate when you try to get an idea how the SBC you want to buy behaves when it's about the real 'use cases'.

 

Good example: switching from Ubuntu Trusty to Debian Jessie with the next Armbian desktop release won't change anything regarding irrelevant Phoronix benchmark tests. But for our users it will make a huge difference since we can now ship with an up-to-date mpv package which allows HW accelerated video decoding. That's all just software, benchmark results remain the same but performance from an end user perspective explodes (no more stuttering video but smoothly even with high bit rates).

[Igor]

Benchmark results produced by maker and associative are corrupt by origin   PI magazine is a part of marketing department while their primary job is to impress people with a bunch of bull shit. Numbers are how they should be   They must be somehow higher then Rpi2 otherwise believers can be frustrated. They, by definition, doesn't want to face reality, so it's already represented accordingly. It keeps them and their faith high. 

[tkaiser]

The numbers the Pi foundation produced are fine. They show that RPi 3 is faster than RPi 2 even when running their slow ARMv6 code. So by comparing the RPi 3 numbers with other boards that are able to run code already optimised for ARMv8 you get the idea how performance might improve when they switch their software foundation to Aarch64/ARMv8 (both Pine64 and C2 are 10 to 15 times faster than RPi 3 in this 'benchmark test' since they're able to run optimised code)

 

What really scares me is how one can test different SD cards and cpufreq governors in reality and then conclude he has tested two boards instead: http://openbenchmarking.org/result/1603051-GA-ODROIDPI362

 

ODROID-C2 finished in 13 seconds and RPi 3 in 219. Is the C2 over 16 times faster when running SQLite workloads? Nope, it's just the difference a fast SD card with high IOPS and ondemand vs. performance cpufreq governor might make. And when this benchmark should be of any use then not to draw conclusions about "ODROID vs. RPi" but to check what's the most important factor for this sort of SQLite workload (disk intensive) and then either choose the storage that meets these requirements (C2 with an expensive eMMC 5.0 module or even better a Banana Pi with connected SATA SSD) or choose an appropriate platform (I wouldn't run databases on systems without ECC RAM except for read-only stuff like eg. CMS or something like this where the contained data can be reconstructed in case of failures)

[Igor]

Proper benchmarking is a complex issue. Proper presentation too. I sign on this.

 

I was only trying to look from other perspective and emphasize that they don't even try to do it right since people don't even try to doubt or think when see such comparisons. Even compared to other boards. Using of proper scientific method could produce unwanted results so you rather produce results you wanted

[cbm801]

And of course Orange Pi One wasn't included because it could take 1st place in price/benchmark.

[tkaiser]

And of course Orange Pi One wasn't included because it could take 1st place in price/benchmark.

 

Wouldn't change that much since he uses wrong numbers also when it's about board prices. He calculates $25 for the Orange Pi PC and $35 for RPi 3. No idea why he chose that numbers and not others that are even way more off.

 

For me here in Germany it's not $25 vs. $35 but the Orange Pi PC costs 17,-€ including shipping from China and the RPi 3 costs either 44,- € (best price) or if I wanted it now (what I don't do) even 48,-€ when I drive into the city to get the board. The RPi 3 costs more than 2.5 times as much as the OPi PC. And the performance gains wouldn't justify this price especially now since Raspbian is still made of ARMv6 code and Armbian improves more and more on the desktop too.

 

BTW: I played a bit around with our new desktop images (Armbian 5.05 release candidates) and this is mpv playing jellyfish-90-mbps-hd-h264.mkv absolutely smooth from http://jell.yfish.us

 

 

 

macbookpro-tk:~ tk$ slogin 192.168.83.118

tk@192.168.83.118's password: 

 

  ___                               ____  _   ____   ____

 / _ \ _ __ __ _ _ __   __ _  ___  |  _ \(_) |  _ \ / ___|

| | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | | | |_) | |    

| |_| | | | (_| | | | | (_| |  __/ |  __/| | |  __/| |___

 \___/|_|  \__,_|_| |_|\__, |\___| |_|   |_| |_|    \____|

                       |___/                              

 

Welcome to ARMBIAN Debian GNU/Linux 8 (jessie) 3.4.110-sun8i 

 

System load:   0.28            Up time:       1 min

Memory usage:  12 % of 1001Mb IP:            192.168.83.118

CPU temp:      42°C           

Usage of /:    41% of 7.3G   

 

Last login: Mon Mar  7 17:03:36 2016

tk@orangepipc:~$ sudo armbianmonitor -m

[sudo] password for tk: 

Stop monitoring using [ctrl]-[c]

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU

17:43:49: 1200MHz  0.17   3%   0%   2%   0%   0%   0%   43°C

17:43:55:  480MHz  0.15   3%   1%   1%   0%   0%   0%   43°C

17:44:00: 1296MHz  0.22   3%   1%   1%   0%   0%   0%   48°C

17:44:05: 1008MHz  0.36  22%   8%   6%   0%   7%   0%   48°C

17:44:10: 1008MHz  0.42  22%   8%   6%   0%   7%   0%   48°C

17:44:15: 1008MHz  0.46  22%   8%   6%   0%   7%   0%   47°C

17:44:20: 1008MHz  0.75  32%  11%  10%   0%  10%   0%   47°C

17:44:25: 1008MHz  0.69  23%   8%   5%   0%   9%   0%   48°C

17:44:30: 1008MHz  0.71  23%   8%   5%   0%   9%   0%   47°C

17:44:35:  480MHz  0.65  23%   8%   6%   0%   8%   0%   44°C

17:44:40:  480MHz  0.60  23%   8%   6%   0%   8%   0%   44°C

17:44:46:  480MHz  0.55   1%   0%   0%   0%   0%   0%   44°C

17:44:51:  480MHz  0.51   1%   0%   0%   0%   0%   0%   44°C^C

 

 

 

SoC temperature increases by a few degrees and CPU utilitisation is also pretty low. There are still some issues but that's stuff for GUI oriented people and not me

[jpearn]

What is interesting is that the RPi3 will throttle on stock speeds after a while, mine does this. Apparently it is hit and miss whether you can get one which will overclock at all . . .

http://www.jackenhack.com/raspberry-pi-3-overclocking/

 

Even the engineers have recommended a heatsink for hefty processing :

https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=6201&sid=600aa15ee596c0d9cb6a756ecb8ba60c&start=1075

[tkaiser]

What is interesting is that the RPi3 will throttle on stock speeds after a while, mine does this. Apparently it is hit and miss whether you can get one which will overclock at all . . .

http://www.jackenhack.com/raspberry-pi-3-overclocking/

 

 

i find it a bit amazing to not use RPi-Monitor on a Raspberry Pi where it would work out of the box without further adjustments but to hack together small scripts to monitor stuff. BTW: New version of armbianmonitor available with next release is able to flawlessly install RPi-monitor in a single step using 'sudo armbianmonitor -r' (should work on any Debian based distro and especially on Raspbian, in Armbian we install then the necessary templates for Orange Pi in a single step).

 

And then: Overclocking both CPUs and DRAM without verifying reliability is just a mess. Bit flips might lead to data corruption and crashes, drawing too much power especially when a board is powered through Micro USB is never a good idea since it will also lead to more crashes/corruption. It might be an interesting read how this discussion about 'factory default overclocking' regarding Pine64 developed over time (in the beginning it seemed a great idea to 'unlock' 1200/1344 MHz but fortunately I could convince them from staying away increasing the default 1152MHz the Pine64 ships with)

[tkaiser]

Even the engineers have recommended a heatsink for hefty processing :

https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=6201&sid=600aa15ee596c0d9cb6a756ecb8ba60c&start=1075

 

Wow, thanks for bringing that to my attention. They recommend a heatsink for what they call "heavy processing (and H.265 is probably the heaviest use case there is, with use of multi-core NEON, plus vector GPU and QPU code running)". Ok, this is H.265 with Armbian 5.05 running on a cheap Orange Pi PC:

tk@orangepipc:~$ sudo armbianmonitor -m
[sudo] password for tk: 
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU
19:25:34: 1200MHz  1.55  34%   5%  25%   0%   0%   2%   48°C
19:25:39: 1008MHz  1.43  13%   2%   6%   0%   3%   0%   47°C
19:25:44:  480MHz  1.31   1%   0%   0%   0%   0%   0%   46°C
19:25:49:  480MHz  1.21   1%   0%   0%   0%   0%   0%   46°C
19:25:55: 1008MHz  1.11   4%   1%   2%   0%   0%   0%   50°C
19:26:00: 1008MHz  1.10   4%   1%   2%   0%   0%   0%   50°C
19:26:05: 1008MHz  1.18   4%   1%   2%   0%   0%   0%   49°C
19:26:10:  480MHz  1.16  24%   6%  16%   0%   0%   0%   48°C
19:26:15:  480MHz  1.15  18%   4%  13%   0%   0%   0%   48°C
19:26:20: 1008MHz  1.14  18%   4%  13%   0%   0%   0%   48°C
19:26:25:  480MHz  1.21  15%   5%   9%   0%   0%   0%   49°C
19:26:30:  480MHz  1.11  15%   5%   9%   0%   0%   0%   46°C
19:26:35:  480MHz  1.02  15%   5%   9%   0%   0%   0%   46°C^C

Playing jellyfish-90-mbps-hd-hevc.mkv (324MB in size, 90 Mbps bitrate, 1920x1080, HEVC, Main profile, Level 5.0, Tier: high). I'm an absolute video NOOB so can anyone please confirm that we on our H3 boards can play H.265 HW accelerated while CPU utilisation is increasing just slightly while RPi 3 users have to think about overclocking and buying an heatsink already?! Really?

[blindpet]

I am guilty of using sysbench for benchmarks of the Banana Pi, unfortunately users look for these in choosing a board (sadly I did not know about armbian at the time). My primary focus was however network throughput for samba, ntfs, exfat over SATA and USB. I am curious what kind of cli benchmarks are any good besides sysbench, I would think compiling a program from source would be a better measure.

 

Looks like now that armbian is out for the Orange Pi Plus I can finally test SATA throughput properly unless you all think I should wait for a kernel or driver update?

 

I would of course appreciate any feedback on these benchmarks I prepared (additional ones for exfat vs ntfs vs ext4 and unrar par2 processing at the bottom).

[tkaiser]

Looks like now that armbian is out for the Orange Pi Plus I can finally test SATA throughput properly unless you all think I should wait for a kernel or driver update?

 

It looks like you can't do that much since the USB-to -SATA bridge used on Orange Pi Plus, Banana Pi M3 and Cubietruck plus (GL830) is simply crap. No one ever achieved more than 15 MB/s write and 30 MB/s read. This might be the slowest USB-to-SATA bridge in the world.

 

Regarding your other benchmarks: just try to understand the various discussions on this topic (also over at CNX -- the comments section and the links therein are the most interesting stuff) and please accept that passive benchmarking is always crap producing huge amounts of numbers without meaning.

[blindpet]

So it is the hardware itself for the USB to SATA bridge that is garbage? No amount of driver tweaking will help? Just trying to clarify so I don't waste my time, I never got above 20 MB/s in my old Pi Plus tests.

 

I will have a read on CNX, thanks for the link. I will include a disclaimer with future sysbench statistics.

[Da Alchemist]

 

 

The Rpi3 can not decode H.265 HW accelerated. http://www.golem.de/news/raspberry-pi-3-im-ersten-test-kein-grund-zur-eile-1603-119469-3.html

Regards

 

Playing jellyfish-90-mbps-hd-hevc.mkv (324MB in size, 90 Mbps bitrate, 1920x1080, HEVC, Main profile, Level 5.0, Tier: high). I'm an absolute video NOOB so can anyone please confirm that we on our H3 boards can play H.265 HW accelerated while CPU utilisation is increasing just slightly while RPi 3 users have to think about overclocking and buying an heatsink already?! Really?

[tkaiser]

So it is the hardware itself for the USB to SATA bridge that is garbage?

 

Yep. The only interesting thing on the Opi Plus is eMMC (I would suspect Igor gets eMMC boot support ready until release of 5.05)

 

The Rpi3 can not decode H.265 HW accelerated. http://www.golem.de/news/raspberry-pi-3-im-ersten-test-kein-grund-zur-eile-1603-119469-3.html

Regards

 

Thx for the confirmation. So we've currently the situation that a cheap $10 OPi One can play HW accelerated H.265 video where a RPi 3 fails and needs overclocking and a heatsink? Weird.

 

If we could also get HW accelerated video encoding to work on the H3 I would be more than happy...

[theguyuk]

Raspberry Pi 3 is the equivalent of a Ferrari body fitted with a model T ford engine and tires.

 

Raspberry Fanboys are always going to do their best to attract the most advertising when posting flaky benchmarks...    

 

Somebody should ask him to include hardware accelerated video in his benchmarks and how good is the Raspberry 3 in Android.

 

I have a old MK802 type Ak802 dual core A9 @ 1.2ghz  that can play better video in Android than a Rasberry.

[tkaiser]

JFTR: I let an Orange Pi PC with Armbian settings (1.3 Ghz but more importantly sane throttling settings) walk through the whole test suite: http://openbenchmarking.org/result/1603082-GA-1603083GA41

 

Quite amazing how results differ. Same with Pine64+ -- the next-to-last entry is made by me and show how A64 can shine if settings are chosen correctly (applies to both hardware -- heatsink and fan -- and software -- again optimal cpufreq/throttling settings)

[manuti]

I tried to do sysbench test in the more objective way as possible:

 

http://raspberryparatorpes.net/hardware/comparativa-de-raspberry-sysbench/

 

using the same micro SD card (not only the same model, I do with the same unit), cable, power source and peripherals connected and in this case, because is easy, with all my RPi units running the same OS installation.

 

I ordered a Orange Pi One and I will try to do this test again trying to be honest.

[tkaiser]

I tried to do sysbench the more objetive as posible

 

Nice try but still insufficient.

 

Using passive benchmarking is only great if you want to collect meaningless numbers. When you use those tests for active benchmarking purposes then it will be way more time consuming and the one thing you will do most often will be... throwing results away since they're completely irrelevant.

 

Regarding 'sysbench --cpu' and trying to compare ARMv7 and ARMv8 (applies to RPi 3 also if RPi foundation will sometimes in the future switch Raspbian's codebase to ARMv8) everything is outlined here already: http://forum.odroid.com/viewtopic.php?f=136&t=19158#p127223

 

Running sysbench storage tests on an SD card... c'mon what are yout trying to achieve? Producing numbers without meaning or just the insight that if you want to run anything storage intensive then you should avoid using SD cards at all (using eMMC when available or moving both rootfs and database storage location to USB or SATA where available).

 

This is the only lesson you can learn from any storage bench when used on SBCs! And what do people do instead? Create graphs that are based on meaningless numbers.

 

Please don't get me wrong. Synthetic benchmarks can be very useful. A storage benchmark that is done correctly might provide the insight that on an Orange Pi Plus (eMMC and an ultra slow USB-to-SATA bridge onboard) it's braindead to move the rootfs to USB (some people still call it SATA for reasons unknown to me) but instead use the eMMC since it's faster. But measuring SD card speeds on an Orange Pi Plus is just a waste of time.

[manuti]

But sometimes this is the way some people use his boards with 64GB microSD card acting like server ...

... and people like numbers, measures, graphs, ... 

When somebody ask me about the boards I have, I prefer to talk about feelings and today I prefer my old ODROID-U3 with eMMC card than others.

And sorry, I don't want to bother you, only can show some of this kind of nonsense numbers realized in a honest way and thinking how easy it would be perverting the results.

Thanks a million for your work in armbian !!!

[rodolfo]

tkaiser

Like most "benchmarking tests" the laughable Phoronix marketing slideshow forgets the "bench", the "marking" and the "tests". The title of that fraudulent opinion piece should simply be " Creating pretty pictures from randomly running irrelevant stuff on smallish boards". There is a valid point though in using stock software provided by the seller of the boards, as it is beyond the average buyer's skills to
reinvent the wheel from scratch.

Honest "benchmark tests" could be much simpler :

1. Does the seller provide the hardware he advertises ( price,delivery,quality ) ?
2. Does the seller provide appropriate working software ( OS,drivers,schematics ) ?
3. Is there a lively community interested in expanding and exchanging know-how ?
4. Does the seller provide adequate support to the user community enhancing the use of the boards ?
5. Does the board run reliably and uninterrupted for days, weeks, months, years ?

Obviously, there is no software providing these answers. There is no comparing boards without stating the purpose of the board.
There is no "general use case" for an SBC beyond "just running and wasting power", Automated testing is only useful for regression
tests, where you would vary ONE parameter at a time.

To illustrate this  :

  RasPi 2 makes a great x2goclient thin-client terminal for everyday office use.
  Why ? Because I tested it for daily use in an actual busy office, compared it to zillion-core Odroids and unsupported Chinaware (RK...)

  RasPI A+ ( no, not the expensive unavailable dinky PiZero with useless microconnectors ) is a cheap and efficient battery-run data collector for MCUs
  Why ? Because I tested running ATTINY/NRF24 connected to RasPi A+/NRF24 uplinked via WIFI. All components optimized to run efficiently on batteries.

Presently I ordered some OrangePI ONEs for testing. In the meantime I've found out that the Chinese New Year seems to last till the next one starts.
The seller's bull on the web page orangepi.org is absolutely useless, there is no working software and schematics were only released after major bitching.

 

My preferred use cases for the OrangePI ONE will be

-Thin client running x2goclient  ( basis : HW-accelerated graphics / Debian Jessie / LXDE  )
- Small headless servers utilizing fast SOC-USB without slave hubs/bridges connected ( the RasPi 1-2-3 and OPI PLUS I/O joke ) running reliably 24/7

I will definitely rely on Armbian for running the OPI ONEs as I can easily share the viewpoints expressed in the forum. Thank you for providing all the necessary
know-how, software and documentation. I hope I will be able to contribute once I get the boards for testing.

Thank you and keep up the good work !

[manuti]

tkaiser

 

Like most "benchmarking tests" the laughable Phoronix marketing slideshow forgets the "bench", the "marking" and the "tests". The title of that fraudulent opinion piece should simply be " Creating pretty pictures from randomly running irrelevant stuff on smallish boards". There is a valid point though in using stock software provided by the seller of the boards, as it is beyond the average buyer's skills to

reinvent the wheel from scratch.

 

Honest "benchmark tests" could be much simpler 

...

 

Maybe my UG802 (RK3066 dual core) with Picuntu running several days a week as torrent downloader since 2012 and update from Ubuntu 12.10 to 14.04 and I hope in next months go to 16.04 is a good example of benchmark. And also chinese people lost an opportunity to have a PiZero killer 4 years ago.

 

 

[rodolfo]

Maybe my UG802 (RK3066 dual core) with Picuntu running several days a week as torrent downloader since 2012 and update from Ubuntu 12.10 to 14.04 and I hope in next months go to 16.04 is a good example of benchmark. And also chinese people lost an opportunity to have a PiZero killer 4 years ago.

 

Yes - that is exactly what I mean. Real people doing real stuff for real. RK was progressing nicely and then unfortunately stumbled over their own greed. Actually, I would prefer a stripped OrangePi (ONE/LITE without LAN, WIFI, OTG) with 3xUSB2 and solder pads for the rest, power-optimized with a LiIon-battery-circuit for < $10. The next interesting board would be ARM64-based, exposing USB3 and featuring HW-accelerated graphics for <$20. LAN/WIFI/SATA are no problem with properly exposed USB at highspeed/superspeed, avoiding crappy components on the boards.