LAN/NIC problem

[tkaiser]

Speeds above 120mb/s follow the law of diminishing returns. Because of other system latencies on most SBC(s) including the pine boards, in over 95% of use cases 100mb/s is more than sufficient in most situations.

It feels almost insane to answer to such weird claims. One last try: if you would start to accept that Raspberries are different (those have problems with networking and overall throughput since their SoCs are crippled!), that Pine64+ is nothing new (SBCs exist for quite a long time now) and that there exist a world outside this pine64 forum here then it really gets easy.

At Armbian we currently support 21 SBC that feature GBit Ethernet (Pine64+ inlcuded). All of those are able to get close to 30 MB/s in NAS mode (GbE network, single disk USB 2.0) or exceed this (GbE network, SATA or RAID). Why should this be different with Pine64+ (of course it's not, @pfeerick demonstrated this to you, this is just common knowledge, everyone knows this, typical NAS boxes come with MIPS, PowerPC or ARM SoCs that are way slower, have less CPU cores and are accompanied by way less RAM but show performance numbers way 'above 120mb/s').

If you don't get 'above 120mb/s' why not thinking about what IS wrong instead of trying to justify bad performance numbers? This specific problem can be cured. Just switch to interactive if ondemand is used and on pine64.pro OS images both network and storage throughput will magically increase a lot (@pfreerick even demonstrated that to you)

Code:

sudo apt-get install cpufrequtils
cpufreq-info
sudo cpufreq-set -g interactive

[MarkHaysHarris777]

Speeds above 120mb/s follow the law of diminishing returns. Because of other system latencies on most SBC(s) including the pine boards, in over 95% of use cases 100mb/s is more than sufficient in most situations.

<snip>

If you don't get 'above 120mb/s' why not thinking about what IS wrong instead of trying to justify bad performance numbers? This specific problem can be cured. Just switch to interactive if ondemand is used and on pine64.pro OS images both network and storage throughput will magically increase a lot (@pfreerick even demonstrated that to you)

Code:

sudo apt-get install cpufrequtils
cpufreq-info
sudo cpufreq-set -g interactive

Thank you.  This is helpful too.

... I promise I'm going to play around with this today... dedicate some time to it.  I did see Pete's example, but have not tried this particular experiment with my own working ( GbE ) board. So, I'll make sure that happens today sometime... will get back to you /

marcus

[tkaiser]

Bug trackers already exist online

That's not the problem. OS images are provided by pine64.pro and on the pine64 wiki. These images base on linux-sunxi communiy's work and especially longsleep's work/scripts. Longsleep took care that appropriate settings are used and that issues get fixed (for example assigning a static MAC address based on the random MAC address the driver chose) so using his original Ubuntu Xenial image (emphasis on ORIGINAL!!!) you don't run into these two still present network problems.

What has happened in the meantime? 'Official' images do not contain the fixes (or it takes ages to adopt the necessary bug fixes), countless other images got spitten out with bad settings and adding even such silly mistake as 'same MAC address on every device'. (that's just weird and destroying other's good work)

Then a bug tracker is installed that 'accepts' exactly this silly mistake as a bug. And instead of fixing the issue these 'bug reports' simply decay over there. The problem is not technical infrastructure, the problem is ignorance and confusion constantly being spread. And an attitude by some 'opinion leaders' here that prevent any progress. Fortunately for Pine64 development it's absolutely irrelevant what happens here. It's just the average users that are suffering from this. Development happens somewhere else while users here are cut off from (relying on outdated stuff using bad settings since they are kept away from the good stuff like longsleep's ORIGINAL OS image, the ones in pine64 wiki base on his work but added the MAC address flaw!).

Enough time wasted here again. When I come up with Pine64+ NAS benchmarks with FreeBSD and mainline kernel I post them to Armbian forum, feel free to link to then.

[pfeerick]

I'm sorry you feel that way... but do appreciate the time you have spent in trying to highlight issues in the pine64 development process, as there are issues, and they need to be resolve in order to consolidate all the confusion presented by the different sites and images.

So in a nutshell, what you're suggesting is needed (which Armbian has already done) is a scripted way to make pine64 images, which will then make it possible to easily reproduce, upgrade and fault-find. Also, which is why I was heading towards already-existing stuff  like github - if we use a system that people are already familiar with, they are more likely to interact, thus there is a better chance of getting more community members involved. But at the same time, we need to get rid of all the legacy images, which are just adding the confusion unnecessarily, and ensuring that old bugs pop up again un-necessarily. And naturally, if we have some sort of automated build system, if a bug report came in for something a silly as the uEnv.txt having hard-coded mac address by default, it could be fixed, tested, and an updated image made available. And if there was some way to add a CI system like Travis, even some of the testing would be automated as you go... i.e. changes to build scripts.  

Maybe we need to split this off into another discussion thread focusing on streamlining the build process & documentation (maybe at post #133?) so this can be discussed further. It would probably also go hand-in-hand with the discussion stating up about potentially android moving from the code base that the pine64 guys have been working on to a community one as that appears more stable and more manageable, so there is again the question of how to make so everything can be backed up, tracked, documented, etc.

Enough time wasted here again. When I come up with Pine64+ NAS benchmarks with FreeBSD and mainline kernel I post them to Armbian forum, feel free to link to then.

[tkaiser]

   

That's a GbE equipped H3 device running with Armbian defaults sharing a RAID-0 over two USB disks. Testing from a MacBook connected to an el cheapo GbE switch. Old boring BSP kernel is used, therefore no UASP possible, no special 'tuning'. Just defaults. If you would've done the same test with OS images from the board's manufacturer (Xunlong) results would be way lower (due to wrong cpufreq settings and also wrong THS / throttling settings which will lead to killed CPU cores and a pretty slow overall system running on only 1 or 2 CPU cores after load peaks).

Why do I emphasize on this? Since settings matter!

We (linux-sunxi community and Armbian team) developed better THS/throttling settings first for H3 devices and then for Pine64's A64 (already back in March). Based on the experiences we made with H3 the whole job was easy with A64 since both SoCs are pretty similar and even the BSP kernel drivers use the same wrong strategies (wrong for Linux use cases!). Unfortunately a lot of OS images have way too late or never been updated to make use of this (applies to situation with both H3 and A64 and is something I already tried to explain to you earlier. But you just ignored that ('a zillion words') instead of taking into account that settings of the OS image in use really matter if one wants to explore why network performance sucks)

Anyway: H3 is a bit slower than A64 and shows a single-threaded limitation in RX direction which is mostly responsible for the poor write test results (below 55 MB/s). And that's why I'm pretty confident that Pine64+ is able to get close to or even exceed 80 MB/s (with mainline kernel and appropriate storage and network settings). The boards I tested with that are now away are able to do this so lets hope TL Lim will send out new working ones (the math is really simple: adjust settings, measure network and storage individually, check bottlenecks and you know what to expect. We do this all the time at Armbian since this is one of the project goals: identify bottlenecks and come up with appropriate settings to push these little beasts to the envelope)

But as already written: just by using longsleep's original Xenial image one would already get approriate settings that work pretty well regarding both storage and network. That's also one of the reasons why we came up with official Armbian images that late (Pine64 and Pine64+ both being supported since May by our automated build system): since for those Pine64+ users that knew what they were doing there was no need for Armbian, longsleep's image worked fantastic from the very beginning (and there exists only one original OS image from him that's this here. None of the images available at http://wiki.pine64.org or https://www.pine64.pro is from him even if he's mentioned all the time. Those images and their users suffer from wrong settings and silly bugs like 'same MAC address')

[jandvs]

Speeds above 120mb/s follow the law of diminishing returns. Because of other system latencies on most SBC(s) including the pine boards, in over 95% of use cases 100mb/s is more than sufficient in most situations.

<snip>

If you don't get 'above 120mb/s' why not thinking about what IS wrong instead of trying to justify bad performance numbers? This specific problem can be cured. Just switch to interactive if ondemand is used and on pine64.pro OS images both network and storage throughput will magically increase a lot (@pfreerick even demonstrated that to you)

Code:

sudo apt-get install cpufrequtils
cpufreq-info
sudo cpufreq-set -g interactive

Thank you.  This is helpful too.

... I promise I'm going to play around with this today... dedicate some time to it.  I did see Pete's example, but have not tried this particular experiment with my own working ( GbE ) board. So, I'll make sure that happens today sometime... will get back to you /

marcus

I tried this on my Diet-Pi image.  It didn't make a difference.  Couldn't ping google.com at all.  Got 42% to 54% packet loss pinging a local network pc.  Still worked fine at 100mb/s.

TL Lim asked me to send him my board for testing, so it's shipping out today.

[tkaiser]

I tried this on my Diet-Pi image.  It didn't make a difference.

• if your board is affected by the GbE issue then it's useless to play around with cpufreq governor. Only work-around is to force Fast Ethemet, only solution is to get the board replaced
  
• DietPi does not use cpufrequtils anyway, there you would have to use 'dietpi-config' to adjust settings. David (DietPi lead) switched some time ago to Armbian as build system on all SBC != Raspberry Pi (so at least relevant kemel patches are incorporated into DietPi) but to be honest I've no idea which cpufreq governor he uses on Pine64 but I fear it's also ondemand (I tried to convince him a while ago from ondemand being a really bad choice for Allwinner BSP kernels, maybe he fixed that in the meantime)
  
• The whole issue here is about one person claiming SBC are not able to exceed laughable 12MB/s due to bus restrictions or whatever. While the real problem is that wrong default settings used with most of the available OS Images prevent higher numbers. Here it's software (settings) that matter, in your case it's a hardware issue. I just wanted to point out (obviously to no avail again) that it's necessary to look for bottlenecks individually since otherwise you have no clue why network performance sucks if network performance sucks
  

Anyway, useless to continue. TL Lim seems to be able to identify the issue now, maybe all affected boards get replaced, maybe new boards are tested before they're sent out, maybe broken OS images will be fixed, maybe this micro community will be able to dismantle from this strange micro reality

[MarkHaysHarris777]

I now have cpufrequtils installed on my debian and ubuntu servers ; the debian unit has a real hdmi display and has been my primary desktop workstation most of the summer.  The ubuntu server is housed in the ABS box from Radio Shack and is being used as a headless server; I am accessing its desktop via VNC on my iMac. The debian does work ( GbE ) and the ubuntu does not work ( GbE ) but is connected via the same switch with the modified cable-- clicking along great at 100mb/s.

On irc today longsleep indicates that his kernel switches from 'ondemand' to 'interactive' automatically after 30 seconds. I found that this is not true ( not on my machines ) and that cpufreq-info shows 'ondemand' for both systems by default. 

Its very hard on my working system to get consistent results ; one iperf run will get speeds in the mid 300s to high 300s one time, and will get high 200s to low 300s the next... without changing anything; however, I can confirm, after running iperf many times with each governor, that the speeds on average are somewhat higher with the 'interactive' governor. Its not dramatic, but more often than not the speeds were in the higher 300s to lower 400s with the 'interactive' governor; and typically on average in the mid  300s to lower 300s with the 'ondemand' governor.  

marcus

[amc2012]

For anyone using Armbian, there appears to be a huge update today, including some pine64 specific modules. Wonder if any of it affects some of the things being discussed here?

[tkaiser]

For anyone using Armbian, there appears to be a huge update today, including some pine64 specific modules. Wonder if any of it affects some of the things being discussed here?

Nope, why should it?

The problems discussed here are a hardware problem and a 'community' problem. Everything any of the Armbian team members did for/with Pine64+ in the past went back to linux-sunxi community immediately and has been incorporated by longsleep in his source trees (whether this has been picked up by the various distro bakers is unfortunately another question).

The huge Armbian update to 5.20 affects many of the boards we support (especially the Allwinner based, Pine64 explicitly not since so much moronic 'the Mali' hype has been generated here). I fear even the little bug concerning wrong temperature readouts has not been fixed (can't test right now since no boards available).

Regarding Pine64/Pine64+ nothing has changed since months. We still use those settings that work best.