Search the Community

Showing results for tags 'research'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • First aid
    • Getting started
    • Board doesn't start
  • Bug tracker
    • Allwinner A20
    • Allwinner H2 & H3
    • Allwinner H5 & A64
    • Armada A388, A3700
    • Amlogic S905(x)
    • NXP (Freescale)
    • Rockchip 3288 & 3328
    • Other supported boards
  • Community forums
    • Common issues
    • Peer to peer technical support
    • TV boxes
    • General chit chat
  • Development
    • Allwinner H6
    • Rockchip 3399
    • Development

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 7 results

  1. 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: 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: Orange Pi Lite, RTL8189FTV module, Kernel 3.4.113: 41.5 Mbits/sec and 50 retransmits on average. Full log: ODROID-C2 with TP-Link TL-WN823N dongle, RTL8192CU module, kernel 3.14.79: 77 Mbits/sec and 73 retransmits on average. Full log: 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)
  2. 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.
  3. Clearfog PRO with Linux 4.12.4-mvebu Samsung 840 PRO utilization: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random kB reclen write rewrite read reread read write 102400 4 62501 101691 98761 94430 34522 93050 102400 16 183325 215091 231439 232948 101667 171875 102400 512 301985 307789 341261 344567 328849 309560 102400 1024 294818 309177 345099 347791 339763 309775 102400 16384 271066 344426 384226 388587 387169 346825 2 x Samsung 840 PRO in RAID0, ext4 utilization: random random kB reclen write rewrite read reread read write 102400 4 67614 95508 94561 94984 32561 74157 102400 16 174075 200947 222430 223840 109654 199578 102400 512 307905 294689 317652 308007 307057 268841 102400 1024 307821 317784 327007 330213 322851 317024 102400 16384 286193 383463 394221 398474 397951 374333 Logs: Controller temperature is stable at 64°C, network utilization is also at top speed. Card was donated via Amazan wish list. Thank you! Hummingboard 2 with Linux 3.14.79-cubox (mainline not working out of the box) Not that impressive as Clearfog, but works. random random kB reclen write rewrite read reread read write 102400 4 28502 39271 37895 37983 22325 38821 102400 16 68494 80988 69940 70511 53264 80047 102400 512 116594 118132 93789 94280 92828 118884 102400 1024 138185 140277 122610 123717 120853 139393 102400 16384 183976 183169 151745 153813 151890 179652 Logs: Espressobin 2 x Samsung PRO 840, RAID 0, BTRFS random random kB reclen write rewrite read reread read write 102400 4 21547 20493 37509 37024 21747 17728 102400 16 61955 56230 93068 93795 64349 45724 102400 512 188611 186828 175688 176961 172098 185109 102400 1024 215817 216559 189477 191846 188481 214727 102400 16384 226764 228502 229162 238883 222826 229894 Intel N4200 / Up2board Square 1 x Samsung 840 PRO random random kB reclen write rewrite read reread read write 102400 4 65003 76031 93147 92507 32024 73029 102400 16 146880 175968 187734 224409 106025 163916 102400 512 244782 225736 348401 357949 343145 221037 102400 1024 239203 247778 313476 313372 309170 248540 102400 16384 254396 266530 357708 368483 370731 276458 2 x Samsung 840 PRO in RAID 0 random random kB reclen write rewrite read reread read write 102400 4 61680 70018 67650 66635 18221 67984 102400 16 145869 164784 147884 143877 46355 160169 102400 512 230140 219870 213069 199087 213587 210607 102400 1024 273150 271782 257206 279397 275632 271896 102400 16384 314895 311385 365117 376228 375081 317790 Native onboard SATA 1 x Samsung 840 PRO random random kB reclen write rewrite read reread read write 102400 4 70611 80842 100647 97276 30072 77666 102400 16 194707 208422 239401 224119 102211 218393 102400 512 346735 410867 401536 425167 396013 412711 102400 1024 374032 366490 378981 394321 382352 368195 102400 16384 441298 430380 475063 486540 482151 414518 Reference: A20's native SATA This document is work in progress ...
  4. 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 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 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: 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: 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:
  5. Starting to work on lets call it the "dogafu" experiment (don't give a fuck about recommendations). This would combine my threads about powering & bad SD-Cards. Cause I want do something useful and not just crash armbian on a system, from which I know that it would happen, I decided to do not only stupid tasks on my OPi zero. I could just hammering the SD-Card with a webcam and motion until it crashes and write on this thread 'opi 0 with terrible setup crashes after x days'. But, nobody would read this thread cause it's not interesting for anyone. We know that this would happen and for those users who don't know, there's nothing of interest in this thread. Since thermal throttling on the opi zero seems to be a real issue and there's a lack of information, that the temperature readouts from the SoC are correct, I decided to connect a DS18b20 to the OPi0 and let it measure the temperature of the SoC. Everything was installed on ARMBIAN 5.31 stable Ubuntu 16.04.2 LTS 3.4.113-sun8i. Hooking up the DS18b20: First we edit the configuration file and uncomment the w1 modules with sudo nano /etc/modules-load.d/modules.conf and cause onewire does not work properly @240 MHz we had also to change MIN_SPEED to 480000 with: sudo nano /etc/default/cpufrequtils after a shutdown we can connect the DS18b20 on GPIO10 (Data, physical pin 26), VCC to one of the 3.3V (physical pin 1 or 17) and ground (physical pin 6,9,14,20 or 25) don't forget to have a 4.8kOhm resistor betwenn VCC and Data! If you want to have your data pin not on GPIO10 you have to modify the script.bin with bin2fex /boot/script.bin /tmp/orange.fex followed by nano /tmp/orange.fex and change the GPIO in the [w1_para] section (example for using of GPIO6 for DS18b20): sudo fex2bin /tmp/orange.fex /boot/script.bin and a reboot is needed to activate this settings. Im everything works correctly sudo armbianmonitor -m should show that the cpu frequency would not go below 480MHz (otherwise DS18b20 would not run smoothly). Go to cd /sys/bus/w1/devices/ we can see our sensor with ls. It should start with something like 28-XXXXXXXXXXX. cat 28-0517010cbeff/w1_slave should show our actual temperature. So the actual temperature in my room is 23.562°C (IMO forget about everything behind the °C, proper precise temperature measurement isn't trivial and needs calibration which is not possible without professional equipment). Send data to an other device: Cause this setup with bad powering & a corrupt SD card will brick and I do not want to lose the collected data, I decided to send all the data to a second, proper running, OPi 0 via mqtt. This will be done by some bash scripts and crontab (it would be possible to do this only with crontab, but cause I may use this scripts on other devices for other purposes it's easier to have them isolated). For this, I installed a mqqt client with sudo apt-get install mosquitto-clients. After installation, we test if the client can publish on an other device with: mosquitto_pub -h 192.168.x.xx -t test -m "everything works ;-)" (-h ip oft the mqtt broker, -t topic to publish -m msg.payload). On my second OPi 0 with node-red and mosquitto we should see that the message arrived (installation of node-red and mosquitto). (with #, we subscribe to every topic on the mosquitto broker) Bash script & crontab: IMO the easiest way to send data periodically is to generate a small bash script which includes all the tasks and then setup a crontab to start this bash script. The scritp was saved in /home/opi/scripts/ with nano scriptname the script was generated (It might be possible to do this tasks without a bash script but since I'll reuse parts of it i decided it's the lazy way to do it.): Cause cpu infos are only available as root, crontab must run under root privileges. Add a new crontab with sudo crontab -e (1 for edit with nano). This crontab will start our script every minute: Cause this script runs now with root privileges, this might be a security risk so make sure that no one has access to your OPi! Now it's time to set up everything in node-red to get our results visible. I added dashboard to node-red to have some nice UI templates (usage of node-red & how to set up can easily learned by google . FYI: This is an ongoing project. At the moment, everything runs on a reliable SD-Card and the DS18b20 is not properly mounted on the SoC (waiting for thermal paste). As soon as I have everything setted up, I'll put it on the bad SD-Card with a cheap phone charger to see how stable it runs.
  6. 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 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'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:
  7. First i have to say - if i knew what i am gonna go through, i would never buy this troubled hardware. So don't buy it too. But if you are already strayed like me, i decided to share my modifications, to make this inconsiderate piece of hardware useful. With this mods the device finally work as i need it to and i am fully happy with hardware part. Not so happy with software though, but that's another story. The main reason for me, to buy this router, except pc like capabilities, was SATA+SATA power connector. I used my old router with usb HDD, so it sounded good to have it in box and on native sata interface. Silly me, who would thought this will be the most troubled part. I thoroughly suspected, this sata port is designed for SSD disks and never provided for mechanical HDD-s, as this AXP209 power scheme, simple can't provide needed >2A in some cases (at spin up) current, for disk only, not to mention the board consumption itself. And native sata interface, is not so native, but lets ignore this. So, first thing we have to think about, if we are going to use mechanical HDD with this board, is reliable power source. According to our needs 2A are for spin up and perhaps heavy load of HDD and the board with less peripherals should work at 1A, but 2A is by specifications. So 5V, 4A is the optimal power source we need to be sure we will not have hang outs at power on. 5V, 2A (real) is the minimum, but we have to pray at each power on, HDD to not stuck at spin up, so i wouldn't recommend this. In my case, i add some reserve (you know what those chinese power supplies are) and buy this: Second thing is how to connect this power to the board. It's discussed many times - this micro-usb connector used in Lamobo R1 is not suitable. It can throughput 1.4A by specifications. The board will usually suffer instabilities even with something connected in USB port, not to think about HDD at all. One way is to use battery connector. I was using this method for some time. But there is one major disadvantage. The board will not automatically power on after power loss. We have to push the power button. I had special match stick just for this . Since Lamobo R1 have to be router in major, this is a problem. And here comes the first hardware intervention. We need better power connector added at + and - somewhere on PCB. Near micro-usb is fine, this is my solution (sorry for bad pictures, but will catch the idea): Of course, we have to find place for the connector somewhere on acrylic case. In my case, it's become more messy than i wanted, but is ok. This way board will automatically boot after power loss, so is suitable for router purposes. This combination (proper psu and connector), make the board stable, but not the attached mechanical HDD. No matter what patch is applied like mentioned here, i still have situations when, at power on, board is powering, but attached HDD can't spin up and just ticking. It's often enough not not count on this for long term of work. So other, more drastic solution is needed. Hardware mod number two, is to attach HDD power directly to PSU connector, avoiding AXP209 PMU and attach only sata - data part to board. I modified one of these: On the bottom is my earlier self made sata cables. They worked, but coast me troubles with connectivity on the board part mostly and kernel automatically drop speed to SATA1. So on the above adapter i am using full male part for the board, with power cords cutted off. On the other side, sata - data cable is cutted and resoldered to sata data connector. And power for the HDD is from separate power sata connector wired directly to our new, power connector for the board. This is necessary, because there is not much space left if passive cooling is placed on SoC, as in my case. If someone is creative, or can't solder those tiny wires, can use lower radiator, or no at all. Or simply remove the side lid. In this case, above adapter can be used without much modifications, just cut the power cords on the male side and solder to the power connector. But i decided to make it clean. I didn't make pictures before everything to be assembled, but bellow can be roughly seen, what i am talking about: As it's also seen, HDD have to be placed on the top cover, with at least two holes. This will not prevent power management of HDD in any way. Both hd-idle and hdparm (from what i tested) are able to spin down HDD this way. This is the only permanent for sure, solution i found for HDD powering on this board. Here is the part to mention passive cooling of the board, as it is capable of overheating. Above is seen radiators i placed for SoC and RAM modules. But it's not the most heating part of the board, it is the switch chip - BCP53125. So some lower radiator is good for there. And also some small and lower radiator for PMU, especially if adding of USB peripherals is planned: Mod three. Who own this board, is well known of it's crappy and unuseful wifi module. It's good for client, but not for AP mode, what is needed for actual router. I hardly reach 1Mb/s speed with it for single client and it's drop connection often. I was using external USB wifi module for AP mode. But inspired of this - Hardware Mod BPi-R1, i bought the same Ralink MT5572 module and do the same mod. My advice of removing the old module, is to cut 6 antenna pads with some utility knife and simply move the module up/down until it digress from the rest 7 pads. Then soldering the new module is easy: As for the MT5572 module, it's very good for AP . 2.4Ghz/5Ghz capable, 30dBm output power. Range is more than on my old 24dBm router, no matter the 3 antennas. And we don't even have to talk about bult-in, old RTL8192CU, 20dBm (but this is the least problem of it) module. Some parameters: I am using OpenWrt as OS for now. I just can't find anything so suitable for my needs, especially in firewall part. I have some ideas for "computer" part of the board in the future, but this will be for now, because i am bored and tired of this crappy piece of... nothing out of the box. OpenWrt is stable: Some logs: Don't mention redundant packages i added. With this "huge" sd cards, i am like - "hey, i am not sure what this is, but looks like i can use it someday, let's add it" . It's different when you have to fit it in 4/8Mb flash. Maybe some day i will make minimal image with only important stuff. And finally at work : Last thing i think i have to mention, as it is related to hardware too. There is this post of @tkaiser. It is all true. So if someone want a real router of this board, external USB LAN adapter is needed. I used this one: It's specially chosen for this board because of USB hub and Gigabit LAN. Lamobo R1 have two USB interfaces - normal and OTG. But OTG have bug when acting as OTG and in all images and OS-s i know is disabled. I can enable it only in legacy Linux images and i need USB. That's why i was using this external LAN adapter for WAN interface. Saying "was", because, even if i agree with all in above post, i am one of those who actually think like this - 'hey, the few seconds when the device is booting... who cares that WAN and LAN are bridged?' I actually use pppoe and really don't care if my few devices will bet exposed to my ISP small local network for few seconds. So i am using vlans. And in a matter of fact, i've seen a lot of cheap routers with the same switch with vlans solution, or at least it look like this. So take it as you will, it's good for my needs. But if you want real router functionality with separate interfaces, consider adding some USB LAN like above and do yet another hardware mod of this board. Sorry for the long post. I left this here if it could be useful for someone.