Search the Community

As already done with other topics this will be the start of a new thread collecting more information over time. Since we had a lot of annoying discussions recently regarding Wi-Fi on Orange Pi Zero and in general I thought let's give it a try a few days ago. I did some preparations in the meantime (monitoring 24/7 Wi-Fi throughput in 2.4 GHz band for example) and then started to test in a not too crowded environment here. As a start some quick Wi-Fi tests with a random 'quality' USB Wi-Fi dongle and 3 different Wi-Fi chipsets that can be found an a few boards Armbian supports: RTL8192CU (used on a lot of cheap USB dongles and even on Lamobo R1) Ampak AP6212 (based on Broadcom's BCM43438 module also used on RPi 3 and Zero W, nearly all Wi-Fi equipped NanoPi and Banana Pi) RealTek RTL8723BS (used on Pine64+ and on CHIP for example) RealTek 8189FTV (used on the more recent Wi-Fi equipped Orange Pi) The usual Wi-Fi performance 'benchmark' results available here and there most of the time ignore a lot of important bits, eg. Environment (Wi-Fi means shared media so in crowded areas with a lot of other Wi-Fis around you fight for free slots on the media, even USB3 peripherals or microwave ovens happily interfere with your Wi-Fi performance) Environment (yeah, again: This time aerial/antenna used, position of antenna in relation to AP, distance, free sight or not, walls/stuff that filter or reflect signals) Settings (Wi-Fi powermanagement enabled or not? Which cpufreq governor used? Performance results can vary based on at which clockspeed CPU cores run) So for the test I chose to let all boards run with performance governor and Wi-Fi powermanagement disabled. All are equipped with the same el cheapo Xunlong aerial (sent with all Orange Pi that are Wi-Fi capable). Position of antenna is always the same, distance from AP (Fritzbox 7390) to board approx 50 cm, AP in cabinet (20mm MDF). Almost same environmental conditions (due to some testing delays I could not guarantee that Wi-Fi channel utilization was always the same but since I let a constant iperf3 monitoring run for the last couple of days I chose time slots where maximum throughput seemed to be possible). Also no Ethernet connected (since it's easy to f*ck up performance tests in this scenario when wired and wireless interfaces of both device and router/AP are somehow all connected since some kernels then send packets over the wrong interface) and Wi-Fi connection established the usual way (nmtui --> 'Activate connection' --> done) with /etc/network/interfaces being empty (to let network-manager control all devices for smooth networking). Now the results: NanoPi Air with el cheapo Xunlong aerial, AP6212 module, Kernel 3.4.113, no BT configured: 39 Mbits/sec and 188 retransmits on average. Full log: http://sprunge.us/aPXb Pine64+ with same el cheapo Xunlong aerial, RTL8723BS module, Kernel 3.10.104, no BT configured: 39 Mbits/sec and 58 retransmits on average. Full log: http://sprunge.us/EffO Orange Pi Lite, RTL8189FTV module, Kernel 3.4.113: 41.5 Mbits/sec and 50 retransmits on average. Full log: http://sprunge.us/dWJV ODROID-C2 with TP-Link TL-WN823N dongle, RTL8192CU module, kernel 3.14.79: 77 Mbits/sec and 73 retransmits on average. Full log: http://sprunge.us/Njhi How to interpret the results? The test setup is stupid for any real world consideration (if distance between device and AP is just 50 cm then use a cable instead! ) But this set of tests was about identifying the maximum you can get under perfect or at least pretty good conditions (no interference, rather good signal/noise ratio and so on) All 3 onboard Wi-Fi chips perform identical. This is due to single antenna 2.4 GHz Wi-Fi: 65Mbps bit rate resulting in ~40 Mbit/sec TCP/IP throughput with ideal/good/identical environmental conditions The only reason the TP-Link Wi-Fi dongle could outperform the onboard Wi-Fi chips is called MIMO. This is available with 802.11n and makes use of more than one antenna (2 in this dongle's case). Now we're talking about 130 Mbps bit rate resulting in almost 80 Mbit/sec TCP/IP throughput Next steps: Let's have a look how worse environmental conditions affect performance. This means increasing distance between AP and device, put a few walls in between, use a more crappy antenna. To save some time I will continue the testing solely with the TP-Link Wi-Fi dongle (connected to the ODROID but here the board doesn't matter at all, it's just about the driver variant/version used) and Orange Pi Lite since this is the cheapest 'general purpose Wi-Fi' enabled board Armbian supports and the same chip is also used on OPi PC Plus and OPi Plus 2E (which are both also priced very competitively for their feature set). But I will add also results from Raspberry Zero W if this board ever arrives (if not I'll take RPi 3 instead, both use same BCM43438 chip that is also contained in Ampak's AP6212 which is the solution present on most Wi-Fi enabled Armbian boards)

