Rui Ribeiro

@badrianiulian
 
I wouldn't bother much regarding the spec
https://wikidevi.com/wiki/Ralink_RT5572
better using a wifi usb key "ready to play" as AP
 
@tkaiser
Thanks for your interesting web research
WiTi board has not enough RAM for me
Omnia is promising as a router (they are related to CZ.NIC CZ DNS authority) but not polyvalent enough for my personal needs

Hello all you happy people ... I'm back with an update
First here's a photo I took tonight when I cleaned the dust out

Also as of tonight my uptime was 25 days, 37 min
 
There is an issue with HDMI though... When I leave the HDMI connected (even if I'm watching or not), after a while (3-4days) the system freezes.
Also if the HDMI isn't connected at startup, there is no signal on screen when I connect the HDMI after the bootup... Anyone knows what's going on with that?

Warning: This whole thread is only about historical information now since it's 2018 and we can buy inexpensive and great performing A1 rated SD cards in the meantime. Buying anything else is a mistake so directly jump to the end of the thread for performance numbers and recommendations.
 
 
 
Edit: See an early 2017 update at the end of the thread regarding new SD specs also covering random IO performance.
 
Edit 2: Some thoughts/observations on lifespan/reliability of SBC storage: http://tech.scargill.net/a-question-of-lifespan/ (see also/especially the comments there)
 
Edit 3: CNX Software picked up recent performance reports (eg. by Andreas Spiess) and other important issues around SD cards: http://www.cnx-software.com/2017/06/13/micro-sd-cards-for-development-boards-classes-tools-benchmarks-reliability-and-tips-tricks/
 
Edit 4: See an early 2018 update testing real world A1 performance class products at the end of the thread.
 
Edit 5: See here and there for some rather boring but very important information about Armbian's tries to prevent SD cards wearing out too fast.
 
 

 
Preparations:
 
I tested 8 different SD/TF cards under identical conditions. I created an Armbian 5.07 image to be used on Banana Pi (A20 SoC with 4.4.6 kernel, ext4 rootfs (Armbian defaults == no journal), 960MHz scaling_max_cpufreq, scaling_governor == performance. All test runs were done using 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' and monitored using 'sudo iostat 5' for anomalies (none detected).
  Kernel version matters (since with Allwinner's 3.4 kernel sequential throughput is limited to ~16MB/s, with mainline kernel we get close to Banana Pi SDIO implementation's max: ~23MB/s) and filesystem settings matter too (enabled journal for example slows down 4K writes a lot).   Sequential speeds:     Random I/O:     The 4 Samsung cards were bought within the last 3 weeks and manufactured between 09/2015 and 12/2015 according to the card's metadata. Interesting observation: I used three of these cards the first time and they all show identical behaviour especially regarding writes with small record sizes: pretty slow in the beginning and getting faster over time (the Samsung Pro for example started with only 1400KB/s 4K writes and 3 runs later the same test showed 3270KB/s -- maybe an indication that some sort of calibration happened. Anyway: I know why I always repeat tests and do not rely on a single test run)   Sequential speed mostly irrelevant / random I/O differs and matters a lot!   The SanDisk Extreme Pro has been bought nearly 3 years ago. This card shows superior sequential read/write performance compared to the three Samsung EVOs. But only when used in combination with a host that can make use of these speeds. My MacBook writes 4 times faster an OS image to the Extreme Pro compared to the EVOs. But this doesn't matter at all since the SDIO implementation of the board in question is limited to ~23MB/s (50MHz @ 4 bit). The same sequential write/read speed limitation applies to most SBCs since to be able to exceed this slow mode the voltage the SD/TF card is fed with would've to be adjusted (default 3.3V, the faster modes require a dynamic switch to 1.8V instead which some/most SoCs can perform but if the SBC vendor doesn't implement this you're limited to ~23MB/s).   Therefore cards labeled as being capable of "up to 90MB/s" do not perform different than those that can only do "up to 20MB/s" as long as we're talking about sequential transfers since the SD card interface is already the bottleneck. But since we're using SD/TF cards not in cameras but as storage media for the rootfs of an SBC something different is more important: Random I/O. And here performance of cards that are labeled identical ('class 10' for example) differs a lot.   All 4 Samsungs outperform the other cards easily in this area. The SanDisk Extreme Pro can not compete regarding random I/O compared to superiour (but mostly irrelevant) sequential transfer speeds. And funnily the 3 other cards show horribly slow random write performance, especially with 16k record size. According to card metadata the 2 Intenso are oemid 0x5048 / manfid: 0x000027 (cheap crap known to die way too early) and I would believe the SanDisk 'class 10' card is a fake or at least uses the same controller as the 2 Intenso since 16K random writes are also way slower than 4K writes.   Detailed results (summary table also available as .ods, .xlsx or .txt):   Samsung Pro 64GB (brand new) http://sprunge.us/DEYd   Samsung EVO+ 64GB (brand new) http://sprunge.us/NLQd   Samsung EVO+ 32GB (brand new) http://sprunge.us/heGL   Samsung EVO 64GB (already used some time) http://sprunge.us/DUOS   SanDisk Extreme Pro 8GB (already used some time) http://sprunge.us/ZPFZ   SanDisk 'Class 10' 8GB (already used some time) http://sprunge.us/OHjT   Intenso 'Class 10' 16GB (already used some time) http://sprunge.us/LUMZ   Intenso 'Class 4' 4GB (already used some time) http://sprunge.us/GbAY   Some updates from Igor (still showing superiour EVO results but the clear winner is ODROID's eMMC module with SD card adapter):   Transcend Premium 300x 16GB (almost new) http://sprunge.us/UcSD  
 
 
Sandisk Extreme Pro 8Gb (almost new) http://sprunge.us/aDJJ
 
 
 
Hardkernel eMMC 8G via SD reader (brand new) http://sprunge.us/SHXF
 
 
 
Sandisk Ultra 8Gb (old and very used) http://sprunge.us/OWZf
 
 
 
Sandisk 8GB (almost new) http://sprunge.us/iViT
 
 
 
Sandisk 8G (new) http://sprunge.us/XHjj
 
 
 
Transcend 8Gb (used) http://sprunge.us/NTRT
 
 
 
Samsung EVO 32Gb (brand new) http://sprunge.us/bTQh
 
 
    Further readings: http://www.bunniestudios.com/blog/?page_id=1022 http://thewirecutter.com/reviews/best-microsd-card/ http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card http://www.bradfordembedded.com/2014/05/flashbenching/ Conclusions:
If the board's SD card interface is the bottleneck since it's not supporting the faster SDIO modes using expensive cards that exceed the interface's maximum sequential bandwidth is useless. An expensive Samsung Pro Plus won't be faster than a way more cheap EVO when it's about sequential transfer speeds since you will stay at ~22MB/s anyway Sequential read and especially write speeds are all the SD association's speed ratings are about (to ensure reliable recording of videos/images in cameras/recorders) When an SD card is used in an SBC sequential speeds aren't that important. It's all about random I/O, especially with small block sizes (reading and writing small random chunks of data from/to the card) No commonly used 'random I/O' speed ratings exist so you have to check the card in question prior to usage or rely on appropriate benchmarks (see the two links directly above). Again: the 'speed class' won't tell you anything. You can get two different 'class 10' cards that differ by 500% or even more regarding real world storage performance (again: random I/O matters). In the example above the Intenso 'class 10' card is 385 slower compared to the EVOs when it's about 16K random writes (good luck if you have a database running that uses this page size) Interestingly more expensive cards are outperformed by cheaper ones (the EVOs show a better overall performance compared to the Samsung Pro since sequential speeds are limited by the interface) One extreme example: Using an identical cloned installation that was somewhat outdated on the small 4GB Intenso card and on the 64GB EVO resulted in the following times for an 'apt-get upgrade' (+200 packages): EVO less than 6 minutes vs. 390 minutes (yes, ~6.5 hours) with the Intenso. The time to finish depends largely on fast random writes. It's easy to test the card in question when running Armbian since we ship with iozone. Therefore simply execute the iozone call from the first paragraph after logging in as a normal user. Starting with Armbian 5.06 a even better method exists that also tests the whole card for errors: armbianmonitor -c will report precisely both performance and health state of your card

So in other words: You did not test the SD card using F3 or H2testw in the meantime?

- Added Hummigboard 2 with working PCI and onboard wireless with legacy kernel 3.14.65. This applies for HB1 & Cubox too.

Again: Use a good heatsink, use thermal paste and most importantly: Let convection do the work.
 
I have a cheap port multiplier here that automatically starts to corrupt data under load due to overheating:
 

 
After I attached a heatsink and operated the thing vertically problems were gone:
 

 
 
And the good news is: The way convection works the better it cools parts that get hotter than others.

Something must be amiss with the  kernel sources?
 
I had to change in /lib/modules/4.4.1-sunxi/build the following occurrences of 4.4.1 to 4.4.1-sunxi
 
include/generated/utsrelease.h:#define UTS_RELEASE "4.4.1"
include/config/auto.conf.cmd:ifneq "$(KERNELVERSION)" "4.4.1"
include/config/kernel.release:4.4.1
 
And then I was able to compile the sysdig module without problems. 
 
Now insmod does not load due to other problem:
 
# insmod ./sysdig-probe.ko 
insmod: ERROR: could not insert module ./sysdig-probe.ko: Unknown symbol in module
root@ruir:/lib/modules/4.4.1-sunxi/updates/dkms# dmesg | tail
[165564.069037] sysdig_probe: Unknown symbol tracepoint_probe_register (err 0)
[165565.581076] sysdig_probe: Unknown symbol tracepoint_probe_unregister (err 0)
[165565.581439] sysdig_probe: Unknown symbol for_each_kernel_tracepoint (err 0)
[165565.581493] sysdig_probe: Unknown symbol tracepoint_probe_register (err 0)
[165571.445442] sysdig_probe: Unknown symbol tracepoint_probe_unregister (err 0)
[165571.445804] sysdig_probe: Unknown symbol for_each_kernel_tracepoint (err 0)
[165571.445858] sysdig_probe: Unknown symbol tracepoint_probe_register (err 0)
[165961.635924] sysdig_probe: Unknown symbol tracepoint_probe_unregister (err 0)
[165961.636286] sysdig_probe: Unknown symbol for_each_kernel_tracepoint (err 0)
[165961.636338] sysdig_probe: Unknown symbol tracepoint_probe_register (err 0)

You can always use config file in /boot, but I would still recommend using build script (documentation), mainly because of additional patches.
 
I'll check description for these options later to see if it's OK to have them on by default.

Before you start to think about trying to tweak network settings please accept that something else went wrong. If Armbian boots you get a SSH console. The only exception: When you chose an OS image for Orange Pi Plus and use it on any other Orange Pi variant or something went wrong at the first boot regarding H3 board auto detection (you can read about in the original thread and better use the link below since it points you more directly to an explanation of the problem)
 
What you should look for instead is:
Serial console available (this will save you huge amounts of time since you see what's going on) To which file /boot/script.bin is linked to (that might be the culprit), see the H3 Mini FAQ where it's about wrong detection of Orange Pi 2 SD card really ok? Armbian 5.05 (where lots of stuff is fixed) the other thread since your issue is most likely well known in the meantime (please be aware that 5.04 is still a test version)   TL;DR: It seems that for whatever reasons board auto detection fails and network doesn't come up (physically -- without the correct definition in a so called fex file you can't even "reach" the hardware so everything you tweak in Debian/Ubuntu is totally useless). The only way to fix this is to relink script.bin to orangepipc.bin.

Use armbianmonitor for the following tasks: armbianmonitor -b switches between verbose and normal boot armbianmonitor -c /path/to/test performs disk health/performance tests armbianmonitor -d tries to upload debug disk info to improve armbianmonitor armbianmonitor -m provides simple CLI monitoring armbianmonitor -r tries to install RPi-Monitor armbianmonitor -u tries to upload armhwinfo.log for support purposes This is currently possible.

That means that boot loader is patched / prepared and we did a manual boot. For installer we need to create / adjust scripts and make few tests. This is scheduled for next release - in 2-3 weeks. This info is valuable for users who knows how to do it manually.
 
http://forum.armbian.com/index.php/topic/881-prepare-v51-v201604/

BTW: I fixed packaging script so this "make scripts" is done on headers install and will not be needed any more ... adding later today.

@Rui
 
I have probably already put my little workaround script on the forum for DKMS modules after I update Armbian kernel (and before reboot)
#!/bin/bash sudo rm /tmp/.reboot_required pushd . for f in $(ls -d /usr/src/linux-headers-*-sunxi) do cd $f sudo make scripts done popd sudo dpkg -i frandom-dkms_1.1-0centrych4_armhf.deb sudo apt-get install --reinstall -t jessie-backports sysdig sysdig-dkms

hello Rui,
 
tkaiser put a picture of the GPIO pins issue on L-R1 quite a while ago
 
http://linux-sunxi.org/Lamobo_R1#Pictures=> http://linux-sunxi.org/File:Addon_Board_on_Lamobo_R1_Fixed_Orientation.JPG
 
My "picoolfan" module (RTC+fan) on my R1 is "out of the box"
http://www.voc-electronics.com/a-37420681/gpio-extensions/picoolfan/

Just a small post about how to connect the PL2303HX RS-232 adaptor cable and the Real Time Clock. Do not trust the Banana pi photos as the I2C bus in the Lamobo/Banana PI R1 is inverted.
 
As they say a picture is better than a thousand words. Often the online Banana PI/Lamobo PI diagrams can be confusing, and do not even try to guide yourself by Banana PI pinouts / photos of placement of hardware products/extensions. I will reiterate again, as this can be a source of confusion, the Banana PI is a rebranded Lamobo product, and the GPIO bus is different/rotated 180º.
 

 
To scan the GPIO:
 
$sudo i2cdetect -l
i2c-0 i2c       mv64xxx_i2c adapter             I2C adapter
i2c-1 i2c       mv64xxx_i2c adapter             I2C adapter
$sudo i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
$sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --
 
The 68 is the RTC.
 
For the  PL2303HX I also have in /etc/inittab:
 
T0:2345:respawn:/sbin/getty -L ttyS0 115200 vt100
 
and add to the kernel bootargs in /boot/boot.scr :
 
setenv bootargs "console=tty1 console=ttyS0,115200n8 
 
and to finish:
 
$sudo mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

@ALL
 
thanks a lot for reporting the issue

Yes, it was quite obvious that you had a problem with random writes. And the following is not for you but for anybody else stumbling accross this thread.
 
NEVER use bonnie/bonnie++, dd or hdparm to measure storage performance with Armbian.
 
We ship with iozone for a reason since iozone testing is more reliable and especially results are easier comparable.
 
Do a chdir to the directory in question and then do a
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 to get a quick overview how your storage behaves and think about running the 3 sets of tests outlined here if you're interested in maximum sequential transfer speeds.
 
The most important rule when benchmarking: Don't trust in the numbers you get since they are wrong most of the times. But there are tools that prevent you from measuring wrong numbers a bit better than others but none is perfect. A short list of really incapable 'benchmark' tools (unfortunately these are the 3 most recommended amongst SBC users):
hdparm: only a weird joke since the 'benchmark' runs just a few seconds and chances that the results are influenced by a short write burst in the meantime are 50% or higher. If used as often recommended (-tT) then you're tampering disk throughput with memory bandwidth also which makes the results even more meaningless dd: most often used with the wrong flags, therefore not testing disk but RAM (caches/buffers) instead, only testing sequential speeds and mostly with absolutely irrelevant block sizes that tell you nothing about 'real world' performance bonnie/bonnie++: They test something but definitely not what they claim to do. Bonnie(++) output is interesting if you're an engineer to tune your operating system or to learn how compiler switches might influence benchmarks but it's nothing for end-users Same applies to 'mixed' tests that also invoke high CPU utilisation (scp test results vary depending on the strength of negotiated SSH ciphers on weak ARM boards, so you're testing the speed of encryption algorithms and not storage/network most probably) or tamper disk throughput with network throughput (FTP, NFS, SMB, whatever). These tests are useful to get the idea how your application might behave but they can't help you identify the bottlenecks or improve the situation.

