arox

LOL, today I did some testing with NanoPi NEO, kernel 4.7.2 and the new schedutil cpufreq scheduler. I let the following run to check thermal readouts after allowing 1200 MHz max cpufreq:
sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo) To my surprise the result was just 117.5 seconds -- that's 'better' than RPi 3 with same settings and with Orange Pi PC while being clocked higher (1.3 GHz vs. 1.2 GHz) I got the following a few days ago: 'sysbench takes 142 seconds, H3 constantly running at 1296 MHz, SoC temperature reached 74°C but no throttling happening'
 
Wow!!! An increase in performance of ~30 percent just by using a new kernel! With a benchmark that should not be affected by the kernel version at all?! That's magic.
  So I immediately tried out our 3.4.112 Xenial image. Same thermal readouts, same result: 117.5 seconds! What did happen?   I tried out Xenial 16.04 LTS with both 4.7.2 and 3.4.112 kernel. And before I always used Debian Jessie. Ok, downloaded our Jessie image for NanoPi NEO, executed the same sysbench call and got 153.5 seconds (which is the correct value given that no throttling occured, max cpufreq was at 1200 MHz and OPi PC clocked at 1296 MHz finishes in 142 seconds!)   What can we learn from this? Sysbench is used nearly everywhere to 'get an idea about CPU performance' while it is horrible crap to compare different systems! You always have to ensure that you're using the very same sysbench binary. At least it has to be built with the exact same compiler settings and version! We get a whopping 30 percent performance increase just since the Ubuntu folks use other compiler switches/version compared to the Debian folks:   This is 2 times 'sysbench 0.4.12'   Ubuntu Xenial Xerus: root@nanopineo:~# file /usr/bin/sysbench /usr/bin/sysbench: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=2df715a7bcb84cb03205fa3a5bc8474c6be1eac2, stripped root@nanopineo:~# lsb_release -c Codename: xenial root@nanopineo:~# sysbench --version sysbench 0.4.12 Debian Jessie:
root@nanopineo:~# file /usr/bin/sysbench /usr/bin/sysbench: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=664005ab6bf45166f9882338db01b59750af0447, stripped root@nanopineo:~# lsb_release -c Codename: jessie root@nanopineo:~# sysbench --version sysbench 0.4.12 Just the same effect when comparing sysbench numbers on RPi 2 or 3 when running Raspbian or Ubuntu Mate -- see post #12 above (but there the difference is only 15 percent so it seems either the Raspbian people aren't using that conservative compiler switches compared to Jessie or Ubuntu Mate for Raspberries does not optimize that much as our 16.04 packages from Ubuntu repositories)
 
TL;DR: Never trust any sysbench numbers you find on the net if you don't know which compiler settings and version have been used. Sysbench is crap to compare different systems. You can use sysbench's cpu test only for a very limited set of tests: Creating identical CPU utilization situations (to compare throttling settings as I did before in this thread), running tests to estimate multi-threaded results when adding/removing CPU cores or test CPU performance without tampering results by memory bandwidth (sysbench is that primitive that all code runs inside the CPU caches!)
 
Everything else always requires to use the exact same sysbench binary on different systems to be able to compare. So no-cross platform comparisons possible, no comparisons between systems running different OS images, no comparisons between different CPU architectures possible. Using sysbench as a general purpose CPU benchmark is always just fooling yourself!

Memory is mainly used by disk cache and object storage (especially in gui apps) ... and leakage in bad software. You should check if your system needs swap (with swapon -s for example). A database may need much RAM - especially when badly designed because it then needs full table scan. A java/servlet server needs RAM to keep users context. A gui or CAD program may create numerous instance and require much memory. Apart of that, for personal usage, high memory consumption is often due to bad software (with buggy chromium, I fear that you simply cannot get enough memory). A light DB or a lignt web server dont need that much memory - especially for serving static files.
 
So buy as much of RAM that you can, but dont choose the card for the RAM unless you really know you need it : you can also use 2 cheap cards with different hardware instead of an expansive one if you have specific needs.

Hi,
 
Just joined to say thanks to all to those that are involved in the development of Armbian. I recently bought an Orange Pi PC after reading the internet full of people bitching about non-booting devices, HDMI issues, overheating and general crapness.
 
Decided to buy a Orange Pi PC nonetheless, found an old crap micro SD card, burnt Armbian (the internet has made it clear to not bother with the crap on the official Orange Pi website!) onto it and the thing booted without any issues! Typing this message from it as we speak in Iceweasel!
 
The thing only cost me 9 quid, so decided to donate what I would have wasted in cash on a Raspberry Pi 3 (which is anything but the 25 dollar SBC it seems to be advertised) as a donation to Igor and co.
 
I just run the Orange Pi PC out of the plastic static bag it came in LOL!
 
Once again, great work.

Have you read that tutorial ?
 
http://johanbijker.blogspot.fr/2012/07/tp-link-mr3420-serial-connection-with.html
 
It looks like MR3420 use 3.3V and not TTL (5V) logic. You should be able to adapt this to other arm cards but beware that serial ports are ttyAMAx on raspbian and generaly ttySx on other systems.
 
If you need to cross TTL and 3.3V logic, have also a look at level shifters in :
 
http://elinux.org/RPi_GPIO_Interface_Circuits
 
Now be prepared to have occasionally strange effects in some case as it sometimes prevent to do a full hardware reset (that means that if your system crash, you may have to unplug serial connection). You should make some test if you want to use that remotely with an unattended system.

I am afraid (or not anymore) that RPI zero will be obsolete before being really available.

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

tkaiser said : "For RPi Zero exactly zero use cases come to my mind"
 
Well, I have an old Raspi A that serve a dozen of relays, IR transmitter, buzzer, Bluetooth remote, and other goodies. A 80286 would do the job. Idem with an other Pi for a waker (lamp + buzzer + radio), and other for temp sensors ...
 
So my personal use cases are low power, low consumption devices in a BT pan network. Ideally, I should use aduinos and mesh zigbee or z-wave network, but it would cost much more time and money !
 
So I am very interested in nanopi neo as RPI zero is so hard to find. Thanks for your work. Even if you dont have use cases for some cards, other will have the needs that match the specs. (I dont use a computer anymore but a network of arm nodes with specific roles : server, fw, desktop ...)

tkaiser said : " I then replaced the PSU with another one where barrel plug fitted somewhat tighter and subsequent boots were fine. Maybe that's the culprit?"
 
I use to power my RPI threw GPIO. I never tried with BPI. I dont have the schematics for BPI M2+. (On RPI it shunts the fuse). I will try to add a capacitor (the PSUs can have bad noise level) and power threw GPIO. I'll tell you if my BPI survive ...