• iperf/iperf3 act single threaded in one operation mode, so you might end up with network performance in reality bottlenecked by CPU and the benchmarking tool in question (test methodology being wrong)
  
• Different Linux distros use different compiler settings which might also affect performance (for example, the sysbench binary shows 'performance numbers' 30 percent better when running with Ubuntu Xenial compared to Debian Jessie -- just by using other compiler switches when creating the distro's packages). I leave it up to the audience to test this out with the various distros available for Pine64 whether/how iperf/iperf3 are also affected (testing is easy, just try out various distros with iperf/iperf3 against a host that is known to exceed 900 Mbits/sec, reduce Pine64's cpufreq to 480 MHz and record the numbers and you see how your benchmarking tool 'performs')
  
• The cpufreq governor might make a difference since for example with ondemand cpufreq scaling works way too slow if only network activity increases. So in case the wrong tool and methodology is combined (iperf instead of iperf3 and default test execution of 10 seconds) you get wrong numbers or at least misleading ones. Never use any of these benchmarking tools without also running tools like htop and also longsleep's pine64_health.sh or Armbian's 'sudo armbianmonitor -m' (or install RPi-Monitor, it's easy and costs you only a few minutes)
  
• With longsleep's network tuning script applied performance drops down to ~800 Mbits/sec in Armbian -- this should be avoided when running Armbian (see updated explanation in Armbian forum, only variation increases a lot)
  
• Armbian images are always created from scratch and have not been tampered with by humans. So such mistakes as known from the official Pine64 Linux images leading to ARP nightmares will not happen. We set the MAC address on first boot.
  
• My test setup consists of a x86 box connected to the same el cheapo Gbit switch as Pine64 and a couple of other SBC. Most importantly Pine64 is powered reliably (that means not using Micro USB but the pins on the Euler header) and stays cool. It's known that RTL8211E Gbit PHY as used on Pine64+ needs an additional 350mW, it's known that using Micro USB for DC-IN is crap (consumption increase leads to voltage drops), it's also known that an overheating SoC consumes more energy than a cool one (details) which might add to powering/undervoltage related problems
  
• Iperf/iperf3 numbers don't tell the whole story, they're useful to rule out severe problems but only when used in active benchmarking mode trying to check for the real bottlenecks.
  

(10-25-2016, 07:08 PM)endotronic Wrote: Hey all, I found this thread while searching for ways to get GigE working on my Pine64 2GB. I'm not quite sure I have the latest longsleep kernel, but I did just install the most recent one I could find the other day:

Code:

kevin@pine64:~$ uname -a
Linux pine64 3.10.102-2-pine64-longsleep #66 SMP PREEMPT Sat Jul 16 10:53:13 CEST 2016 aarch64 aarch64 aarch64 GNU/Linux

I added the network tuning script to /etc/rc.local, but the improvement was very minimal. Using iperf I see bandwidths rarely topping 4 Mbits/sec. If I run "sudo ethtool -s eth0 speed 100 duplex full" or plug into a 10/100 switch, I very consistently get 92+ MBits/sec.

I can live with this, but I intended to use my Pine64 as a file server, so it is falling a little short. Am I missing something?

longsleep, thank you for all your hard work on this. It's really impressive.