wildcat_paris

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

@KodiakFi
"Please be patient and press Enter"

Just posting back in this thread that hitting 'enter' once did the trick, it's a full-fledged OS now.  I've temporarily commented out the Armbian deb repo until I see the all-clear on here that updating won't softbrick my C2.

@KodiakFi
 
it would help if you mention which revision of Armbian you have burnt, please.

@KodiakFi
 
Just in case you have the special USB/UART plug for Odroid, you could try to log in with serial console OR if you can find the IP of the ethernet card (using nmap) you could try ssh login

The board did not boot after compiling uboot either from Igor source and phelum source. I solved it by downgrading uboot to version 5.00 in synaptic package manager.
 
 
Edit: Nope. Problem still here even with 5.0. Almost giving up 

Today me and tricolery solved the problem together. (We live near each other and we also bought the cubieboard2 together).
 
We followed the steps described here: https://linux-sunxi.org/U-Bootand managed to solve our problem. We did not change anything, we just downloaded and compiled using the cubieboard2.
 
If anyone here still have this problem and tried everything described here on this topic try these steps: 
 
git clone -b sunxi https://github.com/linux-sunxi/u-boot-sunxi.git
cd u-boot-sunxi
make cubieboard2_config
make 
dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=1024 seek=8
reboot
 
Dont know if this u-boot-sunxi-with-spl.bin is the newest, but it is working now.
 
(I attached the u-boot here if anyone is interested)
u-boot-sunxi-with-spl.zip

No problem, I happily volunteered, and Armbian saved me a ***lot*** if time while setting-up my nanopi-m1.
I had read about those power supply issues on the forum, but thought I would be fine with a 2A micro-USB power supply - it seems I was wrong: my cable is not short, and I am not sure about its gauge.
 
I powered the board with a MB102 breadboard power supply rated for 5V/1.2A directly on the 4 pins header using Dupond cables as suggested, and cpuburn-a7 hanged the board again. Looking now for a 5V switching power supply: I am not sure the breadboard power supply is doing the job. Thanks for the help.

FYI: https://github.com/friendlyarm/h3_lichee/issues/4
 
According to https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=127210 being able to let the NanoPi NEO idle at ~100mA (while being comparable to RPi Zero from a performance point of view) isn't that bad. But we can provide an OS image that allows performance to exceed RPi 2 level easily. Simply by adjusting settings correctly. A NanoPi NEO can idle like an RPi Zero and instantly transform into an RPi 2 when performance is needed (or anything in between, if the user prefers minimal consumption over highest performance, configuring this is also possible)
 
In case FriendlyARM ships developer samples we might add this to Armbian (including a configuration tool where you can configure performance vs. consumption)

Consumption and improved heat dissipation aren't directly related. Only if you're interested in constant full CPU load you have to take care of heat dissipation (huge heatsink or even combined with a fan) but regarding consumption it's all about configuration and reliability testing (you don't need to do yourself if you choose Armbian since we wasted a few days already digging deep into this stuff).
 
BTW: I think I found why FriendlyARM chose just 432 MHz DRAM clockspeed on Nano Pi NEO: It helps with both consumption and temperatures. See results here: http://forum.armbian.com/index.php/topic/1614-running-h3-boards-with-minimal-consumption/
 
NanoPI NEO should be able to run with just 160mA idle consumption while still being able to increase performance by factor 5 when needed (everything adjustable from user space so no reboot needed, the H3 device can operate in low consumption mode and dynamically switch to power mode when needed)

tobetter created a image based on 4.6.3. His Image will become auto upgradable since he created a odroidxu4 ppa repository. You can "watch" him on GitHub to get last comments, pull requests, etc.
I installed it yesterday (only the kernel, not image) and made some iozone tests (based on tkaiser uas wiki) to check performance. Not so good like 4.7-rc4, but not interesting to be published since I have old SATA II Hardware. I bought a Samsung EVO 850 500GB and will check again the tests. This time we could consider the results based on top components.

Hi,
 
