tkaiser

What's the purpose of replacing Firefox called Iceweasel with Firefox called Firefox? Please enlighten me a bit.

You're welcome. And might be able to improve the collection of quality cards: http://forum.armbian.com/index.php/topic/990-testers-wanted-sd-card-performance/
 
I'm especially interested in results from smaller cards (8GB, 16GB) and more recent SanDisk Extreme Pro/Plus.

1. Select your images ( attach files -> button : choose files ) and upload them to the forum 
 

 

 
2. Insert the displayed attachments into the forum text (Add to Post)
 

 
 
3. Preview and upload the post

Let's move this off topic to other:
specific info what we are working on general. open or join topic.  i am following this basic task handling logic I am always open for suggestions to make things different way. I am not saying my approach is the best or most perfect but sometimes I am (we are) just not in a coding mood or I am (we are) simply doing on strategy and can't focus much on tiny things and vice versa.

Thank you for your patience and for the info.
 
Here are the results for Samsung EVO 16GB, brand new (product code is MB-MP16DA/EU).
Tested on Cubietruck  with Armbian_5.07_Bananapipro_Debian_jessie_4.4.6 from the first post (adapted for cubietruck).
Results from pass No 5, 6 & 7.
 
 
 
HW info from armbianmonitor below (due to sprunge overquota)
 
 
 
I will post results for a couple more cards later this week

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)

@Thomas
 
 
@Eng-Shien Wu
 
Possible, but not really an urgent issue to deal with.

Hmm... I'm a bit lost why you post news related to 'Windows 10 on Intel' in a forum that's known for 'Linux on ARM'? At least one thing is clear: Many many of their users will get in serious trouble since just another vendor made the mistake to use the most crappy connector for DC-IN: Micro-USB. At least they were smart enough to use a LED as 'insufficient power' indicator unlike the Pine64 people for example...
 
Me personally would not buy anything that needs more than a few mA and misuses the Micro USB plug for DC-IN (and I also have the UP board with a slower Atom but focus on Linux instead).

I would better do a web search for 'overlayfs initramfs debian' and then ask if OverLayFS is available for H3 and if Armbian supports initramfs. That would be a sane approach to mount the rootfs on SD card read-only without breaking anything.

Toshiba Memory Exceria M301 8GB MicroSDXC Class 10 48 Mbps
http://sprunge.us/bSfN
brand new card, result of 3rd test
Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -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 bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 637 629 7416 7420 6402 611 102400 16 6997 7375 10210 10654 10091 63 102400 512 16026 15845 22069 22070 21991 2022 102400 1024 16468 16261 22488 22488 22443 4027 102400 16384 16558 16217 22443 22442 22440 12880

You find most if not all used methodologies/tools listed here: http://de.slideshare.net/brendangregg/broken-linux-performance-tools-2016
 
On a SBC I would always take care to use a minimalistic monitoring approach since when the monitoring task starts to influence the behaviour of the system (always running at highest clockspeeds for example when interactive performance governor is used) then this is simply 'Monitoring gone wrong'.
 
Another huge difference when we're talking about more recent SBCs is the thermal/throttling and dvfs/cpufreq behaviour. Not taking that into account and looking at something more or less useless like 'load average' is just fooling yourself (without taking notice). So if you've fun watching at meaningless graphs this might be great. Otherwise better stay away from it unless it serves ok for specific use cases you're an expert in (networking stuff for example)
 
Please just think a few seconds about a monitoring approach that does not monitor CPU clockspeeds and throttling strategies either. Is having an average CPU utilisation of 50% 'bad'? When the system is downclocking to 240 MHz at the same time to save energy and lower temperatures? Is it better when the system only shows 10% CPU utilisation since cpufreq settings let it run at 1200 MHz instead (and the SBC consumes twice as much energy due to dvfs settings)?

