manuti

For me, the best H3 web browsing experience is with Firefox on a Beelink X2 using Armbian on the internal NAND. The difference between Beelink X2 (1GB RAM + armbian on NAND) vs Orange Pi One (512MB RAM + Samsung EVO) is very significant, is not like my core i5 with 4GB of RAM but is more or less decent.

Had a bit of time today to do testing.
Downloaded a fresh copy of the Beelink X2 Jessie server image file Armbian_5.14_Beelinkx2_Debian_jessie_3.4.112.7z. Unpacked it and burnt to a micro-SD card. Put the card in my Beelink X2 and switched the power on. The only thing connected to the Beelink X2 is power and network cable.
 
Of course it booted just as expected and performed the dual boot it should do on first boot. So there is no fault in the ARMbian image file.
 
Here are my observations of the LED behaviour. By LAN led I mean the led on the switch port my Beelink X2 is connected to. I find observing the led on the switch to be the best way to know what is happening.
 
  1st boot: solid purple solid blue LAN led on flashing blue/purple LAN led off flashing red/blue   2nd boot: solid purple solid blue LAN led on flashing blue solid blue ready to log in via ssh

By adding those two files to:
~/.local/share/keyring/default Default_keyring ~/.local/share/keyring/Default_keyring [keyring] display-name=Default keyring ctime=1473189692 mtime=0 lock-on-idle=false lock-after=false Solves the problem. Wifi passwords are getting stored as plain text and we are not asked for anything regarding this.

Now a real world example showing where you end up with the usual 'benchmarking gone wrong' approach. Imagine you need to set up a web server for static contents only. 100 GB of pure text files (not that realistic but just to show you how important it is to look closer). The server will be behind a leased line limited to 100 Mbits/sec. Which SBC to choose?
 
The usual benchmark approaches tell you to measure sequential transfer speeds and nothing else (which is OK for streaming use cases when DVD images several GB each in size are provided but which is absolutely useless when we're talking about accessing 100 GB of small files in a random fashion -- the 'web server use case'). Then the usual benchmark tells you to measure throughput with iperf (web serving small files is about latency, that's quite the opposite) and some silly moronic stuff to measure how fast your web server is using the loopback interface of your server and test tool on the same machine not testing network at all (how does that translate to any real world web server usage? Exactly: not at all).
 
If we rely on the passive benchmarking numbers and have in mind that we have to serve 100 GB at a reasonable cost we end up thinking about an externally connected HDD and a board with GbE (since iperf numbers look many times faster than Fast Ethernet) and a board that shows the highest page request numbers testing on the local machine (when the whole 'benchmark' turns into a multi-threaded CPU test and has nothing to do with web serving at all). Please don't laugh, but that's how usual SBC comparisons deal with this.
 
So you choose from the list above as storage implementation an external 500 GB HDD since USB performance looks ok-ish with all boards  (+30 MB/s), and NanoPi M3 since iperf numbers look nice (GbE) and most importantly it will perform the best on the loopback interface since it has the most and the fastest CPU cores.
 
This way you end up with a really slow implementation since accessing files is more or less only random IO. The usual 2.5" notebook HDD you use on the USB port achieves less than 100 IOPS (see above result for USB HDD on Banana Pro with UASP incapable enclosure). By looking at iperf performance on the GbE interface you also overlooked that your web server is bottlenecked by the leased line to 100 Mbits/sec anyway.
 
What to do? Use HTTP transport stream compression since text documents show a compression ratio of more than 1:3, many even 1:10, (every modern web server and most browsers support this). With this activated NanoPi now reads the text documents from disk and compresses it on the fly and based on a 1:3 compression ratio we can stream 300 Mbits/sec through our 100 Mbits/sec line. Initially accessing files is still slow as hell (lowest random IO performance possible by choosing USB HDD) but at least once the file has been read from disk it can saturate the leased line.
 
So relying on passive benchmarking we chose a combination of devices (NanoPi M3 + 500 GB HDD) that costs +100$ considering also shipping/taxes and is slow as hell for the use case in question.
 
