(09-15-2016, 07:18 PM)pfeerick Wrote: So longlseeps ubuntu image is the one that offers the best out-of-the-box experience/configuration.
Would not agree. Sure, the temperature fix didn't made it into the release yet, I don't wanted to poke Igor now (please keep in mind that we support +40 SBC and that there are important and less important things to be done before such a major release) but this will come the next days (just do the usual apt-get update/upgrade, everything in Armbian will be fixed that way, no scripts needed)
In Armbian we have a few more tweaks that might improve NAS performance (the so called IRQ affinity, we send those for the USB ports to dedicated cores which helps in situations where both high IO and network activity happens and the so called IO scheduler, we treat HDDs and flash/SSD differently since... they are different, just look through /etc/init.d/armhwinfo) We also do a lot of logging and provide a mechanism to help us helping you ('sudo armbianmonitor -u' will upload extensive debug info).
But if you now compare longsleep's original Ubuntu image and your Armbian Jessie installation then longsleep's will show better performance as long as you rely on iperf3. Why? Since iperf/iperf3 are CPU bound and act in Xenial in one mode multi-threaded while on Jessie single-threaded and therefore Jessie will show lower numbers.
The whole iperf/iperf3 game played here is not taking into account what iperf/iperf3 are primarily measuring: CPU performance. If you want to test network instead you need to ensure that the other host is beefy enough to always exceed 935 Mbits/sec, it this is not the case then you always get random results.
So testing between two Pine64 with unknown settings is just producing numbers without meaning. If you test against a PC (it should be a PC since many Windows laptops for example throttle their network performance down when running on battery) then your local settings on Pine64 matter.
Our default cpufreq settings for A64 allow the CPU cores to jump between 480 and 1152 MHz. When they remain at 480 MHz (that's the 'ondemand' problem since this scheduler doesn't realize that network activity would also mean increasing clockspeed!) then you get pretty low scores since the CPU becomes the bottleneck. I tested that exactly for the audience here already, see post #2: http://forum.armbian.com/index.php/topic...s/?p=14673
So when Debian Jessie from pine64.pro shows just 410 / 595 Mbits/sec (the directions matter, you always have to test in both!) against a PC then you can imagine what you get when you let 2 Pine64 remaining at 480 MHz run against each other: Something in the 300 Mbits/sec range while your network connection is working perfect and would allow 940 Mbits/sec. Since iperf/iperf3 are CPU bound! When one of the 2 Pine64 is set to 1152 then it still matters which distro is used since iperf/iperf3 are still CPU bound and depending on the distro act sometimes multi-threaded and sometimes not (see link above, I tested and explained this already in detail)
And all of this I already tried to explain weeks ago when we started 'exploring' this fun stuff: http://forum.pine64.org/showthread.php?t...7#pid18687
TL;DR: If you want to test network throughput of your individual Pine64 in benchmark mode better switch to performance governor and test against a device that is known to exceed 935 MBits/sec. If a switch is in between it's necessary to know whether the switch allows exceeding 935 Mbits/sec or not (all my dumb GbE switches are fine, one of my 2 expensive managed shows sometimes weird behaviour). Testing with unknown cpufreq settings between 2 Pine64 is absolutely useless since numbers are just the result of CPU cores running at 480 MHz bottlenecking everything. Variation in results might be caused by anything. For real world scenarios switch to interactive governor since ondemand fails miserably detecting when to increase clockspeeds when it's about network and/or storage activities. Performance governor might show even better performance but then CPU cores run all the time at 1152 MHz (not that much of a problem since only consumption will increase slightly)
If you want a deeper understanding of this stuff you need to monitor what's happening in parallel (at least using htop, armbianmonitor or pine64_health.sh script, just read the last link above).