Warning: This whole thread is only about historical information now since it's 2018 and we can buy inexpensive and great performing A1 rated SD cards in the meantime. Buying anything else is a mistake so directly jump to the end of the thread for performance numbers and recommendations.
 
 
 
Edit: See an early 2017 update at the end of the thread regarding new SD specs also covering random IO performance.
 
Edit 2: Some thoughts/observations on lifespan/reliability of SBC storage: http://tech.scargill.net/a-question-of-lifespan/ (see also/especially the comments there)
 
Edit 3: CNX Software picked up recent performance reports (eg. by Andreas Spiess) and other important issues around SD cards: http://www.cnx-software.com/2017/06/13/micro-sd-cards-for-development-boards-classes-tools-benchmarks-reliability-and-tips-tricks/
 
Edit 4: See an early 2018 update testing real world A1 performance class products at the end of the thread.
 
Edit 5: See here and there for some rather boring but very important information about Armbian's tries to prevent SD cards wearing out too fast.
 
 

 
Preparations:
 
I tested 8 different SD/TF cards under identical conditions. I created an Armbian 5.07 image to be used on Banana Pi (A20 SoC with 4.4.6 kernel, ext4 rootfs (Armbian defaults == no journal), 960MHz scaling_max_cpufreq, scaling_governor == performance. All test runs were done using 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' and monitored using 'sudo iostat 5' for anomalies (none detected).
  Kernel version matters (since with Allwinner's 3.4 kernel sequential throughput is limited to ~16MB/s, with mainline kernel we get close to Banana Pi SDIO implementation's max: ~23MB/s) and filesystem settings matter too (enabled journal for example slows down 4K writes a lot).   Sequential speeds:     Random I/O:     The 4 Samsung cards were bought within the last 3 weeks and manufactured between 09/2015 and 12/2015 according to the card's metadata. Interesting observation: I used three of these cards the first time and they all show identical behaviour especially regarding writes with small record sizes: pretty slow in the beginning and getting faster over time (the Samsung Pro for example started with only 1400KB/s 4K writes and 3 runs later the same test showed 3270KB/s -- maybe an indication that some sort of calibration happened. Anyway: I know why I always repeat tests and do not rely on a single test run)   Sequential speed mostly irrelevant / random I/O differs and matters a lot!   The SanDisk Extreme Pro has been bought nearly 3 years ago. This card shows superior sequential read/write performance compared to the three Samsung EVOs. But only when used in combination with a host that can make use of these speeds. My MacBook writes 4 times faster an OS image to the Extreme Pro compared to the EVOs. But this doesn't matter at all since the SDIO implementation of the board in question is limited to ~23MB/s (50MHz @ 4 bit). The same sequential write/read speed limitation applies to most SBCs since to be able to exceed this slow mode the voltage the SD/TF card is fed with would've to be adjusted (default 3.3V, the faster modes require a dynamic switch to 1.8V instead which some/most SoCs can perform but if the SBC vendor doesn't implement this you're limited to ~23MB/s).   Therefore cards labeled as being capable of "up to 90MB/s" do not perform different than those that can only do "up to 20MB/s" as long as we're talking about sequential transfers since the SD card interface is already the bottleneck. But since we're using SD/TF cards not in cameras but as storage media for the rootfs of an SBC something different is more important: Random I/O. And here performance of cards that are labeled identical ('class 10' for example) differs a lot.   All 4 Samsungs outperform the other cards easily in this area. The SanDisk Extreme Pro can not compete regarding random I/O compared to superiour (but mostly irrelevant) sequential transfer speeds. And funnily the 3 other cards show horribly slow random write performance, especially with 16k record size. According to card metadata the 2 Intenso are oemid 0x5048 / manfid: 0x000027 (cheap crap known to die way too early) and I would believe the SanDisk 'class 10' card is a fake or at least uses the same controller as the 2 Intenso since 16K random writes are also way slower than 4K writes.   Detailed results (summary table also available as .ods, .xlsx or .txt):   Samsung Pro 64GB (brand new) http://sprunge.us/DEYd   Samsung EVO+ 64GB (brand new) http://sprunge.us/NLQd   Samsung EVO+ 32GB (brand new) http://sprunge.us/heGL   Samsung EVO 64GB (already used some time) http://sprunge.us/DUOS   SanDisk Extreme Pro 8GB (already used some time) http://sprunge.us/ZPFZ   SanDisk 'Class 10' 8GB (already used some time) http://sprunge.us/OHjT   Intenso 'Class 10' 16GB (already used some time) http://sprunge.us/LUMZ   Intenso 'Class 4' 4GB (already used some time) http://sprunge.us/GbAY   Some updates from Igor (still showing superiour EVO results but the clear winner is ODROID's eMMC module with SD card adapter):   Transcend Premium 300x 16GB (almost new) http://sprunge.us/UcSD  
 
 