If we stop relying on passive benchmarking, really look at our use case and switch on our brain we can not only save a lots of money but also improve performance by magnitudes. With an active benchmarking approach we identify the bottlenecks first:
Leased line with 100 Mbits/sec only: we need to use HTTP content-stream compression to overcome this limitation Random access to many files: we need to take care of random IO more than sequential transfer speeds We need to tune our network settings to make the most out of the sitiuation. Being able to use the most recent kernel version is important! We're on a SBC and have to take care of CPU ressources: so we use a web server with minimum ressources and should find a way to avoid reading uncompressed contents from disk to immediately compress it on the fly since this wastes CPU ressources So let's take an approach that would look horribly slow in the usual benchmarks but improves performance a lot: An Orange Pi One together with a Samsung EVO 64 GB as hardware, mainline kernel + btrfs + nginx + gzip_static configuration. Why and how does this work?
Orange Pi One has only Fast Ethernet and not GbE. Does this matter? Nope, since our leased line is limited to 100 Mbits/sec anyway we know that the cheap EVO/EVO+ with 32/64 GB perform excellent when it's about random reads. At 4K we get 875 IOPS (3500 KB/s, see comparison of results), that's 8 times faster than using an external USB HDD we use pre-compressed contents: that means a cron job compresses each and every of our static files and creates a compressed version with .gz suffix, if nginx communicates with browsers capable of that it delivers the already compressed contents directly (no CPU cylces wasted, if we configure nginx with sendfile option not even time in userspace wasted since the kernel shoves the file directly to the network interface!). Combine the sequential read limitation of SD cards on most boards (~23MB/s) with an 1:3 compression ratio and you end up at ~70MB/s with this trick. Twice as fast as uncompressed contents on an USB disk unfortunately we would also need the uncompressed data on disk since some browsers (behind proxies) do not support content compression. How to deal with that? Using mainline kernel, btrfs and btrfs' own transparent file compression. So the 'uncompressed' files are also compressed but at a lower layer and while we now have each and every file twice on disk (SD card in fact) we only need 50 GB storage capacity for 100 GB original contents based on an 1:3 compression ratio. The increase in sequential read performance is still twice as fast since decompression happens on the fly. Not directly related to the filesystem but by tweaking network settings for low latency and many concurrent connections we might be able to improve requests per seconds when many clients access in parallel also by factor 2 compared to an old smelly Android 3.x kernel we still have to use on many SBC (relationship with storage: If we do tune network settings this way we need storage with high IOPS even more) An Orange Pi One together with an EVO 64GB costs a fraction of NanoPi M3 + USB HDD, consumes nearly nothing while being magnitudes faster for the 'static files web server' use case if set up correctly. While the usual moronic benchmarks testing CPU horsepower, GbE throughput and sequential speeds would show exactly the opposite.
 
And you get this reduction in costs and this increase in performance just by stopping to believe in all these 'benchmarking gone wrong' numbers spread everywhere and switching to active benchmarking: testing the stuff that really matters, checking how that correlates with reality (your use case and the average workload) and then setting up things the right way.
 
Final note: Of course an Orange Pi One is not the perfect web server due to low amount of DRAM. The best way to overcome slow storage is to avoid access to it. As soon as files are in Linux' filesystem cache the speed of the storage implementation doesn't matter any more.
 
So having our web server use case in mind: If we do further active benchmarking and identify a set of files that are accessed most frequently we could add another Orange Pi One and a Pine64+ with 2GB. The new OPi One acts as load balancer and SSL accelerator for the second OPi One, the Pine64+ does SSL encryption on his own and holds the most frequently accessed 1.7 GB in RAM ('grep -r foobar /var/www' at startup in the background -- please keep in mind that it's still +5 GB in reality if we're talking about a 1:3 compression ratio. Simply by switching on our brain we get 5GB contents cached in memory on a device that features only 2 GB physical RAM!). And the best: both new boards do not even need local storage since they can be FEL booted from our first OPi One.

