(09-14-2016, 12:11 PM)tkaiser Wrote: Anyway, there are a few more use cases where Pine64+'s GbE implementation can shine, for example running the boards without local storage at all (rootfs on NFS, maybe booting through FEL -- a pretty cool feature of all Allwinner boards). This is also something I wanted to test out (NFS and general network tunables) but no Pine64+ left to test with and fortunately two Pine64+ are on it's way (thanks TL Lim!).

(09-14-2016, 12:48 PM)amc2012 Wrote: Good luck with the new ones. My replacement also had the GbE issue. Manufacture date was a couple days away from my kickstarter board. I will say the chip soldering on this one looks MUCH better than the first board I received, even though it was made only a couple days later.

(09-14-2016, 03:36 PM)tkaiser Wrote:

(09-14-2016, 12:48 PM)amc2012 Wrote: Good luck with the new ones. My replacement also had the GbE issue. Manufacture date was a couple days away from my kickstarter board. I will say the chip soldering on this one looks MUCH better than the first board I received, even though it was made only a couple days later.

Well, to me it seems Pine64 folks were not able to identify the whole issue until recently (TL Lim reacted last friday on my 'stab in the dark' tests with different PSUs, @androsch's board arrived the day before). Then the whole Pine64 community here (and over at pine64.pro and in this private IRC chat at irc.pine64.xyz) suffers from OS images shipping with wrong default settings and many people might really believe that it simply makes no difference whether they're using GbE or Fast Ethernet with Pine64+, see the laughable Samba performance when using OS images from pine64.pro: http://forum.pine64.org/showthread.php?tid=1084&pid=19012#pid19012

I would believe a few things have changed in the meantime and I really hope that it's understood now how wrong settings influence (not only) network and storage performance (both real world and synthetic benchmarks).

If anyone still uses these bad OS images, installing/adjusting cpufrequtils and switching to 'interactive' governor should already help (same with 'same MAC address', that's only a problem with OS images from pine64.pro or the wiki). So Pine64 folks are now able to reliably test for the issue before they send out replacement boards using an OS image with sane default settings, checking against a GbE enabled other device that is known to exceed 900 Mbits/sec and if it's above 800 Mbits/sec it's fine. I would assume that was different just days before.

So lets hope for the best. My main concern currently is that a specific person that censored here everything away might start with that after remaining calm for a while! It's ok if users spread confusion but it's not ok if the same person is enabled to prevent being corrected since he can misuse his moderator status to censor posts and ban users!

(09-14-2016, 04:34 PM)waldo Wrote: @tkaiser: What image do you suggest/promote ? Linky-link pls ?

(09-14-2016, 09:36 AM)tkaiser Wrote:

(09-13-2016, 11:16 AM)amc2012 Wrote: Any inference that the onboard GbE would be worse that what I'm getting on GbE over USB I'd imagine have to be incorrect, so while I understand I won't get *full* typical GbE speeds once the onboard port is working, I am looking forward to the significant boost over Fast Ethernet. It's the whole reason I was a backer of this project.

Why shouldn't you get 'full' typical GbE speeds? With longsleep's original Xenial image or Armbian and without any tuning you get already above 900 MBits/sec using synthetic CPU bound benchmarks (but unfortunately you can forget about those numbers when using most 'featured' OS images from pine64.pro or the wiki since they use wrong settings). When tuning for more throughput (which is not always desirable, sometimes you want to tune for lower latency) you will reach the typical 940 Mbits/sec barrier.

On the other hand USB throughput is rather limited, with good settings and BSP kernel you might get 35 MB/s, with mainline kernel and UASP capable disk enclosures you might get close to 40 MB/s. I already prepared a test with RAID-0 and two rather fast SSDs to demonstrate that with modern filesystems (btrfs on Linux and ZFS on FreeBSD) we're able to push the envelope and max out onboard Gigabit Ethernet on the Pine64+ in NAS mode. Jared McNeill who did the FreeBSD port for Pine64 discovered that we can turn the upper USB port normally being an USB OTG port into a full USB host port using an own USB PHY. Linux mainline kernel guys (in this case a girl  ) will implement exactly that too.

So when using modern filesystems with transparent file compression (a reasonable setting on Pine64+ since there's enough CPU horsepower available to trade in some CPU cycles for smaller filesizes and also higher IO throughput at the same time!) I'm pretty confident we'll be able to use Pine64+ as NAS with client-server performance close to or even exceeding 80 MB/s (through the network, including disk access).

Only problem: TL Lim sent 4 Pine64+ dev samples to me back in Jan/Feb, 2 arrived. The first is now at Mikhail's place (that's the guy who did Armbian porting to Pine64 and he's also responsible that we're at kernel version 3.10.102 now and not still at 3.10.65 -- think about countless bugs and security flaws that have been fixed), the second one at @androsch (that's the guy responsible for us finally making some progress identifying the GbE issue). So while both boards serve pretty well I've nothing to play with now. I hope @androsch forwards my request to TL Lim to send another dev sample(s) to provide some nice NAS benchmark numbers.

Given we're able to use both USB ports as true host ports and given the low price Pine64+ is a real bargain for low-end NAS use cases, virtualization (it's ARMv8!), clustering, whatever 

(09-13-2016, 06:06 PM)tllim Wrote: Actually on this case, the filter may be the one that causing this issue.

(09-14-2016, 10:37 AM)tkaiser Wrote:

(09-14-2016, 10:06 AM)amc2012 Wrote: someone on this forum said that due to bus speeds or something on these small board computers that I shouldn't expect to get GbE speeds and that Fast Ethernet is pretty close to the max I can expect? I guess that's not true?

Of course that's not true. At least for A64 used on Pine64+. GbE is connected through RGMII, both USB ports have an own PHY, memory bandwidth is high enough, CPU horsepower is high enough, the ONLY problem are shitty default settings on most of the OS images available for Pine64+. 

• wrong cpufreq governor as explained countless times, also how to fix this several times here
  
• silly mistakes like MAC address already set (that's just the result of people fiddling around and forgetting to adjust stuff before they release an image. And that's the reason why Armbian uses only script to create OS images from scratch: since such mistakes can not happen)
  

(09-15-2016, 12:01 AM)tkaiser Wrote: <snip>  

Most available OS images for Pine64+ show bad network behaviour/performance due to two single reasons:

• wrong cpufreq governor as explained countless times, also how to fix this several times here
  
• silly mistakes like MAC address already set (that's just the result of people fiddling around and forgetting to adjust stuff before they release an image. And that's the reason why Armbian uses only script to create OS images from scratch: since such mistakes can not happen)