Just a small post about how to connect the PL2303HX RS-232 adaptor cable and the Real Time Clock. Do not trust the Banana pi photos as the I2C bus in the Lamobo/Banana PI R1 is inverted.
 
As they say a picture is better than a thousand words. Often the online Banana PI/Lamobo PI diagrams can be confusing, and do not even try to guide yourself by Banana PI pinouts / photos of placement of hardware products/extensions. I will reiterate again, as this can be a source of confusion, the Banana PI is a rebranded Lamobo product, and the GPIO bus is different/rotated 180º.
 

 
To scan the GPIO:
 
$sudo i2cdetect -l
i2c-0 i2c       mv64xxx_i2c adapter             I2C adapter
i2c-1 i2c       mv64xxx_i2c adapter             I2C adapter
$sudo i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
$sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --
 
The 68 is the RTC.
 
For the  PL2303HX I also have in /etc/inittab:
 
T0:2345:respawn:/sbin/getty -L ttyS0 115200 vt100
 
and add to the kernel bootargs in /boot/boot.scr :
 
setenv bootargs "console=tty1 console=ttyS0,115200n8 
 
and to finish:
 
$sudo mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

The numbers the Pi foundation produced are fine. They show that RPi 3 is faster than RPi 2 even when running their slow ARMv6 code. So by comparing the RPi 3 numbers with other boards that are able to run code already optimised for ARMv8 you get the idea how performance might improve when they switch their software foundation to Aarch64/ARMv8 (both Pine64 and C2 are 10 to 15 times faster than RPi 3 in this 'benchmark test' since they're able to run optimised code)
 
What really scares me is how one can test different SD cards and cpufreq governors in reality and then conclude he has tested two boards instead: http://openbenchmarking.org/result/1603051-GA-ODROIDPI362
 
ODROID-C2 finished in 13 seconds and RPi 3 in 219. Is the C2 over 16 times faster when running SQLite workloads? Nope, it's just the difference a fast SD card with high IOPS and ondemand vs. performance cpufreq governor might make. And when this benchmark should be of any use then not to draw conclusions about "ODROID vs. RPi" but to check what's the most important factor for this sort of SQLite workload (disk intensive) and then either choose the storage that meets these requirements (C2 with an expensive eMMC 5.0 module or even better a Banana Pi with connected SATA SSD) or choose an appropriate platform (I wouldn't run databases on systems without ECC RAM except for read-only stuff like eg. CMS or something like this where the contained data can be reconstructed in case of failures)

Benchmark results produced by maker and associative are corrupt by origin   PI magazine is a part of marketing department while their primary job is to impress people with a bunch of bull shit. Numbers are how they should be   They must be somehow higher then Rpi2 otherwise believers can be frustrated. They, by definition, doesn't want to face reality, so it's already represented accordingly. It keeps them and their faith high. 

It's important to believe blindly in numbers! At least when you try to be mislead as much as possible!
 
Yesterday Michael Larabel from Phoronix fired up his usual set of passive benchmarking tests for the new Raspberry Pi 3 and he still uses rather questionable results for other boards to compare with (he claims that it would be sufficient to use a board with 'factory settings', run a set of synthetic benchmarks, don't analyse the results or even think about whether they could be wrong and treat the results as the truth)
 

 
RPi 3 is 4 times faster than OPi PC and 6 times faster than OPi Plus? Really?
 
If you just try to think about these graphs for a second it's obvious that there must be something wrong: Testing Orange Pi PC and Plus individually already makes no sense at all (same SoC, same settings --> same performance results to be expected) and publishing results that vary that much is alarming: either your benchmark must be wrong or the conditions or the tester. If you just think a second it's obvious that Orange Pi PC and Plus have to be faster than Banana Pi M2 (also an Allwinner ARMv7 SoC clocked a bit slower) and that you should drop any results if you experience a difference of more than 10% between both boards that must perform identical.
 
So I took our Armbian 5.05 release candidate and tested 2 of Phoronix' benchmarks on an H3 based Orange Pi (and then stopped this waste of time):
 
C-Ray: 340 with Armbian vs. 1425 according to Phoronix. Using Armbian increased the performance by over 400% (if you're dumb enough to rely on 'benchmarking gone wrong')
John the Ripper: 558 with Armbian vs. 315 according to Phoronix. Using Armbian increased the performance by 77% (if you're dumb enough to rely on 'benchmarking gone wrong')
 
Confusing! Why is Armbian way faster?! And why does choosing Armbian speeds up your Orange Pi in one case over 4 times and in the other case just by 77%? Let's have a closer look:
 
How does Armbian differ:
We are able to use 1.3GHz as CPU clockspeed (might speed things up) For reliability reasons we clock the DRAM lower (might slow things down) Most importantly: We don't use braindead thermal throttling settings (and I used a heatsink/fan) And the latter is the most important issue that Michael Larabel seems to miss at all when he uses the 'benchmark' results he collected sometimes ago to compare between different hardware. It's 2016 now! Each and every more recent SoC is a throttling candidate. This has to be taken into account if you want to benchmark a SoC or a board. If you ignore this your results are plain bullshit (just like Michael's).
 
When he tried to 'benchmark' Orange Pi PC and Plus he obviously ran into the problem that the vendor's budget cooling settings favoured killing CPU cores instead of thermal throttling so he obviously ended up with just one active CPU core left after some time of testing. And while this was an important finding (OS images for Orange Pis all crap more or less back then and negatively influencing performance) it's also important that this is nothing the hardware has to be blamed for.
 
The very same board running with Armbian performs more than four times faster! Think about. So obviously the benchmarks Phoronix recommends do not test the hardware but something else instead.
 
To be clear: the Phoronix test suite is fantastic when used correctly. That means ACTIVE BENCHMARKING and not collecting meaningless numbers and then relying on these worthless numbers to draw the wrong conclusions. When using the Phoronix test suite correctly you can identify performance bottlenecks and boundary conditions that affect performance easily (wrong cpufreq governor, killed CPU cores, thermal throttling, wrong settings, whatever). And also what to do to increase performance (tweaking compiler/scheduler settings, constantly trying out to optimise things until it works better).
 
The worst thing you could do with the Phoronix test suite is to collect numbers without meaning (passive benchmarking) and then use them to draw the wrong conclusions (that's what most of Phoronix' users including the author of the test suite do all the times).
 
Back to the origin again: We started with the Raspberry Pi 3 and 'benchmarking gone wrong' the Phoronix way. You really should take the numbers Michael/Phoronix published with a grain of salt since he neither mentioned whether throttling happened nor he commented on the consequences for the RPi 3 if the RPi foundation understands that it's necessary to provide a Raspbian version that is ARMv8 optimised.
 
The RPi foundation claimed the new RPi 3 would outperform the RPi 2 by 50% using questionable sysbench results. If they would've optimised their Raspbian code base for ARMv8 they could claim the RPi 3 would be at least 15 times faster. Why? Because benchmarks are always wrong and using sysbench (that calculates prime numbers) can't be used any more to compare between different ARM architectures (or architectures in general): http://forum.odroid.com/viewtopic.php?f=136&t=19158(I'm really curious whether Phoronix gets that when 'benchmarking' ODROID C2)
 
TL;DR: Benchmarking is fine as long as you use it to optimise software and to rule out insufficient hardware. When used wrong it's misleading (unfortunately that happens most of the time)

Hi Rui,

You are using pure iptables. I am using the CSF Firewall which is pretty handy and because of the bridged interface I have to add those three commands.
I ran yesterday a first scan with nmap on TCP and I will run more tests. So far my code works.
By the way, I am not using VPN.
 
Google is your friend (mostly :-) )
Difference between SNAT and Masquerade
 

Hi,
 
In order to secure my BPi-R1 I want to install a firewall on top of armbian.
So please, no tipps for complete 'firewall distribution like IPcop, IPfire'.
 
So I thought about, what is necessary to protect 'my cloud', which may be not the first interest for a hacker.
My test candidates:
Open Edgewize Shorewall ConfigServer Security & Firewall (csf) iptables (do it on your own)  
I collected some information of their functions, but I don't know what is crucial.
Application Layer Filtering Just managing your network by port numbers and ip addresses is no longer sufficient. With the growing levels of web use, and http based applications, deep packet inspection is needed to properly manage your network securely. User authentication (invite some friends to share pictures) Blacklist Whitelist  
As the R1 can hold a HDD I want to load it with things like:
LAMP http://ampache.org/  http://www.seafile.com/en/home/  http://syncthing.net/ https://sourceforge.net/projects/xbian/ OpenMediaVault may be testing owncloud I would like to know, what is your take on that and how do you secure your devices?
 
Cheers
Tido

Just to add some more confusion here
 
I learned today that Linksys WRT1200AC is based on Marvell's Armada 38x (see Clearfog Pro -- using the internal 128MB NAND for u-boot and combining this with external USB/eSATA storage it would be even possible to run Armbian on it).
 
And since a new toy arrived today the next thing I'll try is to get an USB3-to-GbE adapter. This board idles at 2W, Ethernet throughput 940 Mbits/sec, quick USB3 storage test showed 170 MB/s (didn't had a faster drive to test). But definitely no candidate for Armbian support
 
 
 

Small update: the ODROID-C2 is now officially announced (and Hardkernel did it right again: large heatsink as factory default and same board dimensions and connector layout -- I hope they will release a C2+ based on S912 with 4GB RAM later that year).
 
And the Pine guys started promoting their Peripheral On Top (POT) 'pseudo standard' with a few announced add-ons that look good to me (missing an 1-Wire-to-I2C POT, based on eg. DS2482S)