We provided this week experimental Armbian images with mainline kernel for a few H3 boards. On the official download pages there are a few variants with 4.6.7 lurking around and here you find some with 4.7.2: http://kaiser-edv.de/tmp/w8JAAY/
  Those for the NEO are also suitable for NanoPi M1 and OPi One/Lite, the one for OPi PC Plus can be used on any of the larger Oranges (no Ethernet on +/+2/+2E -- don't ask please, this is stuff for later) since they all use the same more sophisticated voltage regulator being able to adjust VDD_CPUX in 20mW steps (VDD_CPUX is the voltage the CPU cores are fed with). The procedure is called dynamic voltage frequency scaling and the idea behind is to lower voltage on the CPU cores when they're running at lower clockspeeds and vice versa.   Works pretty well with legacy kernel in the meantime but it required a lot of work to come up with optimal settings that are still reliable (undervolting the CPU causes stability problems and data corruption!) while also providing best performance results (lower VDD_CPUX voltage, less heat, later throttling). For details please read through the whole issue here: https://github.com/igorpecovnik/lib/issues/298   So what has changed with mainline kernel now? In Armbian we use megi's kernel branch containing Ethernet and dvfs/THS patches and a few others. What's still missing and what do you get now when trying out these mainline images? No HDMI, no audio, no sophisticated SBC stuff like I2C, SPI and so on (unless you know how to deal with device tree overlays).   But USB, Ethernet on all Fast Ethernet equipped devices (no network on GbE models currently!), cpufreq scaling / dvfs, working WiFi and with 4.7 also the opportunity to test out USB OTG and the new schedutil cpufreq scheduler.   My 4.7.2 Armbian releases contain also a new armbianmonitor variant that can deal with mainline kernel on H3 boards (different templates needed and a different method to get VDD_CPUX values -- fex file vs. device tree) and can install cpuminer. Why cpuminer? To test the efficiency of throttling settings -- see below. As usual RPi-Monitor can be installed using 'sudo armbianmonitor -r' and now cpuminer will be installed by 'sudo armbianmonitor -p' (p for performance measurements).   To let cpuminer run in fully automated mode do a 'touch /root/.cpuminer', then minerd in benchmark mode will immediately start after booting and results will be collected by RPi-Monitor (not on the status page but only on the statistics page -- actual values aren't interesting only behaviour over time!)   Dvfs settings for Orange Pi PC and the other SY8106A equipped H3 devices already look good and work quite well (although I would tweak them here and there) while those settings for the H3 devices with the more primitive voltage regulation do not.   I used a NanoPi NEO for the test but the results apply to all H3 boards that use only 2 different VDD_CPU voltages: NanoPi M1/NEO/NEO-Air and OPi One/Lite. Unlike the Oranges NanoPI M1 and NEO overheat more easily, the latter especially (maybe due to smaller PCB size, single bank DRAM configuration and LDO regulators nearby the SoC?). And tested on the only remaining NEO that does not wear a heatsink.   In the beginning I allowed 1200 MHz max cpufreq but since I neither used heatsink nor fan throttling had to jump in to prevent overheating. In this mode H3 started running cpuminer at 1200 MHz, clocked down to 1008 MHz pretty fast and from then on always switched between 624 MHz (1.1V VDD_CPU) and 1008 MHz (1.3V VDD_CPU). The possible 816 MHz (1.1V) in between were never used. Average consumption in this mode was 2550 mW and average cpuminer score 1200 khash/s:     I then limited max cpufreq to 816 MHz through sysfs and let the test continue. In the beginning H3 switched between 624 and 816 MHz but since SoC temperature further decreased H3 stayed then all the time at 816 MHz and below 75°C (the highest allowed cpufreq at the lower VDD_CPU core voltage with megi's settings!). Average consumption in this mode was 2420 mW and average cpuminer score 1350 khash/s.   This is how cpufreq and temperatures correlated over time:
  So we got an increase in performance from 1200 to 1350 khash/s (+12.5%) while being able to lower consumption by 130 mW (2550 mW vs. 2420 mW) so not only performance increased but also performance per watt ratio if we manually adjust maximum cpufreq and forbid everything above 816 MHz. Quite the opposite of what one would expect   At least it should be obvious that dvfs settings for the small H3 devices need some attention. I monitored consumption through AXP209 on a Banana Pro feeding the H3 device through its USB port. The high voltage fluctuations due to the NEO's voltage regulator constantly switching between 1.1V and 1.3V can be seen until 8:12, then the '30 minutes average value' stabilized at 8:42 and the real consumption difference could be read: 130 mW:         With legacy kernel we defined a lot more possible cpufreq/dvfs operating points so let's give it a try: Same hardware setup (same NEO, same USB-to-Micro-USB cable from Banana Pro to NEO, same upright position for nearly identical thermal behaviour), same DRAM clockspeed (408 MHz) but different DVFS/THS settings of course:     If we compare mainline kernel with max cpufreq limited to 816 MHz and legacy kernel we get 4.7.2: 1350 khash/s, ~74°C, constant 816 MHz cpufreq, 2420 mW reported consumption 3.4.112: 1150 khash/s, ~80°C, 648-720 MHz cpufreq, 2610 mW reported consumption Looking at numbers 1 to 3 it simply feels weird: lower clockspeed, lower performance but higher temperatures. Would be an indication for different thermal readouts between mainline and legacy kernel (we had the same issue half a year ago when switching from BSP u-boot to mainline: temperature readouts 10-15°C lower).   But fortunately I also monitored consumption and there it's 200 mW more. On the same hardware with the same hardware setup. So there is really something happening on the NEO that wastes more energy when running minderd with legacy kernel and that might be responsible for higher temperatures and more aggressive throttling leading to lower performance (at least that's the only possible reason I can imagine)   Since we already know that on the NEO adjusting DRAM clockspeed with legacy kernel makes a huge difference regarding consumption and temperatures (see post #13 here) maybe the whole problem is related to different DRAM config on the NEO (single bank vs. dual bank on all other H3 devices) and something's wrong with mainline kernel here? Don't know but already decided to repeat the test with NanoPi M1 (dual bank DRAM config but also the primitive 1.1/1.3V voltage regulation)

-

I think that a fan controller is a nice thing to play with. But when you use Armbian with H3 devices there's really no need for a fan, since a quality heatsink is enough (you don't even a heatsink if you are able to accept that throttling will happen earlier, you only loose performance but that's it -- your H3 is always save). Please read through post #2 here: http://forum.armbian.com/index.php/topic/1850-pi-fan-issues-on-orange-pi-pc/?p=14192
 
Apart from that I've looked a lot into how consumption with H3 boards can be minimized the last weeks. Less consumption is also less temperatures. To me it seems absurd to add components that waste additional energy to only lower cosmetically the temperatures of other components especially since they're made for high temperatures. H3 is not an animal or a human being that gets hurt by temperatures exceeding 40°C. It's a chip rated for up to 125°C

Thanks, it works!!!

I added a script lurking around on my disk for some time to Armbian's repo to be hopefully included into future Armbian releases when testing looks good: https://github.com/igorpecovnik/lib/blob/master/scripts/h3consumption
 
Since it's just a script you can include it in your running Armbian installation simply by downloading it from Github -- try it this way please:
sudo -s wget -q -O /usr/local/bin/h3consumption "https://raw.githubusercontent.com/igorpecovnik/lib/master/scripts/h3consumption" chmod 755 /usr/local/bin/h3consumption h3consumption -H h3consumption -p The last 2 calls will show the verbose help text along with current settings. This might then look like this:
 
 
 
Mode of operation/test:
Please read through the description (-H output) first and check also the referenced links Use -p to get currently used settings Use the other switches to modify settings Do not use -p now but instead do a reboot first and then check again -p You might also have a look at /etc/rc.local and /etc/defaults/cpufrequtils to get an idea where the script does things for a better understanding Two examples (will go into details later in different thread😞
On an Orange Pi Plus 2E 'h3consumption -c 1 -m 1296 -d 408 -g off -e fast' reduces default idle consumption from 1650 mW by 780 mW to just 870 mW On an Orange Pi Lite 'h3consumption -D 132 -c1 -g off -u off' reduces default idle consumption from 1060 mW by 660 mW to just 400 mW (same low consumption running identical settings possible with NanoPi M1, Orange Pi One/PC/PC Plus and maybe the larger boards too when GBit Ethernet PHY can be completely disabled) Please note: the -D switch allows to use DRAM clockspeeds that are way below Allwinner's defaults and what's expected to work ok (since DDR3 shouldn't be clocked lower than 300 MHz and Allwinner used 408 MHz clockspeed as lower limit). While clockspeeds as low as 132 MHz seemed to work reliably in my tests and it should be ok to test these out when having in mind that this is an experimental feature you won't be able to go lower than 408 MHz anyway without a kernel patch (available in post #14 here) with all available official Armbian releases. So you've to either use the kernel .deb I provide in the other thread or wait for a new round of Armbian images (no idea how Igor's plans look like)

i did a 4.6.4 kernel armbian build for my opi one yesterday. I was delighted. Ethernet worked. Docker worked after only an apt-get install. i launched a basic ubuntu xenial arm container and it held together. nothing like a 512 meg docker host
 
Tapatalk thinks its important to tell you im using tapatalk from a phone.

That means a new hardware revision is out since the older Beelink X2 are equipped with AP6181: http://linux-sunxi.org/images/1/19/X2_PCB_top.jpg(the device I have also has AP6181 but different DRAM modules compared to the wiki picture)
 
Did you check which hardware revision you have?

Finally I discover my Beelin X2 have a `8189es` so applying same firmware but change the bcmhd part by the 8189es all the tings go up.
manuti@beelinkx2:~$ sudo modprobe 8189es firmware_path=/lib/firmware/ap6210/8189es.bin nvram_path=/lib/firmware/ap6210/nvram.txt manuti@beelinkx2:~$ lsmod Module Size Used by 8189es 1076034 0 mali_drm 2732 1 drm 178255 2 mali_drm mali 123208 0 ump 29379 3 mali sunxi_spdma 3703 1 sunxi_spdif 7037 1 sunxi_sndspdif 3885 0 sndspdif 2743 1 hid_logitech_dj 10040 0 manuti@beelinkx2:~$ sudo ifconfig wlan0 up manuti@beelinkx2:~$ sudo iwlist wlan0 scan wlan0 Scan completed : Cell 01 - Address: xx:xx:xx:xx:xx:xx ESSID:"xxx" Thanks a lot to everybody.

Got my NEO's this morning ! So far so good, the form factor is excellent and there is still some place to screw in M3 spacers without shorts on SMDs (was afraid of this being an issue when reviewing the dxf schematic) 
I'm currently running the version of Snappy Ubuntu while waiting for the ARMbian to come out
 
I'll be happy to run some test if you guys need anything; I have currently 10 of them running on my desk.
 
Bonus : picture of the NEO hooked up with my proto POE module (PCB hat on it's way !)

Yesterday I showed in the first post above how on some AXP209 equipped boards like Lime2 the 5V provided through the USB host ports can be switched on/off using the sunxi-pio utility. So if we use a battery equipped A10/A20 board we can use this also to power other consumers through the USB ports, can switch them off and on and provide an 'uninterruptable power supply' (UPS) mode.
 
The same way we can also cut power to on-board components that are controlled through AXP209, for example a connected SATA disk. The following graph shows Lime2 powered through USB OTG (to get the 'big picture' regarding consumption -- see the post before for reasons when to choose which powering mode). On the left the 2TB Samsung is in 'active/idle' state (spinning but doing nothing -- ~480 mA consumption), then my power management settings in /etc/rc.local let the disk switch to 'standby' mode after 5 minutes of inactivity (340 mA) and then I switched off power to the disk completely using sunxi-pio (230 mA):
 

 
How to know which pin has to be toggled? I just looked into the fex file again:
sata_power_en = port:PC03<1><default><default><0> So by using the following we can physically power off the disk after unmounting the filesystems of course (not available as device later until we power it on with sunxi-pio again or reboot the board):
sunxi-pio -m PC03'<default><default<default><0>' # off sunxi-pio -m PC03'<default><default<default><1>' # on Unfortunately from all our AXP209 equipped boards only a few support powering the disk through AXP209:
 
 
 
But what about other onboard components that might not be used but are by default in 'powered on' state and add to the board's consumption while not needed. Let's search for the magical word '_power' inside the fex files:
 
 
Would be interesting to play around with LCD and CSI power settings and to have a look whether switching those pins off where defined as on by default makes any difference regarding consumption (or for example the GBit Ethernet PHY on some boards when they do not need network connectivity). But this is stuff I leave for others to test and get back to this thread with results.
 
Since we're talking about disks. These are the two lines I add to /etc/rc.local to spin-down Samsung/Seagate SATA disks on A20 boards after 5 minutes of inactivity:
hdparm -B 254 /dev/sda hdparm -S 60 /dev/sda And to manually send SATA disks to sleep 'hdparm -Y /dev/sdX' can be used. Please keep in mind that this is SATA stuff and not every USB-to-SATA bridge contained in USB disk enclosures supports this. Also some disks ignore sleep and power management settings and then scripted approaches like hdd-spindown.sh are needed (as we can see above physically powering off a disk leads to further energy savings but without switching power on the disk won't come back when needed -- unlike sleeping since then the disk's controller simply wakes it up when a new disk access happens)

SOLVED!
 
Here is solution (for H3):
 
1. Convert script.bin to FEX:
cd /boot bin2fex script.bin script.fex 2. Edit script.fex to enable UART3:
sudo nano script.fex Find section [uart0] and set the next to disable uart0-2 and enable uart3 only with 2-pin mode on pin 8/10:
[uart0] uart_used = 0 uart_port = 0 uart_type = 2 uart_tx = port:PA04<2><1><default><default> uart_rx = port:PA05<2><1><default><default> [uart1] uart_used = 0 uart_port = 1 uart_type = 4 uart_tx = port:PG06<2><1><default><default> uart_rx = port:PG07<2><1><default><default> uart_rts = port:PG08<2><1><default><default> uart_cts = port:PG09<2><1><default><default> [uart2] uart_used = 0 uart_port = 2 uart_type = 4 uart_tx = port:PA00<2><1><default><default> uart_rx = port:PA01<2><1><default><default> uart_rts = port:PA02<2><1><default><default> uart_cts = port:PA03<2><1><default><default> [uart3] uart_used = 1 uart_port = 3 uart_type = 2 uart_tx = port:PA13<2><1><default><default> uart_rx = port:PA14<2><1><default><default> ;uart_rts = port:PA15<3><1><default><default> ;uart_cts = port:PA16<3><1><default><default> Remark: I don't find description for value <2> in PA13<2> but it works as expected.
 
3. Save changes.
 
4. Convert FEX to bin
fex2bin script.fex script.bin 5. Reboot.
 
6. Device name is ttyS3. Default speed = 57600. To test it type "echo TEST > /dev/ttyS3"
 
 
PS. Some times after 
apt-get upgrade script.bin replaces to default values, so it need to repeat all steps.

Be very very careful. There exist no correct specification regarding GPIO pin layout for the Banana Pi M2: http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/411-m2-gpio-defininiton?start=6#2648
 
All the glorious 'Team BPi' (that provided so much crappy software and wrong informations and is responsible for missing informations and support) did, is to steal the above picture from http://www.raspberrypi-spy.co.uk and remove their logo. Don't expect that any pin mapping is correct, it's just a manipulated picture stolen from somewhere else.
 
Please crawl through the two most horrible forums ever to get a clue how much of this stuff simply is wrong:
http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2 (this is 'Team BPi's former official Banana Pi forum abandoned a few months ago) http://forum.banana-pi.org/c/bpi-m2 (this is the current official forum -- maybe they already prepare to abandon this and start over with a fresh one somewhere else? At least the most moronic marketing person ever that normally floods the forum with useless crap is quiet. Not a single @sinovoip post the last days!) The best thing you can do with a M2 is to use it as headless server or throw it into the bin.
 
Ok, to be a bit more constructive: UART pin mappings depend on the device tree definitions when using Armbian (mainline kernel only available for M2). Maybe others can assist you. I won't waste my time with any of 'Team BPi's products any more (R1, M2, M3 -- I'm sure they already develop an M4 and M5).

There's no need to benchmark this. I tested with mainline kernel and 3 external USB disks half a year ago (back then no SMP was working so H3 was running on a single CPU core at 1008 MHz) and could saturate all three host ports. Performance of the OTG port when used as host port is also known, so when H3 is running on all 4 cores it's no problem to exceed 150 MB/s while using all 4 USB ports in parallel. Network performance is also already known and since H3 is powerful enough it's also not a problem to saturate USB lines and GbE in parallel. You find some numbers in this thread: http://forum.armbian.com/index.php/topic/1440-h3-devices-as-nas/
 
Performance might vary depending on kernel version (GbE with mainline kernel is currently slower compared to legacy kernel, regarding USB storage it's the other way around) but the important thing here is: 4 USB ports and 1 GbE network port that do neither have to share bandwidth nor block each other when used in parallel. And this is the most important differentiation to any RPi where everything is limited by the single USB 2.0 connection. Any data that has to be transferred between a disk connected to RPi (USB) and a client behind the network (also USB) has to pass this bottleneck twice. It's really not comparable and RPi suffers a lot when it's about transferring data.
 
But to be honest: Since we're talking about clustering it's all about the use case. Do cluster nodes need high network bandwidth? Then forget about any RPi and choose SoCs with true GbE networking. Do they need high local storage throughput? If so forget about any RPi and maybe also about any non-SATA SoC. And so on.
 
Clustering with cheap ARM boards looks nice and might be a useful tinkering excercise doing some things right (eg. an intelligent cooling approach instead of the brain-dead ones mostly seen). But there are only a few reasonable use cases for such stuff (eg. an automated build/test farm for ARM installations since testing stuff natively might be 20 times faster than using QEMU) and especially when people start thinking about HPC stuff then choosing ARM boards that aren't OpenCL capable and can compute stuff on powerful GPU cores is laughable (since you would need a few hundred boards, an insane amount of networking equipment and cabling and the whole cluster would still be outperformed by any middle class GPGPU capable cheap PC)

Yeah, bcmdhd driver has some strange things inside the code. It seems mandatory to have some file specified, but later on it gets replaced with correct FW name based on chip id. If you check driver source, you can see a lot of different FW file names.

http://linux-sunxi.org/Orange_Pi_One#Orientation_of_the_GPIO_header

-

Thanks a million Igor.

I'm wondering the same thing. I was able to install Chromium using the latest Ubuntu Trusty (which is based on Debian Jessie) armhf packages on my Debian Jessie Armbian build running on a Banana Pi M1. I had to install libgcrypt11, chromium-codecs-ffmpeg-extra, and chromium-browser Ubuntu .deb files. The rest of the dependencies were found from the Debian apt sources.
 
But the performance is unbearably slow. I figured with 1GB and a dual-core ARMv7 processor, that web browsing would be at least decent and on par with the experience you get with smartphones. It's not even close. Since Armbian is a bare bones installation, is it possible that I'd need to install other packages to improve web browsing performance? I'm even running everything off a speedier SSD drive on the SATA port, rather than off of the SD card. I tried Midori and that consistently freezes after loading virtually any webpage. Thanks for any suggestions.
 
UPDATE: I'm starting to suspect this has a lot to do with the fact that I'm on the mainline kernel without any GPU acceleration. So all of the X11 rendering is handled by the CPU, which naturally is going to be unbearably slow for any graphics intensive programs, like a web browser. This is just an assumption on my part, so I could be wrong. Sadly it looks like I'll have to back off to the legacy kernel until GPU support is added to the mainline kernel.

It was already fixed and an update will be issued ASAP to minimize the problem. This was simple overlooked so it could not appear in the changelog. We are overloaded. Sorry. 

I put the firmware file on my webserver http://www.itgubben.eu/files/

Thx for the reminder. But fortunately the same pin mapping is used. I just did this
root@beelinkx2:/home/tk# modprobe sunxi-cir root@beelinkx2:/home/tk# ir-keytable -p NEC,RC-5,RC-6,JVC,SONY,LIRC,OTHER ; ir-keytable -c ; ir-keytable -t Invalid parameter(s) ir-keytable: -p: (PROGRAM ERROR) Option should have been recognized!? Try `ir-keytable --help' or `ir-keytable --usage' for more information. Old keytable cleared Testing events. Please, press CTRL-C to abort. 1466427392.393181: event type EV_MSC(0x04): scancode = 0x03 1466427392.393209: event type EV_SYN(0x00). 1466427392.837740: event type EV_MSC(0x04): scancode = 0x03 1466427392.837767: event type EV_SYN(0x00). 1466427393.983779: event type EV_MSC(0x04): scancode = 0x02 1466427393.983808: event type EV_SYN(0x00). 1466427397.780964: event type EV_MSC(0x04): scancode = 0x48 1466427397.780994: event type EV_SYN(0x00). 1466427398.716936: event type EV_MSC(0x04): scancode = 0x48 1466427398.716964: event type EV_SYN(0x00). 1466427401.090401: event type EV_MSC(0x04): scancode = 0x14 1466427401.090431: event type EV_SYN(0x00). 1466427402.939626: event type EV_MSC(0x04): scancode = 0x5c 1466427402.939656: event type EV_SYN(0x00). 1466427403.581513: event type EV_MSC(0x04): scancode = 0x5c 1466427403.581539: event type EV_SYN(0x00). 1466427407.404387: event type EV_MSC(0x04): scancode = 0x0b 1466427407.404416: event type EV_SYN(0x00). 1466427411.510339: event type EV_MSC(0x04): scancode = 0x58 1466427411.510367: event type EV_SYN(0x00). 1466427412.160997: event type EV_MSC(0x04): scancode = 0x58 1466427412.161022: event type EV_SYN(0x00). So IR also works. Since Beelink X2 ships with a remote someone a bit familiar with this stuff could start now (read as: before we release Armbian 5.15) to add an appropriate config file we could then integrate into the build (but I have to admit that I'm such a NOOB regarding IR that I don't know how to deal with the information from this thread where I found how to check the scancodes)
 
On a related note. The on/off button on Beelink X2 also uses the correct pin mapping. After installation of the acpid package this is possible:
root@beelinkx2:/home/tk# acpi_listen button/power PBTN 00000080 00000000 So all we need to do is to define a shutdown action for the 'button/power' event, in the most simple form as follows:
echo -e 'event=button/power\naction=/etc/acpi/check-and-shutdown.sh' >/etc/acpi/events/powerbtn echo -e '#!/bin/bash\nshutdown -h now' >/etc/acpi/check-and-shutdown.sh chmod 755 /etc/acpi/check-and-shutdown.sh Then the simple press of the power button executes the script code in /etc/acpi/check-and-shutdown.sh (in the aforementioned example without a check -- but on an Orange Pi Lite I currently use as a backup device I added some code to check whether a backup is currently running delaying the shutdown until the task is finished). Of course anything else can also happen when the power button is pressed, it's just the execution of some script code (and the same applies to each and every Orange Pi out there too)