Thanks for your answer and your work on openelec which allows my orangepi to be useful.
In fact my primary objective was to have armbian installed, and kodi installed on it, as well as other tools (hfsprogs for the NAS, etc...), like a "bleeding edge" install.
With Openelec I must swap my sd cards because there is just kodi on that OS. That is why I asked if there were "unbroken ISOS", ie functionnal kodi/hfs/ethernet in my case, but it is not about openelec image but linux distros available for the pi.
But for the moment I have Openelec and I am very happy with it, but I would have liked to benefit from the fast gigabyte 10/100 to make a NAS.
 
By the way Iam looking forward booting openelec from the MMC, is there a simple way to copy the content of the SD card to boot from the MMC ?

Ok, so i have to reformat my hard drive. Which filesystem do you advise : ext4 ?
And then I Can(t make a NAS with the orangepi + kodi player in bleeding edge ? I must have a sd card with openelec ?
But on my Raspberry pi : NAS with hfs+ works like a charm (but quite slow due to the USB shared bandwidth), and netatalk works great too (like a TimeCapsule).
I won't be able to have these features on the orangepi ?
 
Thanks

Thanks for your answer. I come from a Raspberry pi, with debian and all linux toys on it (including Kodi), I thought it was the same but I seem to be naive.

I just want to post a thank you to the developers and contributors who have built one NICE distribution. Over a year ago I bought a few OPi PC as a possible replacement for Raspberry Pi based HAM radio projects I support. To say I was disappointed in the distribution from the manufacturer is a understatement. Without Loboris stepping up and getting something usable I would have tossed them in the trash and moved on. Last night I downloaded and installed Jessie server from Armbian. What a pleasure. Small, clean and a giant plus for me, HEADERS!!!!. I am so tired of having to build the headers for a kernel so I can compile the out of tree modules I need.  I just ordered a few NanoPi NEO and I look forward to being able to run Armbian. Thank you VERY much! My next stop is the donate button.

Steve

@borsti67
 
 
I haven't thought of this point but it is interesting.
 
I had in mind the
"./compile.sh" using default user_compile.config
"./compile.sh  xu4" using user_compile_xu4.config
 
Zador.blood.stain prefers
# compile.sh KERNEL_ONLY="yes" DEST_LANG="ru_RU.UTF-8" BOARD="OPi+2E" SYSTEM="jessie"
or maybe the opposite
# KERNEL_ONLY="yes" DEST_LANG="ru_RU.UTF-8" BOARD="OPi+2E" SYSTEM="jessie" compile.sh
 
I don't like because I have no memory in my goldfish brain nor time to type or copy/paste
(and Zador.blood.stain is clearly 10x more skilled than me in bash and many other areas)
 
@All
the idea IS not to replace the existing framework to build all the boards (which is great)
BUT it is a counterpart of the "userpatches" concept where you can set-up files/patch/config for Lamobo-R1/XU4/OPi+2E
example:
- I need to build kernel only for Lamobo-R1 (I have custom patches&config for the kernel)
- I need to build full image for OPi2+2E with all standard settings
- I need to build full image for XU4 but I need to set specific details (boot partition size, use newer settings like UUID etc. )
 
And last but not least:
- limit the use of root user (and then use RSA key for forked version of "lib" in github)
- CTRL-C to stop cleanly compile.sh (trap CTRL-C and launch clean-up before ending the script)
- clean the environment (chown all the related files of "lib" including $HOME/.ccache because sudo inside compile.sh makes all .ccache files "root" then ccache can get broken for other uses, so I don't want this $HOME/.ccache mess ever ever again)

Hello,
 
I understand plainly zador.blood.stain for keeping the one-liner version of compile.sh
 
I am dumb guy with low memory in brain and I prefer a config file per board (I am using one file for XU4, one for OPi+2E, one for Lamobo-R1, one generic file for playing) instead of a file with plenty of one liners for compile.sh
 
But I have *just* used the plain original (updated) version of Armbian lib and I felt coming back to the Age of ICE (everything is root and sudo, no possible proper CTRL-C of compile.sh to restore all files with user id&group $HOME/.ccache is root, impossible to use RSA keys for forked version of lib (to push/pull) -- unless using the RSA key with root user... etc.)
 
for the backlog of my "failed" pull requests
https://github.com/igorpecovnik/lib/pull/387
 
I would propose to add a script in /scripts/patchToUseConfigFiles/ (I will find a better directory name or any directory in mind)
which would:
- patch the user's local compile.sh (I will maintain the patch for compile.sh)
- install one config file for general use and one example for a specific board (to use ./compile.sh or ./compile xu4 or any board you have in mind)
- create and maintain the appropriate documentation how to use the patched compile.sh
 
so well it will take a directory in "lib" + 4 files (+a file in lib.docs)
 
is it something possible? The Age of ICE is very cold, even if I am fan of Vlad, Trump & Angela. Democracy is overrated and a pure theoretical concept.
(for fans of the new UK PM, read this or this because out of EU, UK people won't even get the very limited social boundaries from the EU regulations from international agreements. EU is dangerous but getting out of EU is even more scary)

solved?

After reboot and start the hotspot using create_ap the wlan0 start works using traffic control.
 
root@orangepipc:~# sudo tc qdisc add dev wlan0 root handle 1: cbq avpkt 1000 bandwidth 100mbit
root@orangepipc:~# sudo tc class add dev wlan0 parent 1: classid 1:1 cbq rate 500kbit allot 1500 prio 5 bounded isolated
root@orangepipc:~# sudo tc class add dev wlan0 parent 1: classid 1:2 cbq rate 500kbit allot 1500 prio 5 bounded isolated
root@orangepipc:~# sudo tc filter add dev wlan0 parent 1: protocol ip prio 16 u32 match ip dst 192.168.12.7/32 flowid 1:1
 
Thanks again for yours help @wildcat_paris and @zador.blood.stained
 
create_ap -> https://github.com/oblique/create_ap

@Lucas
 
I have blindly tried
[gr@bpi:~] 2 $ sudo tc qdisc add dev br0:0 root handle 1: cbq avpkt 1000 bandwidth 100mbit [sudo] password for gr: so no error message
 
just another blind guess (it is a lamobo-R1)
 
 
what do you have in /lib/modules/ please?
 
maybe the output of ifconfig and iwconfig as well
 
I wasn't using ifb module but I have read this
https://wiki.archlinux.org/index.php/Advanced_traffic_control
https://github.com/raspberrypi/linux/issues/453
 
but the module loads

@zador.blood.stain
 
yes, legacy kernel you cannot load ifb & tc doesn't work
 
 
 
your changes are on igor/lib/master? so I can build a kernel to test? on both OPi2E and NanoPi M1
on your fork?

the kernel is booting on M1... module ifb loads, tc doesn't return any error
 
zip includes files... probably only sun8i files are needed
 
http://guillaume.romagny.free.fr/armbian/sun8i_mik20160724.zip
gr@nanopim1:/proc$ sudo tc qdisc add dev eth0 root handle 1: cbq avpkt 1000 bandwidth 50mbit gr@nanopim1:/proc$ sudo tc qdisc show qdisc cbq 1: dev eth0 root refcnt 2 rate 50Mbit (bounded,isolated) prio no-transmit compiling the set of debs for Opi PC, just in case.

@Lucas
 
4 more minutes and here is the full set of debs for opipc
http://guillaume.romagny.free.fr/armbian/sun8i_opipc_mik20160724.zip
 
give it a try

Yes, in igorpecovnik/lib master

Hi,
 
I'm using an Orange Pi PC and i'm having some issues using traffic control.
 
I'm using the correct network interface using the command
tc qdisc add dev wlx30b5c214fe58 root handle 1: cbq avpkt 1000 bandwidth 100mbit tc class add dev wlx30b5c214fe58 parent 1: classid 1:1 cbq rate 500kbit allot 1500 prio 5 bounded isolated tc class add dev wlx30b5c214fe58 parent 1: classid 1:2 cbq rate 500kbit allot 1500 prio 5 bounded isolated tc class add dev wlx30b5c214fe58 parent 1: classid 1:1 cbq rate 10kbit allot 1500 prio 5 bounded isolated
and i received the error RTNETLINK answers: No such file or directory   After some reading i saw that is missing 'kernel-modules-extra'.   Can someone have this issue also or can help me pls?!
Thanks in advance,
Lucas Schiochet