Since I've seen some really weird disk/IO benchmarks made on SBCs the last days and both a new SBC and a new SSD arrived in the meantime I thought let's give it a try with a slightly better test setup. I tested with 4 different SoC/SBC: NanoPi M3 with an octa-core S5P6818 Samsung/Nexell SoC, ODROID-C2 featuring a quad-core Amlogic S905, Orange Pi PC with a quad-core Allwinner H3 and an old Banana Pi Pro with a dual-core A20. The device considered the slowest (dual-core A20 with just 960 MHz clockspeed) is the fastest in reality when it's about disk IO. Since most if not all storage 'benchmarks' for SBC moronically focus on sequential transfer speeds only and completely forget that random IO is way more important on any SBC (it's not a digital camera or video recorder!) I tested this also. Since it's also somewhat moronically when you want to test the storage implementation of a computer to choose a disk that is limited the main test device is a brand new Samsung SSD 750 EVO 120GB I tested first on a PC whether the SSD is ok and to get a baseline what to expect. Since NanoPi M3, ODROID-C2 and Orange Pi PC only feature USB 2.0 I tested with 2 different USB enclosures that are known to be USB Attached SCSI (UAS) capable. The nice thing with UAS is that while it's an optional USB feature that came together with USB 3.0 we can use it with more recent sunxi SoCs also when running mainline kernel (A20, H3, A64 -- all only USB 2.0 capable). When clicking on the link you can also see how different USB enclosures (to be more precise: the included USB-to-SATA bridges used) perform. Keep that in mind when you see 'disk performance' numbers somewhere and people write SBC A would be 2MB/s faster than SBC B -- for the variation in numbers not only the SBC might be responsible but this is for sure also influenced by both the disk used and enclosure / USB-SATA bridge inside! The same applies to the kernel the SBC is running. So never trust in any numbers you find on the internet that are the results of tests at different times, with different disks or different enclosures. The numbers presented are just BS. The two enclosures I tested with are equipped with JMicron JMS567 and ASMedia ASM1153. With sunxi SBCs running mainline kernel UAS will be used, with other SoCs/SBC or running legacy kernels it will be USB Mass Storage instead. Banana Pi Pro is an exception since its SoC features true SATA (with limited sequential write speeds) which will outperform every USB implementation. And I also used a rather fast SD card and also a normal HDD with this device connected to USB with a non UASP capable disk enclosure to show how badly this affects the important performance factors (again: random IO!) I used iozone with 3 different runs: 1 MB test size with 1k, 2k and 4k record sizes 100 MB test size with 4k, 16k, 512k, 1024k and 16384k (16 MB) record sizes 4 GB test size with 4k and 1024k record sizes The variation in results is interesting. If 4K results between 1 and 100 MB test size differ you know that your benchmark is not testing disk througput but instead the (pretty small) disk cache. Using 4GB for sequential transfer speeds ensures that the whole amount of data exceeds DRAM size. The results: NanoPi M3 @ 1400 MHz / 3.4.39-s5p6818 / jessie / USB Mass Storage: Sequential transfer speeds with USB: 30MB/s with 1MB record size and just 7.5MB/s at 4K/100MB, lowest random IO numbers of all. All USB ports are behind an USB hub and it's already known that performance on the USB OTG port is higher. Unfortunately my SSD with both enclosures prevented negotiating an USB connection on the OTG port since each time I connected the SSD the following happened: WARN::dwc_otg_hcd_hub_control:2544: Overcurrent change detected ) ODROID-C2 @ 1536 MHz / 3.14.74-odroidc2 / xenial / USB Mass Storage: Sequential transfer speeds with USB: ~39MB/s with 1MB record size and ~10.5MB/s at 4K/100MB. All USB ports are behind an USB hub and the performance numbers look like there's always some buffering involved (not true disk test but kernel's caches involved partially) Orange Pi PC @ 1296 MHz / 4.7.2-sun8i / xenial / UAS: Sequential transfer speeds with USB: ~40MB/s with 1MB record size and ~9MB/s at 4K/100MB, best random IO with very small files. All USB ports are independant (just like on Orange Pi Plus 2E where identical results will be achieved since same SoC and same settings when running Armbian) Banana Pi Pro @ 960 MHz / 4.6.3-sunxi / xenial / SATA-SSD vs. USB-HDD: This test setup is totally different since the SSD will be connected through SATA and I use a normal HDD in an UAS incapable disk enclosure to show how huge the performance differences are. SATA sequential transfer speeds are unbalanced for still unknown reasons: write/read ~40/170MB/s with 1MB record size, 16/44MB/s with 4K/100MB (that's huge compared to all the USB numbers above!). Best random IO numbers (magnitudes faster since no USB-to-SATA bottleneck as with every USB disk is present). The HDD test shows the worst numbers: Just 29MB/s sequential speeds at 1MB record size and only ~5MB/s with 4K/100MB. Also the huge difference between the tests with 1MB vs. 100MB data size with 4K record size shows clearly that with 1MB test size only the HDD's internal DRAM cache has been tested (no disk involved): this was not a disk test but a disk cache test only. Lessons to learn? HDDs are slow. Even that slow that they are the bottleneck and invalidate every performance test when you want to test the performance of the host (the SBC in question) With HDDs data size matters since you get different results depending on whether the benchmark runs inside the HDD's internal caches or not. SSDs behave here differently since they do not contain ultra-slow rotating platters but their different types of internal storage (DRAM cache and flash) do not perform that different When you have both USB and SATA not using the latter is almost all the time simply stupid (even if sequential write performance looks identical. Sequential read speeds are way higher, random IO will always be superiour and this is more important) It always depends on the use case in question. Imagine you want to set up a lightweight web server dealing with static contents on any SBC that features only USB. Most of the accessed files are rather small especially when you configure your web server to deliver all content already pre-compressed. So if you compare random reads with 4k and 16k record size and 100MB data size you'll notice that a good SD card will perform magnitudes faster! For small files (4k) it's ~110 IOPS (447 KB/s) vs. 1950 IOPS (7812 KB/s) so SD card is ~18 times faster, for 16k size it's ~110 IOPS (1716 KB/s) vs. 830 IOPS (13329 KB/s) so SD card is still 7.5 times faster than USB disk. File size has to reach 512K to let USB disk perform as good as the SD card! Please note that I used a Samsung Pro 64GB for this test. The cheaper EVO/EVO+ with 32 and 64GB show identical sequential transfer speeds while being a lot faster when it's about random IO with small files. So you save money and get better performance by choosing the cards that look worse by specs! Record size always matters. Most fs accesses on an SBC are not large data that will be streamed but small chunks of randomly read/written data. Therefore check random IO results with small record sizes since this is important and have a look at the comparison of 1MB vs. 100 MB data size to get the idea when you're only testing your disk's caches and when your disk in reality. If you compare random IO numbers from crap SD cards (Kingston, noname, Verbatim, noname, PNY, noname, Intenso, noname and so on) with the results above then even the slow HDD connected through USB can shine. But better SD cards exist and some pretty fast eMMC implementations on some boards (ODROID-C2 being the best performer here). By comparing with the SSD results you get the idea how to improve performance when your workload depends on that (desktop Linux, web server, database server). Even a simple 'apt-get upgrade' when done after months without upgrades heavily depends on fast random IO (especially writes). So by relying on the usual bullshit benchmarks only showing sequential transfer speeds a HDD (30 MB/s) and a SD card (23 MB/s) seem to perform nearly identical while in reality the way more important random IO performance might differ a lot. And this solely depends on the SD card you bought and not on the SBC you use! For many server use cases when small file accesses happen good SD cards or eMMC will be magnitudes faster than HDDs (again, it's mostly about random IO and not sequential transfer speeds). I personally used/tested SD cards that show only 37 KB/s when running the 16K random write test (some cheap Intenso crap). Compared to the same test when combining A20 with a SATA SSD this is 'just' over 800 times slower (31000 KB/s). Compared to the best performer we currently know (EVO/EVO+ with 32/64GB) this is still 325 times slower (12000 KB/s). And this speed difference (again: random IO) will be responsible for an 'apt-get upgrade' with 200 packages on the Intenso card taking hours while finishing in less than a minute on the SATA disk and in 2 minutes with the good Samsung cards given your Internet connection is fast enough.

The following is the start of a series of tests regarding minimized consumption mode for SBCs. Idea behind is to provide Armbian settings that allow some of the SBC we support to be used as cheap and low-power IoT nodes (or call it 'home automation' or anything else, at least it's about low-power and headless useage) I start with some consumption comparisons with various RPi models below just to get a baseline of numbers and to verify that my consumption monitoring setup is ok. Also you find a lot of numbers on the net that are questionable (measured with inappropriate equipment, comparing OS images with different settings, taking cable resistance not into account, wonky methodology only looking at current and forgetting about voltage fluctuations and so on) so I thought lets take a few RPi lying around and do some own measurement with an absolutely identical setup so the numbers I get can be compared reliably. I used the most recent Raspbian Debian Jessie Lite image currently available (2016-05-27-raspbian-jessie-lite.img) with latest kernel (4.4.13), all upgrades applied, HDMI disabled in /etc/rc.local by '/usr/bin/tvservice -o' and RPi powered through USB port of a Banana Pro (my monitoring PSU -- all values below are 30 min average values). All tests done using the same Raspbian installation on the same SD card. Memory throughput tests done using https://github.com/ssvb/tinymembench CPU 'benchmarks' done using sysbench (that is known to be not able to compare different CPU architectures but since RPi 3 has to run with an ARMv7 kernel and ARMv6 userland it's ok to use it, also it's lightweight enough to not overload my 'monitoring PSU' and throttling could be prevented just by applying a cheap heatsink to the SoC). If we were able to run ARMv8 code on RPI 3's SoC then sysbench would be completely useless since then the test would not take 120 seconds but less than 10 (that's what you get from not using ARMv8 instruction set) I always used 2 sysbench runs, the first with '--cpu-max-prime=20000' to get some numbers to compare, the second running for at least an hour with '--cpu-max-prime=2000000' to get reliable consumption reporting. With the RPi 3 applying a cheap heatsink was necessary to prevent throttling (cpufreq remained at 1200 MHz and SoC temperature at 80°C). Tests used all available CPU cores so the results only apply to multi-threaded workloads (keep that in mind, your 'real world' application requirements normally look different!): sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo) A few words regarding the RPi platform: All RPi use basically the same SoC. It's a BroadCom VideoCore IV SoC that boots a proprietary OS combined with 1 to 4 ARM cores that are brought up later. RPi Zero/A/A+/B/B+ use the BCM2835 SoC which adds 1 ARMv6 core to the VideoCore VPU/GPU, BCM2836 replaced this with a quad-core ARMv7 cluster and on the latest BCM2837 design they replaced the Cortex-A7 cores with Cortex-A53 that currently have to run in 32-bit mode only. The other limitations this platform suffers from are also due to this design (VideoCore VPU/GPU being the main part of the SoC and no further SoC development done except exchanging ARM cores and minor memory interface improvements): only one single USB 2.0 OTG port available between SoC and the outside only DDR2 DRAM possible and the maximum is 1GB (all RPi use LPDDR2 at 1.2V) FAT partition needed where the proprietary VideoCore bootloader BLOBs are located So how do some RPi provide Ethernet and 2 or 4 USB ports? They use an onboard component called LAN9512 (Fast Ethernet + 2 USB ports on RPi B(not B+!) or LAN9514 providing Fast Ethernet + 4 USB ports on RPi B+, 2 and 3. The RPi models that save this component (RPi A+ and Zero) show not so surprisingly the lowest consumption numbers. Same could've been true for RPi A but unfortunately RPi foundation chose inefficient LDO (low dropout) regulators to generate 3.3V and 1.8V needed by various ICs on the boards which transform power into heat on the two first models (so no numbers for RPi A and B here since they're not suitable for low-power operation due to this design flaw) We can see below that disabling the LAN9514 hub/Ethernet combo makes a huge difference regarding consumption which we should take into account if we start to compare with boards supported by Armbian (eg. H3 boards that feature real Ethernet and 4 real USB ports). Same applies to RPi A+ or Zero when an USB-to-Ethernet dongle is connected but here it heavily depends on the dongle in question. When using one of my Gbit-Ethernet dongles (Realtek RTL8153 based) consumption increases by +1100mW regardless whether buspower is 0 or 1, with a random Fast Ethernet adapter it makes a difference -- see below. RPi Zero with nothing connected, doing nothing, just power led: echo 0 >/sys/devices/platform/soc/20980000.usb/buspower --> 365 mW With a connected Apple USB-Fast-Ethernet dongle consumption is like this: echo 0 >/sys/devices/platform/soc/20980000.usb/buspower --> 410 mW (no network) echo 1 >/sys/devices/platform/soc/20980000.usb/buspower --> 1420 (network active, cable inserted but idling) That means this USB-Ethernet dongle consumes 45mW when just connected (regardless whether the RPi is completely powered off or buspower = 0) and as soon as an USB connection between dongle and RPi is negotiated and an Ethernet connection on the other side another whopping 1010 mW adds to overall consumption. Therefore choose your Ethernet dongle wisely when you deal with devices that lack native Ethernet capabilities Fortunately the RPi Zero exposes the SoC's one single OTG port as Micro USB with ID pin so the Zero unlike all other RPi models can switch to an USB gadget role so we can use the USB OTG connection as network connection using the g_ether module (quite simple in the meantime with most recent Raspbian images, just have a look at https://gist.github.com/gbaman/975e2db164b3ca2b51ae11e45e8fd40a).I'll cover performance and consumption numbers in this mode in a later post (covering idle and full load and also some camera scenarios since this is my only use case for any RPi: HW accelerated video encoding). Performance numbers: sysbench takes 915 seconds on the single core @ 1000 MHz, 800 mW reported (+435 mW compared to 'baseline'). And tinymembench looks like this: RPi B+: Nothing connected, doing nothing, just power led: echo 0 >/sys/devices/platform/soc/20980000.usb/buspower --> 600 mW echo 1 >/sys/devices/platform/soc/20980000.usb/buspower --> 985 mW buspower = 1 and Ethernet cable connected --> 1200 mW Performance: sysbench took 1311 seconds @ 700 MHz while 1160 mW consumption has been reported (+175 mW compared to 'baseline') This is tinymembench: RPi 2: Nothing connected, doing nothing, just power led: echo 0 >/sys/devices/platform/soc/3f980000.usb/buspower --> 645 mW echo 1 >/sys/devices/platform/soc/3f980000.usb/buspower --> 1005 mW Performance: sysbench takes 192 seconds @ 900 MHz, 2140 mW reported (+1135 mW compared to 'baseline'). And tinymembench looks like: Raspberry Pi 3: nothing connected, doing nothing, just power led: echo 0 >/sys/devices/platform/soc/3f980000.usb/buspower --> 770 mW echo 1 >/sys/devices/platform/soc/3f980000.usb/buspower --> 1165 mW buspower = 1 and Ethernet cable connected --> 1360 mW Important: RPi 3 idles at just ~130mW above RPi 2 level. Whether further savings are possible by disabling WiFi/BT is something that would need further investigations. Performance: sysbench takes 120 seconds (constantly at 1200 MHz, 80°C), consumption reported is 3550 mW (+2385 mW compared to 'baseline') and tinymembench looks like: To sum it up: There's not much magic involved regarding consumption of the various RPi models: When it's about the 'do really nothing' use case then RPi A+ most probably wins due to half the amount of LPDDR2 DRAM compared to RPi Zero who is next. Both SBC are dimensioned for light loads (only one USB port available that has to provide max 500mA by specs) and save the LAN9514 IC (combined internal USB hub and Fast Ethernet adapter) The two first models RPi A and B are not worth a look when it's about low consumption since they use inefficient LDO regulators to provide different voltages that waste a lot energy. Newer RPi models rely on better circuitry. By accessing /sys/devices/platform/soc/*.usb/buspower consumption can be influenced on all models but it depends on what's connected to the USB port (see the USB-Ethernet adapter example on RPi Zero above) On RPi B+, 2 and 3 cutting power to LAN9514 saves ~400mW. When LAN9514 negotiates an Ethernet connection then consumption increases by ~200mW (which is just 600mW more and really not that bad!) The energy savings of disabled HDMI and especially onboard leds are not that great but you can control behaviour from userspace and get these savings 'for free' so why not disabling stuff you don't need? Consumption numbers for the 'everything disabled and doing nothing' (power cut to LAN9514!) use case do not differ that much. RPi Zero: 365 mW, RPi B+: 600 mW, RPi 2: 645 mW, RPi 3: 770 mW (still no idea whether disabling WiFi/BT on RPi 3 brings consumption down to B+/2 level) When exactly no network connectivity is needed or only from time to time (eg. every hour for a minute or something like this) RPi Zero and A+ can shine. If you need LAN or WiFi permanently you should keep in mind that this adds approx. +1000mW to your consumption and then all LAN9514 equipped 'larger' RPi models might be more energy efficient (!). Even if RPi 3 is not able to perform optimal (ARMv8 cores running an ARMv7 kernel and an ARMv6 userland) it might be an intersting replacement for a RPi B+ if you need the USB ports and Ethernet. You could limit maximum consumption by disabling CPU cores 2-4 and could still get less overall consumption when running light workloads since even with 1 CPU core active RPi 3 is almost twice as fast as the single core RPis (compare with the 'race to idle' concept, the faster work can be done the earlier CPU cores can enter low-power states). EDIT: Disabling CPU cores on RPi 3 does not help with consumption -- see post #5 below. And now to answer the question many might ask since I was talking all the time about various RPi models: Q: Do you now port Armbian to Raspberry Pi?! A: Nope To be honest, there's no need for that. Raspbian when running on Raspberries is really great (unlike the various crappy Raspbian images made eg. for Banana Pis), RPi users are familiar with it, tens of thousands tutorials are available and so on. For me personally it was just important to verify some consumption numbers available on the net, to verify whether my readouts using the PMIC of an Allwinner SBC are correct (seems so) and to get the idea which energy savings level we should target with our new Armbian settings. Based on some experiments done with an Orange Pi Lite I'm pretty confident that we will soon have a couple of ultra cheap H3 boards (that are available unlike RPi Zero which costs way more due to added shipping costs and the inability to order more than one at a time!) that outperform RPis when it's about consumption. At least when we're talking about networked setups and not only the 'does really nothing at all' use case Remaining questions: Why do they allow RPi Zero to clock with up to 1 GHz by default when they limit B+ to 700 MHz (compare performance and consumption numbers of both tinymembench and sysbench above)? How does RPi 3 behaves consumption-wise when WiFi/BT are turned off? How does consumption looks like on the various RPi when average load is not close to 0 but some stuff has to be done (I came accross a lot of really broken python or whatever scripts that try to readout sensors and increase load and consumption a lot). This is an area where RPi 3 (and maybe 2 also) might shine since their SoCs consume only slightly more than the horribly outdated single-core BCM2835 and are able to finish stuff a lot faster (again: 'race to idle' concept: Entering low-power CPU states earlier helps with minimizing consumption if there is some constant load) Further readings: https://www.raspberrypi.org/documentation/configuration/config-txt.md http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-zero-conserve-energy http://raspberrypi.stackexchange.com/questions/8498/disable-lan9512 http://raspberrypi.stackexchange.com/questions/43285/raspberry-pi-3-vs-pi-2-power-consumption-and-heat-dissipation http://raspberrypi.stackexchange.com/questions/5033/how-much-energy-does-the-raspberry-pi-consume-in-a-day https://learn.adafruit.com/introducing-the-raspberry-pi-model-b-plus-plus-differences-vs-model-b/power-supply

TL;DR: All available H3 boards do not differ that much. But the few differences sometimes really matter! The following is an attempt to compare the different available H3 SBC that are supported by Armbian. The majority of boards is made by Xunlong but in the meantime two more vendors started cloning the Xunlong boards (and also Olimex is preparing H3 boards as OSHW). Both Foxconn/SinoVoip with their Banana Pi M2+ and FriendlyARM with their NanoPi M1 tried really hard to copy everything as exact as possible (the so called pin mappings -- how the many contacts the used H3 SoC is providing are routed to the outside). All the boards share the same 40 pin GPIO header (trying to be compatible to the newer RPi boards) and since all the other pin mappings are also 99 percent identical you can for example boot a NanoPi M1 with an Armbian image for Orange Pi PC without loosing any functionality (except of camera module) and the same applies to BPi M2+ that will boot happily an Armbian image for Orange Pi Plus 2E (except of camera module and WiFi/BT) In fact all the various H3 boards just differ in a few details: Amount of DRAM No, Fast or GBit Ethernet Voltage regulator and 'thermal design' (responsible for performance in full load situations) Storage capabilities (pseudo SATA and eMMC or not) Count of available USB ports (with or w/o internal USB hub) Some additional features like camera modules, WiFi/BT and additional/optional connectors (here it's important to check for driver functionality/availability. If there's no driver providing the necessary functionality then these 'additional features' are pretty much useless -- camera connector for example) Why focussing on the H3 SoC for this comparison? Since some of these boards are priced pretty competitive Mainlining support for H3 SoC and these boards is progressing really nicely so we'll be able to run these boards with mainline kernel pretty soon (thanks to the great linux-sunxi community) 2D/3D/video HW acceleration is available with legacy kernels (again thanks to the great linux-sunxi community) The feature set is nice for many use cases (quad core SoC, GBit Ethernet and 4 useable USB ports on some boards make a really nice low cost/power server) It got somewhat confusing regarding the many available Oranges and now also the cloned Banana and NanoPi This is also in preparation of a broader overview of the capabilities of all the boards Armbian currently supports now focussing on the H3 family. So let's get into details: Amount of DRAM That's an easy one. The H3 SoC supports up to 2 GB DRAM. The available and announced boards use either 512MB, 1 GB or 2 GB DRAM (low-power DDR3L on the bigger Oranges and DDR3 on OPi One/Lite, BPi M2+ and NanoPi M1). In case you're using Armbian it simply depends on the use case. And also it's necessary to understand that Linux tries to use all your RAM for a reason: Since unused RAM is bad RAM. So don't be surprised that Armbian will eat up all your RAM to cache stuff which improves performance of some tasks but the kernel will immediately release it when other tasks have a demand for it. If still in doubt please enjoy http://www.linuxatemyram.com. If you want to use your boards with the unofficial H3 OpenELEC fork too please be aware that OpenELEC benefits from at least 1 GB RAM since then the whole filesystem remains in memory and no accesses to a probably slow SD card happen. Prior to jernej/OpenELEC and Armbian resolving the kswapd bug a few weeks ago the 512 MB equipped boards performed rather poor. But now it seems that the unofficial OpenELEC fork runs pretty well also on the boards with less available RAM. Whether 1 vs. 2 GB RAM make a difference absolutely depends on the use case and no general recommendations can be made. Since OpenELEC has been mentioned it should be noted that the current implementation of the unofficial OpenELEC port for H3 boards makes use of the cedarx-license-issues-library (no clear license preventing the use if you care about legal issues -- please have a look at http://linux-sunxi.org/Kodi for further details) Networking: The H3 SoC contains an Ethernet implementation that is capable of 10/100 MBits/sec Ethernet and also GBit Ethernet. A PHY (that handles the physical interconnection stuff) for Fast Ethernet is already integrated into the H3 SoC but to be able to use GBit Ethernet an external GbE capable PHY is needed (the RTL8211E used on all boards adds approx 1.2$ to the costs of the board in question). Most H3 boards use the internal Fast Ethernet PHY so wired networking maxes out at ~95 Mbits/sec. Orange Pi Plus, Plus 2, Plus 2E and BPi M2+ provide GBit Ethernet (+600 Mbits/sec with legacy and exactly 462 Mbits/sec with mainline kernel) while Orange Pi Lite saves an Ethernet jack at all. The good news: Even with the Lite you can use wired network adding a cheap RealTek USB3-Ethernet dongle like this which is confirmed to exceed 300 Mbits/sec in a single direction. The currently available boards have either no WiFi (NanoPi M1, OPi 2 Mini, One and PC), rely on RealTek 8189ETV (OPi 2, Plus, Plus 2), the newer RealTek 8189FTV (OPi Plus 2E, Lite, PC Plus) or a WiFi/BT combination: AP6181 is used on the BPi M2+ but the vendor didn't manage to get BT working at the time of this writing. Currently only jernej's OpenELEC fork and Armbian have a working driver included for the new 8189FTV chip on the fresh Orange boards that seems to perform quite ok and provides client/AP/monitor mode. Can't say that much about that since in my very personal opinion all these 2.4GHz onboard WiFi solutions are simply crap Voltage regulator and 'thermal design': This is a very important differentation: All Orange Pi boards use a programmable voltage regulator to adjust the voltage the SoC is fed with. The SY8106A used on every Orange except of One and Lite can be controlled though I2C and adjusts the so called VDD_CPUX voltage in 20mV steps. This is important since 'dynamic voltage frequency scaling' relies on the principle of providing less voltage to the SoC/CPU when it clocks lower. So when the board is idle also the supplied voltage will be reduced resulting in less consumption and also less temperature. Since H3 is somewhat prone to overheating being able to adjust VDD_CPUX is also important when we're talking about the opposite of being idle. The SY8106A equipped Oranges reduce very fine grained the core voltage when they start to throttle down in case overheating occurs under constant heavy load. As a direct result they will automagically perform better since reducing VDD_CPUX voltage also reduces temperature/consumption so both CPU and GPU cores in H3 due not have to throttle down that much. Quite the opposite with BPi M2+. For whatever reasons SinoVoip saved put a the same programmable voltage regulator on their board as OPi One, Lite and NanoPi have but does not implement voltage switching so H3 there will always be fed with 1.3V. In addition it seems 'Team BPi' didn't take care of heat dissipation through PCB design (it seems Xunlong added a copper layer to the PCB that helps dramatically spreading the SoC's heat) and so with BPi M2+ (and NanoPi M1 too) you have to be prepared that you need both a heatsink and a fan to let this board perform under full load since otherwise heavy throttling occurs or when you use a kernel that does not implement throttling (4.6/4.7 right now for example) be prepared that H3 gets either destroyed or will crash through overheating if you run something heavy on BPi M2+ or NanoPi M1. We're still investigating whether this crappy thermal behaviour might be related to DRAM also (DDR3 vs. low power DDR3L on the Oranges) It seems this thermal behaviour is not that much related to the DRAM type used but more to PCB design (maybe using large internal ground/vcc planes optimizing heat dissipation on Oranges. NanoPi M1 and Orange Pi One/Lite use a rather primitive GPIO driven voltage regulator that is able to just switch between 1.1V and 1.3V VDD_CPUX which already helps somewhat with throttling. A rather demanding benchmark using cpuminer (a bitcoin miner making heavy use of NEON optimizations and assembler instructions) that knows a benchmark mode where it outputs the khash/s rate. On the left OPI+ 2E with the superiour SY8106A voltage regulator switching CPU frequency between 1200 and 1296 MHz. On the right little OPi Lite with the SY8113B voltage generator able to switch between 1.1V and 1.3V and with slightly lower performance since throttling prevents clocking that high. And in the middle as only board with applied heatsink on H3 poor Banana Pi M2+ using the same SY8113B voltage regulator but always feeding the H3 SoC with 1.3V (for whatever reasons!). Storage capabilities: The H3 SoC doesn't feature native SATA capabilities so the 2 boards that have a SATA connector (Orange Pi Plus and Plus 2) implement that using an onboard USB-to-SATA bridge. Unfortunately the chip used there -- a Genesys Logic GL830 -- is horribly slow limiting sequential transfer speeds to 15 MB/s write and 30 MB/s read. It also does not support the USB Attached SCSI Protocol (UASP) so when using mainline kernel attached disks an especially SSDs couldn't show their full random I/O performance. Given that common USB-to-SATA bridges used in external USB enclosures show way better sequential performance (35 MB/s in both directions and close to 40 MB/s when using an UASP capable bridge together with mainline kernel) the SATA port on these 2 SBC can not be considered a feature worth a buy. Every H3 board has a TF card slot (Micro SD card) and some of the boards feature onboard eMMC storage. The H3 can cope with TF cards that are compliant to the SD, SDHC and SDXC standards so rather large cards with more than 64 GB capacity can also be used (be aware that there do not exist that much cards with a capacity larger than 128 GB. Chances are pretty high to get a counterfeit card especially when the price looks too good to be true ). You should also be aware that all H3 boards show the same sequential speed limitations (maxing out at ~23 MB/s) so choosing cards that are rated way faster aren't worth a buy. Better have a look at random I/O performance that is more important in most use cases. The eMMC used on various boards is pretty fast (sequential speeds maxing out at ~75 MB/s and especially random IO way faster than the fastest tested SD cards which is important for desktop useage and databases for example) so you don't make a mistake choosing any of the eMMC equipped H3 boards (BPi M2+, Orange Pi Plus, Plus 2, Plus 2E or PC Plus). You find detailed test results of current SD/TF cards as well as all the eMMC variants used in these two threads: http://forum.armbian.com/index.php/topic/954-sd-card-performance/ http://forum.armbian.com/index.php/topic/990-testers-wanted-sd-card-performance/ Count of available USB ports: The H3 SoC features 3 USB2.0 host ports and one USB OTG port. With Armbian we configure the OTG port as a host port that shows pretty similar performance so on some H3 boards (Orange Pi PC, PC Plus and Plus 2E) you can benefit from 4 USB2 ports that do not have to share bandwidth. Some other boards use an internal USB hub (Orange Pi 2, Plus, Plus 2) so the available USB ports have to share bandwidth in reality. Please keep that in mind when you compare the 4 USB Type A jacks OPi 2, Plus or Plus 2 feature (all being connected to a USB hub so having to share the bandwidth of a single USB 2.0 host port) with the 3 you can count on OPi PC, Plus 2E or NanoPi M1. On the latter boards you get full USB 2.0 bandwidth on each USB receptacle without the need to share bandwidth. BPi M2+ does also not use an internal USB hub but only exposes 2 USB host ports on type A receptacles and the 3rd host port only without ESC protection via soldering (but since this board shows such a terrible thermal design and is relatively overpriced compared to other H3 boards that doesn't matter that much) Additional features: The only board featuring a Bluetooth capable chip from BroadCom is the BPi M2+. Currently the vendor admits that BT is not working so better don't count on this feature to be ever available. Update: Jernej got BT already working in his OpenELEC fork so it's just a matter of time until it works with Armbian too. The H3 SoC is able to output/intercept additional signals, eg. analog audio, Composite video (TV out), IrDA that are present on most of the boards. On the Orange Pi One many of those interfaces are only present as solder points (a bit too tiny to be used by the average maker) and on some other boards they are not present at all (BPi M2+ for example has neither composite video nor analog audio) so always check first what you need or want to use. We have a nice sortable table in linux-sunxi wiki showing most of the important details: http://linux-sunxi.org/Table_of_Allwinner_based_boards Camera modules: Xunlong provides a pretty cheap 2MP camera module that should work with every H3 Orange Pi out there (they all have the necessary connector but for OPi One, Lite, PC and PC Plus you have to tell Xunlong that you also need a so called 'expansion board' that they ship free of charge if you add to your order that you need it. Starting with Armbian release 5.15 we also include an improved driver for this camera. Regarding current state of available camera modules for Oranges, BPi M2+ and NanoPi M1 please look through this thread: http://forum.armbian.com/index.php/topic/1213-ov5640-camera-with-orange-pi/?view=getlastpost

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