tkaiser

Well, that was what we observed one year ago on Orange Pi Zero prior to disabling wi-fi powermanagement (it reads off in your and @t.munzer's iwconfig output). Anyway new image finished uploading: http://kaiser-edv.de/tmp/NumpU8/Armbian_5.34_Sunvell-r69_Ubuntu_xenial_default_3.4.113.img.xz
 
In my opinion the fex file is fine now (looking at it not that much from an Armbian perspective but more having users of other projects in mind like H3Droid, RetrOrangePi, Lakka or @jernej's OpenELEC who hopefully can use the fex 1:1). For Armbian we would need mainline kernel/u-boot support contributed by volunteers.

TL;DR: The small H2+/H3 boards unlike their bigger siblings are all prone to overheating due to smaller PCB size (on the larger boards the PCB's groundplane acts somewhat as a large heatsink dissipating heat away from the SoC). Due to mainline kernel settings not being optimized currently all these boards are slower under constant load compared to legacy kernel. This should change but won't unless someone is looking into it and spends some time on this.
 
Two areas that deal with this overheating tendency or are somewhat related are
 
thermal protection / throttling: use the thermal sensor(s) inside the SoC to downclock various engines if specific tresholds are exceeded DVFS (dynamic voltage frequency scaling). All the small boards have either no voltage regulation (NanoPi NEO2) or a primitive one only switching between 1.1V and 1.3V  
With sun8i legacy kernel Armbian and linux-sunxi community members spent a lot of time and efforts on improving thermal/throttling performance. Read through the following as a reference please: https://github.com/armbian/build/issues/298
 
The result of our optimizations was a lot of better performance compared to Allwinner's defaults (that targeted only Android and preferred higher single thread performance over overall better performance, with Allwinner settings on an overheating system you could end up with just one or two active CPU cores pretty easily). Now with mainline kernel situation for the larger H3 boards is ok-ish (those boards have an I2C adjustable voltage regulator, voltage switching works fine grained, overheating isn't much of an issue anyway and performance is almost as good as with legacy kernel). But situation with the smaller boards needs some attention.
 
If we run the cheapest boards currently with mainline kernel then we're talking about these settings:
 
max cpufreq 1008 MHz (at 1.3V), next lower cpufreq 816 MHz at 1.1V, then 624/480/312/240/120 MHz defined 4 thermal trip points defined starting at 65"C with throttling, then using 75° and 90°C and shutting board down when 105°C are reached.  
With Armbian and using legacy kernel it's the following instead:
 
max cpufreq is 1200 MHz, then 1008 MHz still at 1.3V, at 912 MHz we switch to 1.1V and below are a few other cpufreqs available between 816 MHz and 1344 MHz Armbian's legacy kernel provides cpufreq steps every 48 MHz (allowing for fine grained throttling) On the small boards we use twice as much thermal trip points as mainline settings and our strategy is to switch to 912MHz@1.1V pretty early once throttling occurs  
These differences result in both lower 'normal' performance (since mainline kernel limits also single threaded tasks to 1GHz instead of 1.2GHz) and also 'full load' performance since DVFS/THS/throttling settings are not optimal and once the board reaches the first thermal trip point throttling is not that efficient compared to legacy.
 
It's easy to test: grab an OPi Zero, NanoPi Duo or any of the other H2+/H3 boards with primitive voltage regulation, then grab an Armbian OS image with legacy kernel (3.4.113 using fex settings) and one with mainline kernel. Execute on both
 
sudo rpimonitor -r (installs RPi-Monitor so you can enjoy nice graphs when connecting with a web browser to port 8888 of your machine) sudo rpimonitor -p (installs cpuminer which is a great tool to heatup your board and also to measure 'thermal performance' since spitting out khash/s values in benchmark mode minerd --benchmark (this is the actual benchmark running)  
With mainline kernel performance is lower. Expected result: same performance. What to do? Improve mainline settings.
 
BTW: Mainline settings currently are as they are since these were the values megi started with last year. Once numbers exist they're only dealt with copy&paste any more.

That's Ethernet (so packets in this direction travel over the other interface -- which might have slightly improved your wifi numbers before, it's not that easy to correctly measure wifi performance when more than one interface is active and two or more interfaces are connected to the same subnet). Anyway we already know we can't expect wonders from XR819, it works somewhat ok-ish (see @t.munzer results) and anyone wanting to have decent Wi-Fi performance can always add an RTL8211AU 2x2 MIMO dongle anyway (well, that needs most probably mainline kernel support so someone has to hack together a .dts and submit upstream)
 
Ok, then blue and visible led is connected to PA15 (and labeled wrongly red) and there's another rather invisible led connected to PL10 and wrongly labeled green. To make things worse I decided to now label the blue one green just to get almost consistent boot behaviour on all H2+/H3 boards (blue led labeled green will light up when kernel starts to load, at the time login is possible it will blink 3 times and then turn into solid mode again): https://github.com/armbian/build/commit/6981e324192dd6aad06e9ebd1a21a4c2f5c47d32
 
Will now create the Xenial image again (just check the timestamps at the download location). So now two contributions are IMO needed to consider switching from 'community supported' OS image to fully supported:
Someone has to create a device page in linux-sunxi wiki Someone has to submit pull requests with u-boot config (576 MHz DRAM clock, 1008MHz CPU clock and MMC2 setting for eMMC) and a patch adding DT for the board (please keep in mind that 3.4 LTS kernel support ended already half a year ago)

So SD cards became intelligent in the meantime and know what a partition table is? No, impossible.
 
Which tool did you use to write the image, how does F3 or H2testw test results for each card look like and what does 'armbianmonitor -u' reports (the '### mmc' section)?

The nice thing when used this RAID variant in NAS situations on GbE equipped H3/H5 boards is that the larger the available DRAM the less you realize that IO write speeds are limited to below 40MB/s since all NAS writes end up in filesystem buffers first and will later be flushed to disk. So with an OPi Plus 2E or OPi Prime you can transfer up to 1.5GB of data at +70MB/s and only then it slows down to ~35MB/s. On the boards with less memory this can happen already after just a few hundred MB written.

Interesting, maybe a packaging fix is needed.
 
No idea and won't look into further. Current situation is that most needed bits are part of Armbian repo, everyone can build/improve legacy images and wrt 'full support' we need a wiki page and some copy&paste work (using Beelink X2 mainline stuff it's mostly just that + testing which I can't since not owning the device).
 
Desktop and CLI image as well as 'support package' with individual packages: http://kaiser-edv.de/tmp/NumpU8/
45a44de60feb7b388ad77c456ff58917 Armbian_5.34_Sunvell-r69_Support_Package.tar.gz f3eb7ae54762e37df11a069d4193fddb Armbian_5.34_Sunvell-r69_Ubuntu_xenial_default_3.4.113_desktop.img.xz 44fdbd858437df4c1cfce81f0d92a8a6 Armbian_5.34_Sunvell-r69_Ubuntu_xenial_default_3.4.113.img.xz (No Debian yet of course since Stretch needs a newer kernel than the smelly Allwinner 3.4)

Of course. All data gone.
Nope, it's just metadata (small checksums used to verify data integrity) but no parity data like it's used with RAID5/6 and of course you can't reconstruct data from this type of metadata.
 
On H3/H5 boards that are limited by USB2 an interesting alternative could be a mdraid RAID10 with far layout using 2 disks (you don't need 4 for RAID10 and you should always use RAID10 if you wanted to use RAID1 on Linux in the meantime). This way you get full redundancy and protection against a drive fail while doubling at least read performance. This is an OPi Plus 2E with 2 SSDs in UAS capable JMS567 disk enclosures using a RAID10 with rather small chunk size (default ist 512K) and a btrfs on top:
mdadm --create /dev/md127 --verbose --level=10 --raid-devices=2 --layout=f2 --chunk=4 /dev/sda /dev/sdc RAID-10 made of Intel 540S and Samsung PM851 with 4k chunk size: random random kB reclen write rewrite read reread read write 102400 4 7044 7549 8654 8824 7058 7011 102400 16 14815 14508 25361 25344 21222 14731 102400 128 26835 26558 46249 47619 44310 26084 102400 512 26882 29306 51175 51847 51979 28552 102400 1024 29347 29960 51424 52177 52287 29056 102400 16384 30129 30715 74614 77384 78568 29954 4096000 4 36556 35967 81080 82749 4096000 1024 36335 35705 81314 81422  

I fixed my post.

Why?
 
Check https://forum.armbian.com/index.php?/topic/4583-rock64/&do=findComment&comment=37829 for example to get a clue which advantages the more modern CPU might have if you need AES encryption (still needs real-world tests of course, the numbers there are just a comparison at 'proof of concept' level). Then these Marvell things are made for NAS and router purposes unlike tablet, phone and TV box SoCs on other SBC. CPU utilization for IO and network related tasks is often less compared to other platforms due to better internal design.
 
But if CPU horsepower is really sufficient depends on the types of applications of course. If the box should do video transcoding or also build kernels the HC1 will outperform Espressobin of course. That's one of the reasons I still look forward to more RK3328 variants since quad-core and most probably video transcoding possible HW accelerated using Rockchip's video engine. But still lack of IO possibilities of course.
 

And one of that products you can only sell online since everyone trying it out in real life wants to throw it out of the window or back at the manufacturer asking for a refund
 
https://www.cnx-software.com/2017/02/15/gpd-pocket-cherry-trail-7-portable-computer-runs-ubuntu-16-04-or-windows-10-crowdfunding/

This (and similar relocation related issue on XU4/HC1 which killed UAS) should be hopefully fixed. Other kernel configs may have to be changed too in the future.

Hello everyone, today I would like to show you how to compile CoovaChilli and Freeradius for a Wifi Hotspot with captive portal on an Orange Pi PC  (or PC Plus). I'm writing this because I couldn't find anything related to this topic on the internet, so I wrote this not very detailed guide.
 
wget https://raw.githubusercontent.com/ua3nbw/opihotspot/master/opihotspot_debian.sh chmod +x opihotspot_debian.sh ./opihotspot_debian.sh Russian version https://ua3nbw.ru/all/orangepi-coovachilli-and-freeradius-for-a-wifi-hotspot-with-capt/

UK Server deployed. Details PM'd

"Oh dear! Oh my! Oh trouble!!" 
I think you just found a use case for this: https://github.com/avafinger/H5-firmware
 
 

@Igor  Ok Instead of integrating into our CDN which could be a pain without an infrastructure plan, I will keep it simple and provision for 12 months a UK server with 100GB sys / 500GB data storage & 2TB / month data allowance (can be upped if needed). Ill stick a load balancer / cache on the front of it for the public access mechanism and security and it can host as many repos / domains as you like.
 
Do you have a preference for OS / services or dont care? Ubuntu 16.04 is our normal platform but I can provide licences for RHEL7 or Windows Srv 2016 if needed
I presume you will want SSL enabled http repos. If you or whoever helps you wants to pull my personal email from the forum registration or PM on the forum with any specifics you need I can deploy and reply with access details etc and setup a plan to clone the primary repo and test. I will also give you the public ip(s) of the load balancer so that the *.uk.armbian dns records can be setup.

Or so  https://en.wikipedia.org/wiki/BogoMips#Timer-based_delays
 
Edit: sun8i legacy kernel is a 3.4 kernel so we have there high BogoMIPS values, starting with 3.6 on ARM the meaning is something different, now no DVFS so 'next' is a lot slower than 'default' and even if DVFS will work soon those small H3 board with mainline kernel will still be slower compared to before since 
 

Problem is that there are at least 4 different RasPi PSU's that I have seen and not a single one of them is suitable for powering the tinkerboard which draws upto 3 x more current under load than any of the Pi models. The 2.5A Pi PSU we tested (comes with the Pi3 Kit) would only actually deliver ~1.4A reliably and when it gets hot it gets very unreliable. Thats why I asked  for the numbers off the PSU. The most power hungry PI model (3B) uses 30-40% of the total current than the tinkerboard at max load (see attached chart). Even if you connect the Pi PSU through the GPIO pins there still isnt enough current from any Pi branded PSU I have seen to power the tinkerboard reliably. As a general rule, RasPi accessories (like the boards) are made to very low standards and budgets and should be avoided.
 
If you can provide details for me to replicate your software, ramdisk, swap and workload I can have a look at reproducing the problem and finding a solution or at least a cause. The fact you have swap on SD make me shudder!
 
 

There is no such thing and according to lsusb you also don't use an USB BT dongle.

I have one Orange Pi Zero which had Wi-Fi working in the beginning and after some days Wi-Fi stopped working. I'm always surprised that hardware that cheap as an Orange Pi Zero works in the first place. I remember the last thing I did before realizing that I had broken Wi-Fi on my Zero was taking a nap (you remember the last thing you did was trying out another kernel). But I don't think me taking a nap is related to hardware becoming broken.

After comparing SoPine and Pinebook schematics I can say that they are not the same. On the Pinebook vqmmc (port C power) is wired to a separate AXP output, on the SoPine vmmc (eMMC power supply) and vqmmc are tied together (and to the main 3.3v output), so it will be impossible to switch to speed modes that require 1.8V vqmmc, and any attempt of switching vqmmc to 1.8v will affect DCDC1 output voltage.

This is wrong, yes. Not expected to work since customize-image.sh has to be run as part of the build process. If you want to install OMV later you would today download softy, execute it and choose 'Install OMV':
wget https://raw.githubusercontent.com/armbian/config/dev/softy /bin/bash softy In a few weeks this is all part of next major Armbian release, then it's simply: armbian-config --> software --> Install OMV  (works today also but installation is not optimized so today better use the wget workaround above)

It's not "just" kernel. We need to go deeper and also provide simple u-boot and ATF update. Currently, it's non-existing and we rely on a stock which is somewhere between alfa and beta. AFAIK certain problems are already solved upstream, but you need to update the board. I haven't got that far yet ... idea was to conduct those tests on SD card, but it's not possible to boot from while it's possible from SATA. Recompiling ATF, U-BOOT, leaving SPI alone and trying to boot from SATA with most recent ATF/U-boot might be a good next step.

Hi,
 
Mainline Linux has support for the SCPI Temperature Sensor, please check in /sys/class/hwmon/hwmon0/temp1_input
 
For the hard crash, looking at the logs seems to indicate a memory issue, we will investigate further !
 
Thanks,
Neil

Here some fresh benchmarks with Helios4 configured as RAID6, then as RAID5 with 4x HDDs Western Digital RED 2TB.
 
Note : This is also a 1GB RAM version clocked at 1.6GHz.
 
RAID 6
md0 : active raid6 sdd1[3] sdc1[2] sdb1[1] sda1[0]
      39028736 blocks super 1.2 level 6, 128k chunk, algorithm 2 [4/4] [UUUU]
 
With buffer cache
iozone -e -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 112166 182202 878938 897663 720385 46844 102400 16 126067 193562 907704 1068469 1001711 98934 102400 512 118358 182862 985050 1006993 1001779 170459 102400 1024 117394 176268 875566 888008 889065 169862 102400 16384 114508 169885 818170 817925 827517 172793  
With DIRECT IO
iozone -e -a -I -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 5830 5826 34179 37669 2839 602 102400 16 12445 19215 66829 71497 10074 2198 102400 512 106759 116574 199069 281008 61111 124175 102400 1024 129763 105815 173525 237719 96948 139462 102400 16384 177544 171003 284953 315916 286591 164939  
RAID5
md0 : active raid5 sdd1[3] sdc1[2] sdb1[1] sda1[0]
      58543104 blocks super 1.2 level 5, 128k chunk, algorithm 2 [4/4] [UUUU]
 
With buffer cache
iozone -e -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 115183 170676 904434 895645 722963 51570 102400 16 119682 172369 1063885 1084722 1002759 116063 102400 512 123952 201012 989143 992372 1001279 148636 102400 1024 116065 197683 874443 885162 886703 198021 102400 16384 129151 199118 830783 845355 838656 180389  
With DIRECT IO
iozone -e -a -I -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 9552 10938 36978 39222 28551 530 102400 16 11185 20621 64135 77590 33906 2159 102400 512 40443 51534 96495 533923 536836 43272 102400 1024 84312 78308 122916 486366 440706 83712 102400 16384 196534 207664 598961 597055 619819 206123  
 
On small block operation, my setup shows CPU utilization 50% and memory usage 50%.
 
I know there is no obvious way to say if the system offload on the hardware XOR engine. Check your kernel message you should see the kernel has detected 2 XOR engine.
[    0.737452] mv_xor f1060800.xor: Marvell shared XOR driver
[    0.776401] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr pq )
[    0.776570] mv_xor f1060900.xor: Marvell shared XOR driver
[    0.816397] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr pq )
In the current armbian mvebu kernel config, mv_xor driver is part of the kernel, not a module.
 
I'm still trying to figure out a more concrete way to confirm that the system offload on hardware engine, but based on benchmark it does.
 
 

 

Hi,
 
For those interested in developing their own base board for Nano Pi Duo Ijust finished to design footprint and schematic symbol for Nanopi DUO under Altium.
 
Hope it can help someone, you can get it at https://github.com/frederir/NanoPiDuo-Altium
 
Best.
Frederir.