Sandisk Extreme Pro 8Gb (almost new) http://sprunge.us/aDJJ
 
 
 
Hardkernel eMMC 8G via SD reader (brand new) http://sprunge.us/SHXF
 
 
 
Sandisk Ultra 8Gb (old and very used) http://sprunge.us/OWZf
 
 
 
Sandisk 8GB (almost new) http://sprunge.us/iViT
 
 
 
Sandisk 8G (new) http://sprunge.us/XHjj
 
 
 
Transcend 8Gb (used) http://sprunge.us/NTRT
 
 
 
Samsung EVO 32Gb (brand new) http://sprunge.us/bTQh
 
 
    Further readings: http://www.bunniestudios.com/blog/?page_id=1022 http://thewirecutter.com/reviews/best-microsd-card/ http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card http://www.bradfordembedded.com/2014/05/flashbenching/ Conclusions:
If the board's SD card interface is the bottleneck since it's not supporting the faster SDIO modes using expensive cards that exceed the interface's maximum sequential bandwidth is useless. An expensive Samsung Pro Plus won't be faster than a way more cheap EVO when it's about sequential transfer speeds since you will stay at ~22MB/s anyway Sequential read and especially write speeds are all the SD association's speed ratings are about (to ensure reliable recording of videos/images in cameras/recorders) When an SD card is used in an SBC sequential speeds aren't that important. It's all about random I/O, especially with small block sizes (reading and writing small random chunks of data from/to the card) No commonly used 'random I/O' speed ratings exist so you have to check the card in question prior to usage or rely on appropriate benchmarks (see the two links directly above). Again: the 'speed class' won't tell you anything. You can get two different 'class 10' cards that differ by 500% or even more regarding real world storage performance (again: random I/O matters). In the example above the Intenso 'class 10' card is 385 slower compared to the EVOs when it's about 16K random writes (good luck if you have a database running that uses this page size) Interestingly more expensive cards are outperformed by cheaper ones (the EVOs show a better overall performance compared to the Samsung Pro since sequential speeds are limited by the interface) One extreme example: Using an identical cloned installation that was somewhat outdated on the small 4GB Intenso card and on the 64GB EVO resulted in the following times for an 'apt-get upgrade' (+200 packages): EVO less than 6 minutes vs. 390 minutes (yes, ~6.5 hours) with the Intenso. The time to finish depends largely on fast random writes. It's easy to test the card in question when running Armbian since we ship with iozone. Therefore simply execute the iozone call from the first paragraph after logging in as a normal user. Starting with Armbian 5.06 a even better method exists that also tests the whole card for errors: armbianmonitor -c will report precisely both performance and health state of your card

So in other words: You did not test the SD card using F3 or H2testw in the meantime?

Finally is in Spanish, I don't know why the system refuse to change for the first time. The worst thing is that: I don't know what of the many files touched and changed things is the way to change the Desktop language.

With CMA enabled:
http://mirror.igorpecovnik.com/test/CMA-linux-image-sun8i_5.07_armhf.deb
 
Build tools also updated, I have done few tests and encounter no problems.

