(09-16-2016, 12:34 AM)MarkHaysHarris777 Wrote: The ubuntu image running on the good board easily gets double the speed numbers up into the low to mid 800(s) while the debian image on the same board rarely gets above the mid 400(s).
Well, IMHO it's kinda useless to talk about 'the' ubuntu image since there are a few in the wild. Let's take Ubuntu/Xenial for example:
- longsleep's original based on kernel 3.10.102
- Something called 'Ubuntu Base Longsleep (3.10.65 BSP)' (available from pine64.pro -- if this is really still based on old, ugly and outdated 3.10.65 then that's just another reason to immediately shut the pine64.pro site down)
- Something called 'Ubuntu Linux Image [20160530] based on Longsleep build, updated by Pine64' (no idea which kernel version and settings are used here)
- Armbian / Xenial based on kernel 4.7
- Armbian / Xenial based on kernel 3.10.102
The first and the last one should perform nearly identical (longsleep boots AFAIK with performance governor set while we use interactive instead so his image might win the boot race by 0.2 seconds but then both images switch to interactive by default anyway
) What the other images do in between is unknown (depends on kernel version and settings). And performance might vary for absolutely unrelated reasons. As already said when 'ondemand' governor is used the kernel might not get it that network activity needs an increase in CPU clockspeeds (in Allwinner BSP kernels you would have to set a few other tweaks to get reliable behaviour but since ondemand is broken anyway simply switching to interactive is the better idea).
That means it might happen that someone with a distro relying on ondemand might get worse results with a headless distro (no GUI running) since an image with a desktop environment might generate more background activity, then the kernel increases clockspeeds and the network activity added on top will then lead to CPU cores running at 1152 MHz in the end. That's why I said it's necessary to always monitor in parallel (htop and longsleep's health script is enough!). And by looking at htop output it's pretty easy to understand why low network throughput seems to occur at low CPU clockspeeds. Since the iperf/iperf3 thread is maxing out one CPU core with 100%. By using monitoring the problem gets immediately visible (and the problem is the tool in question being CPU bound, not the network).
Another note: When I did some testing for longsleep back in April to improve DVI support I used exactly one time an Ubuntu image from pine64 wiki. This was configured to run default Ubuntu screensavers after 10 minutes of inactivity. So CPU activity increased from 2% to 400% 10 minutes after each reboot. Testing then with iperf led to a dramatic decrease in numbers but since monitoring is mandatory it was quite easy to get the reason for this (an OS image thrown together without care -- those silly 3D screensavers should only run on systems where GPU acceleration is available which is not the case for most SBC)
Regarding your Thinkpad. It seems it's ok when you get above 800 Mbits/sec against it but I was involved in an incident a few years ago where the customer's network staff used Thinkpads for iperf tests (they had poor performance through cascaded Cisco switches due to wrong algorithm used for the EtherChannels and wrong QoS settings) and the one they used invalidated all results since it acted as a bottleneck. Only after exchanging it with something better the network staff could be convinced that their switch config was the problem (the 'database boy' as you called me is doing network/storage performance optimization for a living)