LAN/NIC problem

[amc2012]

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!).

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.

[tkaiser]

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?t...2#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!

[waldo]

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?t...2#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!

@amc2012 thanks for confirming that ; holding off for a while longer then :S
@tkaiser: What image do you suggest/promote ? Linky-link pls ?

[tkaiser]

@tkaiser: What image do you suggest/promote ? Linky-link pls ?

Either longsleep's original Xenial image or Armbian legacy. Armbian is not a distro but a build system. If choosing Armbian I would also prefer our Xenial legacy build (better 'benchmark performance' compared to Jessie -- just check the link on the download page, everything explained in Armbian forum) and I would also wait 24 hours (Igor, our lead, is currently rebuilding images for the +40 SBC we support and I hope one small issue will also be fixed tomorrow).

We currently provide no GUI images to prevent the poor souls infected by the moronic 'the Mali' hype flooding our forum (but of course all GUI stuff including 2D and video acceleration would work when using our build system, you could also add longsleep's PPA to our Xenial build of course and install a desktop environment then).

[tllim]

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 

@androsh already contact me and three Pine A64+ 2GB board will ship out to you on Sunday after Shipping Facility back from the 3 days China holidays.

[stepw]

Actually on this case, the filter may be the one that causing this issue.

Which one? 3.3V PMIC or 1V regulator on the PHY?

[MarkHaysHarris777]

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+. 

Of course it is true.  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. 

Tom's continued bashing of the official pine64.pro images for the PineA64 are inaccurate and unfair ( it goes back to an old vendetta between Tom and Lenny, and should just stop ). 

The default settings for most situations and for allmost all use cases are just fine. Inappropriate and profane adjectives describing the default settings are not called for and are for the most part not helpful. To their credit longsleep and lennyraposo have created wonderful images that are both robust and stable ( something difficult to accomplish for most people ) and by and away they have shown to be very high quality having little or no quality issues-- Tom's opinion as a 'database' boy not withstanding. If he wants to use armbian that's ok, but the continued haranging about Lenny's images is getting old.

I think before we can talk about how fast these little boards can go, we should first make them just go-- something many of them are not capable of doing period !

[tkaiser]

It gets boring and while it's great that you don't do what you're usually doing (deleting/censoring stuff you don't get) you again spread only confusion.

I explained several times in detail why ondemand governor used on most 'featured' OS images is bad for performance. It's easy to test this out, you just have to get into details and do it. @pfreerick did exactly that, provided comparison numbers and even you were able to realize the difference between 9 MB/s and 29 MB/s? In his case he was bottlenecked by his USB 2.0 storage setup, with a better setup more is possible.

Then: I'm speaking here for experiences made by two far more broader communities: linux-sunxi and Armbian. Two years ago with devices based on old/boring dual core A20 SoC we were already able to get 44/72 MB/s in full NAS mode: http://linux-sunxi.org/Sunxi_devices_as_...erformance  (but only with correct settings, baking a good OS image is not just throwing together u-boot, kernel and a rootfs found somewhere on the net but adjusting all settings accordingly. And BTW: that's the whole purpose of Armbian, the project started for exactly that reason)

A20 has a SATA write limitation and a GbE read limitation (A20 is dual-core ARMv7), A64 has balanced USB2.0 performance and no GbE limitation (and is quad-core and ARMv8 and contains new IP blocks for networking showing no limitation any more). A64 is just like H3 but more beefy and we tested H3 devices as NAS extensively. Everything is already known, if TL Lim sends out working boards I provide soon numbers. But hey, why? It gets so easy if you start to understand that Pine64 is based on an Allwinner SoC and that experiences with these devices do already exist: http://linux-sunxi.org

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)
  

Anyway, it has been a huge waste of time to explain to one single guy that Pine64 is able to benefit from GbE and really can make use of it. And that was only to avoid getting censored by you if other people make true claims. And it's still a waste of time to answer you since you still don't get what you don't get. For this background it's a real shame that you're still enabled to act as a censor since you will start again with that. Why are you still a moderator? It's a shame.

The pine64.pro site was a joke from the beginning, collecting outdated OS images with wrong settings, empty FAQ and info pages for months, a so called bug tracker that does nothing and where people are able to report hardware issues as Linux kernel bugs (and no one cares about any of these 'reports' or assigns them to a developer or does anything useful with it, only confusion and the feeling for Pine64 noobies that 'something's happening there'). Unfortunately pine64.pro maintainer suffers from the same problem as you.

[pfeerick]

I wouldn't have put it quite so bluntly as tkasier did, but I do agree that things have stagnated on the pine64.pro front... and I haven't seen Lenny around on the forums of late, so I suspect it is suffering very much from 'one man band' limitations and unfortunate things like life getting in the way as it does.

I do agree that a scripted automation system like armbian is needed, as it removes the need to remember if you configured this or configured that, and did you change this... it will always come out the same every time. And we all know that documentation has not been a strong point of this project.

So, instead of going around and around in a vicious cycle of lack of documentation, and poorly developed stuff, why don't we use already existing tools instead of re-inventing stuff. Bug trackers already exist online, and are even free... so why make a new one... sure, it's fun to make and say we've done it... but I'm sure we can put our time to better use. So, can we do something with github? Maybe by opening a new repo so we can pull together scripts to do things on the pine64 and also maybe make use of the wiki & github.io hosting there... Then we can track issues in a standardised manner, allow editing to resources, and perhaps even use the github.io to compile release documentation and known issues.

[MarkHaysHarris777]

<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)
  

Tom, the above is actually useful.

... I too stongly believe that the best way to build an image is with scripting;  not by hand.  And it has been clear from past experience that some of our problems (minor though they were) were the result of building images by hand. 

We need to have a well defined build process, and it needs to be automated (scripted) so that things are not forgotten nor misplaced. Also, although lennyraposo has been an extremely valuable resource, this needs to be more than a one-man-show.  We need capable backups, and I agree with Pete, this needs to be moved to github so that we can have offical pull requests, submit issues, and so that more than one person (developer team) can be involved with the process. Just makes sense.

It would be helpful if you would try to be less blunt, and a little more tactful in your remarks.  For my part I'm going to be less easily irritated, and perhaps we'll be able to work together and be friends in the process-- I'm certainly willing. 

just as a side-bar;  we put the rules in place so that the moderators ( and especially me ) don't have to baby-sit the forum ... the bottom line of the rules is basically be respectful, be helpful, work together to solve common problems, and try to forget negative commentary. That's the direction I'm going to move forward in, as a technician and as a moderator.  

sincerely, marcus