Running Android you are able to use GPU/VPU with HW acceleration and the ARM cores aren't used that much. Unfortunately linux is a different story and you'll come across users that really like to benefit from the 'quad-core A53 at 1.2GHz' since you advertise this as an SBC. Then you probably realise the difference (Allwinner SoCs aren't fast but cheap. Since the A64 is said to be able to be clocked up to 1.2 GHz I would suspect it's rather slow compared to other A53 designs and produced in an inefficient 28nm 40nm process)
 
Regarding benchmarks: They're all wrong. A good starting point when it's only about CPU performance is http://slideshare.net/brendangregg
 
But in your situation there's something special: Since you focus on Android CPU performance doesn't matter that much. It's GPU/VPU performance and the former definitely sucks (Mali400MP2 -- old and slow). But most people won't realise that since they focus on irrelevant metrics like "64 bit is twice as much as 32 bit" or "2 GB RAM is twice as much as 1 GB" or "15$ is less than $16" even if they can't tell how that really affects their use cases. You're lucky guys
 
But in case you really want to provide a good 'Linux experience' there's a lot to do.

In what are you interested?
 
Paid consultancy to 'bring up Linux BSP to Ubuntu' (quite easy: simply fix the BSP you got from Allwinner here and there and add any Ubuntu rootfs you find somewhere on the net. Then you've fulfilled what 'the community' already expects: just another broken OS image for a new Allwinner SoC without 2D/3D acceleration and no HW accelerated video encoding/decoding)?
 
Or should the community do this job for free and hack together such an annoying OS image?

All 4 cards are not new, and since this took quite some time, I collected armbianmonitor link only from 1st run: http://sprunge.us/AQDT
Filesystem is ext4 with default settings.
 
Toshiba, class 4, 16GB
 
 
 
Transcend, class 10 UHS-I, 16GB

 
 
Transcend, class 10, 16GB

 
 
Toshiba, class 10, 8 GB

 

I prepared new kernel based on recent H3 Allwinner code. Code was found here: https://github.com/friendlyarm/h3_lichee than it was cleaned and moved to my repository:
https://github.com/igorpecovnik/linux -b sun8i On the top there are additional 100+ patches. I am still working on patches so they are not online yet, but you can try first build and compare to old kernel.
 
Download deb package (dpkg -i linux-image-sun8i_5.07_armhf.deb)
 
Patches regarding thermal, video mode changing and camera are missing. They need further inspection and adjustments.

In what are you interested?
 
Paid consultancy to 'bring up Linux BSP to Ubuntu' (quite easy: simply fix the BSP you got from Allwinner here and there and add any Ubuntu rootfs you find somewhere on the net. Then you've fulfilled what 'the community' already expects: just another broken OS image for a new Allwinner SoC without 2D/3D acceleration and no HW accelerated video encoding/decoding)?
 
Or should the community do this job for free and hack together such an annoying OS image?

Transcend Premium 300x 16GB (almost new) http://sprunge.us/UcSD

 
 
Sandisk Extreme Pro 8Gb (almost new) http://sprunge.us/aDJJ
 
 
 
Hardkernel eMMC 8G via SD reader (brand new) http://sprunge.us/SHXF
 
 
 
Sandisk Ultra 8Gb (old and very used) http://sprunge.us/OWZf
 
 
 
Sandisk 8GB (almost new) http://sprunge.us/iViT
 
 
 
Transcend 8Gb (used) http://sprunge.us/NTRT
 
 
 
Sandisk 8G (new) http://sprunge.us/XHjj
 
 
 
Samsung EVO 32Gb (brand new) http://sprunge.us/bTQh
 
 

Again: Use a good heatsink, use thermal paste and most importantly: Let convection do the work.
 
I have a cheap port multiplier here that automatically starts to corrupt data under load due to overheating:
 

 
After I attached a heatsink and operated the thing vertically problems were gone:
 

 
 
And the good news is: The way convection works the better it cools parts that get hotter than others.

Overview:
 
SinoVoip sent me a few days ago a review sample of their new Banana Pi M2+. It's based on Allwinner's H3 SoC and tries very hard to be a 99% clone of Orange Pi Plus/PC. SinoVoip chose to stay compatible to nearly all pin mappings therefore any OS image that works on Orange Pi Plus will also work on BPi M2+ but some things need adjustments.
 
BPi M2+ features GBit Ethernet, eMMC, 2 USB host ports and one USB OTG that do not have to share bandwidth (no internal USB hub used and H3's 3rd USB host port unused unfortunately), Ampak AP6212 to provide WiFI/BT, fortunately no crappy USB-to-SATA bridge, a CSI interface to be used together with an OV5460 5MP camera module and... no programmable voltage regulator for the SoC.
 
Since it's based on the H3 SoC it's incompatible to all other Banana Pi variants and almost everything you can expect is already known. As usual you find the most recent and comprehensive information for any board based on Allwinner SoCs in the linux-sunxi wiki: http://linux-sunxi.org/Sinovoip_Banana_Pi_M2%2B
 
Compatibility:
 
The SoC's pins are routed to the externals exactly like on Orange Pi Plus/PC so it was pretty easy to create a device tree file for mainline kernel by using everything from Orange Pi Plus and replacing USB definitions with the stuff from Orange Pi PC (deleting the usb3 node since not existent) and here we are: Banana Pi M2+ is supported by mainline kernel with working USB, eMMC, GBit Ethernet and WiFi/BT already and as soon as display support and so on are available for H3 BPi M2+ benefits automagically from it.
 
Situation with kernel 3.4 is the same: In Armbian we support the board already since it was just adoption of SinoVoip's settings (and correction where they're horribly wrong -- see below when it's about performance). Since it's 'just another H3 board' software support will progress nicely and maybe the best news: You are not forced to use OS images from SinoVoip since you can rely on the community's work instead (Armbian for example).
 
Documentation and support provided by vendor:
 
To sum it up: still the usual horrible 'SinoVoip experience' we already know. They still don't get why correct information might matter. 'Documentation' is not written by engineers but instead trainees playing 'copy&paste gone wrong'. According to their website the board is either '55mm square' or 65x65mm, features 'Power led, Status led' (in reality just one led), has a 'CAN bus' (wrong for all their last SBCs, this is still moronic copy&paste from the first Banana Pi whose A20 SoC is CAN capable) and so on... you never know whether the information provided there is information or just the usual copy&paste errors they're famous for.
 
It gets even worse when you look into the vendor's so called 'documentation': There the M2+ is most of the times called M3 ("BPI-M2+ USB interface: BPI-M3 have two USB 2.0 interface on board"), the onboard WiFi chip is sometimes AP6212 and sometimes AP6181, according to the 'BPI-M2+ Quick Start' guide you can power the board through USB OTG (not true) and a '3.5mm jack audio' is available (which is also not true) and so on. And they ask you to download OS images from http://www.banan-pi.org (domain does not exist). Any more questions? If you've to rely on their information or support you're already lost since the vendor simply doesn't give a shit about stuff like this.
 
Software provided by the vendor:
 
Since SinoVoip today released an OS image for M2+ -- they call it Raspbian Jessie(debian 8) BPI-M2P (20160408) -- I thought: let's give it a try. Armbian supports this board already but maybe we missed something. OMFG, what a horrible experience! I burned this Raspbian image to a 8GB SD card and booted. Whole boot log as follows:
 
 
 
 
And then I had an installation with zero free space. You can't do anything with it:
Filesystem Size Used Avail Use% Mounted on /dev/root 3.9G 3.7G 0 100% / devtmpfs 373M 0 373M 0% /dev tmpfs 501M 68K 501M 1% /dev/shm tmpfs 501M 6.9M 494M 2% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 501M 0 501M 0% /sys/fs/cgroup /dev/mmcblk0p1 256M 45M 211M 18% /boot tmpfs 101M 4.0K 101M 1% /run/user/1000 /dev/mmcblk1p1 7.2G 145M 6.7G 3% /media/pi/3684f9bd-1ea5-4cd0-a75b-b47af6147d77 tmpfs 101M 0 101M 0% /run/user/0 I quickly used Armbian's tools to resize the partition to the maximum and rebooted just to realise that they really use raspbian.org repositories for this OS image (how moronic is it to use ARMv6 code on a H3 board?!). I tried to get RPi-Monitor installed which didn't work out of the box, wasted almost an hour to fix this stuff and then gave up. Since I simply copied our armbianmonitor tool to the installation I gave up on RPi-Monitor and used armbianmonitor instead to monitor temperatures, CPU clockspeed and so on when running a few benchmarks:
 
The bad news:
 
BPi M2+ is a 99% clone of Orange Pi Plus/PC. Why didn't they do a 100% copy but instead chose to f*ck up the missing one percent? The Orange Pi variants all use a programmable voltage regulator to provide the SoC's VDD_CPUX voltage (lower clockspeeds --> lower voltage --> less heat --> more efficient throttling behaviour if SoC starts to overheat). On BPi M2+ the SoC is always fed with 1.3V which prevents best performance with heavy multithreaded workloads. Be prepared that due to this high voltage even throttling down to half of the maximum clockspeed doesn't help that much:
 

 
This is a not so demanding benchmark running with Armbian settings. Any Orange Pi variant would reduce voltages when reduding clockspeeds which is responsible for less heat emissions and therefore with the very same settings a H3 used on an Orange Pi would still run with 816, 912 or even 960 MHz due to reduced VDD_CPUX voltage where BPi M2+ remains at 648 MHz.
 
SinoVoip not only tried to copy the hardware very closely, they also use loboris' kernel 3.4 sources developed for Orange Pis (Armbian uses a different code base) and they chose to copy the most important mistake Xunlong made so far (the Orange Pi vendor, that developed also the 1st Banana Pi that has been manufactured by SinoVoip from then on).
 
Their throttling settings prefer killing CPU cores instead of throttling if the SoC starts to overheat. This is the main reason why Orange Pi boards get that bad scores on openbenchmarking.org: Since the multithreaded benchmarks increase temperatures that much that CPU cores are killed and never come back.
 
This is exactly what happens with SinoVoip's software settings: I started an usual run of Phoronix Test Suite, the 1st benchmark already killed cpu3, the next one cpu2 and due to their moronic THS settings the maximum clockspeed is 1008 MHz anyway. So a SBC advertised as 'quad core @ 1.2GHz' is already just a 'dual core @ 1.0GHz' when running a few boring benchmarks:
[ 2749.050080] CPU Budget:Try to down cpu 3, cluster0 online 4, limit 3 [ 2749.051406] [hotplug]: cpu(0) try to kill cpu(3) [ 2749.052482] [hotplug]: cpu3 is killed! . [ 4575.080090] CPU Budget:Try to down cpu 2, cluster0 online 3, limit 2 [ 4575.081791] [hotplug]: cpu(0) try to kill cpu(2) [ 4575.081853] [hotplug]: cpu2 is killed! . And benchmark results look as expected: The worst combination is SinoVoip hardware combined with SinoVoip software: http://openbenchmarking.org/result/1604082-GA-1604074GA00
 
We implemented a special corekeeper service especially for M2+ in Armbian two days ago to help recover from killed CPU cores (since we can't prevent this as long as we've to rely on kernel 3.4 and the M2+'s fixed voltage is a real problem). Be prepared that if you run really demanding workloads on the BPi M2+ with their OS images that you end up with a single core board pretty soon.
 
The good news:
 
Since it's 'just another H3 board' trying very hard to be as compatible as possible to the Oranges you benefit automagically from every software effort made by the community. You don't need to use software from SinoVoip, you don't need to rely on their (non existing) support, you simply can use any of the community's stuff. Mainlining efforts are progressing nicely and by simply mixing device tree stuff from Orange Pi Plus and PC I've been able to get the BPi M2+ with working GBit Ethernet and maximum USB throughput running with kernel 4.6.
 
As a reference iozone measurements of a USB connected HDD (UASP capable enclosure which is responsible for better performance with mainline kernel) and the onboard eMMC:
 
'SinoVoip' 3.4.39-lobo kernel:
USB disk: random random KB reclen write rewrite read reread read write 102400 4 6347 8163 8494 8473 506 1603 102400 16 15420 18110 16543 16674 1885 5445 102400 512 23024 33610 32381 32779 23049 23276 102400 1024 17930 30673 23079 24077 23051 24331 102400 16384 22468 35098 34304 34148 34189 35090 eMMC: random random KB reclen write rewrite read reread read write 102400 4 5323 5683 14130 14135 12028 5573 102400 16 17531 18513 34499 34598 31193 17278 102400 512 24868 24626 61687 61697 61581 23991 102400 1024 25134 24949 66979 67180 67140 24553 102400 16384 26165 25950 76265 76649 76701 25931 4.6.0-rc1:
USB disk: random random KB reclen write rewrite read reread read write 102400 4 7760 7917 7845 7868 505 1445 102400 16 17647 20568 20593 20945 1945 4729 102400 512 27334 35579 38033 38553 24980 35320 102400 1024 27419 36866 38764 39026 30661 36766 102400 16384 28267 37358 38540 38558 38988 37542 eMMC: random random KB reclen write rewrite read reread read write 102400 4 5233 5708 14953 14951 12650 5916 102400 16 19776 20609 37958 38023 34206 19403 102400 512 26981 27200 78648 78752 77930 26121 102400 1024 27188 27173 78793 78764 78431 26651 102400 16384 27276 27135 79341 79440 79406 27334 Open questions:
 
The board is designed to be used with an OmniVision OV5460 camera module (Xunlong sells a cheap GalaxyCore gc2035 camera module instead). The very same camera module has already been sold for Banana Pi. And the state of the driver prevented any resolutions above 640x480 (video). So unless someone is able to check the state of the drivers the use of this 'superiour' 5MP module is questionable (at least when you try to run the board with Linux -- Android might be a different story)
 
Conclusion:
 
If the price will be competitive this board is worth a look unlike other SinoVoip boards (M2/M3). It's already fully supported by Armbian so there's no need to use any of the crappy OS images the vendor provides (it's easy to use our Armbian build system to create OS images for non Debian based distros, just read the docs!)

Hi Baos,
 
the mac address is not invalid, but it is marked as a locally administered address. The mac addresses devices usually get from their manufacturer are universally administered addresses. So it seems the SW on your router doesn't like these perfectly valid addresses.
 
I fear Igor doesn't have an Organizationally Unique Identifier (OUI) to create UAA mac addresses , so LAA is the correct way to go.
 
Bye,
wahlm
 

Hi, i discovered and solved incompatible gc2035 driver with some v4l2 applications.
 
I made some modifications to the 3.4.39-02 kernel-lobo:
 
gc2035: of 8fps to ~20fps eand improvements in the matter of light.
The original driver accepts only 800×600, added the following resolutions: 800×600/640×480/320×240
sunxi_wdt: builtin to module (greater flexibility to change the module options) / pr_info some functions, causing flood in kern.log (switched to pr_debug)
CONFIG_CMDLINE=â€earlyprintk=ttyS0,115200 loglevel=5 initcall_debug=0 console=ttyS0,115200 console=tty0 fsck.mode=force fsck.repair=yes init=/init ipv6.disable=1
kernel size: ~59mb
 
For more informations:
http://www.sistemasembarcados.org/2016/04/orange-pi-camera-with-v4l2loopback-vidcopy.html