LAN/NIC problem

[tkaiser]

We are looking onto three areas, VDD33, AVDD33, and VDD10

You might want to look into this as well: http://forum.armbian.com/index.php/topic...s/?p=15472

When you receive @androsch's board please also have a look at the voltage drops between DC-IN and USB ports. When powering through Euler pins with 4.97V and jumper in DC5V setting only 4.6V on the USB ports look 'wrong': http://forum.armbian.com/index.php/topic...s/?p=15173

[cdslashetc]

I haven't done enough serious electronics in years to justify buying a big variable DC power supply, but ordered an adjustable DC-DC converter planning to feed with a bundle of alkaline batteries for experimentation, hopefully will give reasonably clean power should at least be cleaner than AC-DC.

https://www.amazon.com/gp/aw/d/B01CE5P33...UTF8&psc=1

Sent from my Nexus 6 using Tapatalk

[jandvs]

I sent my pine home with my friend.  Visually, the Pine 64's are identical. They both are Pine64+ 2GB.  He compared HIS to MINE using a couple of different cables long with his sdcard (debian) and mine (ubuntu). Packet loss was determined by pinging google.com (also tried yahoo.com and bing.com with similar results as below).

Pine 64 - HIS
50ft Cat 6 -ubuntu card, no packet loss
50ft Cat 6-debian card, no packet loss
6in Cat 6-ubuntu card, no packet loss
6in Cat 6-debian card, no packet loss


Pine 64 - MINE
50ft Cat 6 -ubuntu card, packet loss (10-28%)
50ft Cat 6-debian card, packet loss(15-28%)
6in Cat 6-ubuntu card, packet loss(8-21%)
6in Cat 6-debian card, packet loss(11-24%)

So this eliminates my "network enviornment" and isolates my pine64 in a known good environment to have a hardware issue.

One more point to clarify on this comparison, he used his Pine64 power supply and mine still showed the issue like when I use my Pine64 power supply.  I'm not saying the power supplies that came with the pine are clean, but the same power supply works on his, but doesn't help the Gbe issue on mine.  I've also tried powering mine from the USB port of my TV/Monitor.  I have no idea what amperage it supplies or how clean it is, but I had the same results.  I have not tried any other power sources.  I don't have scope, so I can't really monitor fluctuations.

[tkaiser]

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 

[amc2012]

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.

Oh, I don't know, because 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?

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.

With the stock PINE images, I was getting around 30MB/s FROM the PINE over the USB GbE and about 9-10MB/s TO the PINE. Moving to Armbian netted about 33MB/s down and an improvement to about 18MB/s up.

On my home network, other machines can get around 90MB/s, sometimes a little more when transferring from NAS to machine.

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

I'd be totally jazzed to see those kinds of speeds on my PINE.

[MarkHaysHarris777]

I'd be totally jazzed to see those kinds of speeds on my PINE.

I'll be totaly jazzed when all three of my boards just work...

[androsch]

I hope @androsch forwards my request to TL Lim to send another dev sample(s) to provide some nice NAS benchmark numbers.

Done.

Gesendet von meinem XT1032 mit Tapatalk

[tkaiser]

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+. And the limiting factor here is USB 2.0 of course (keep that in mind when dealing with USB Ethernet dongles, the best you can get is maybe 300 Mbits/sec when using RTL8153 based dongles for ~$7.50) since network is faster than any single disk access.

Other platforms suffer from bus limitations (eg. all Raspberries which only have one single USB2 OTG port to the outside) or i.MX6 where the SoCs GbE maxes out at ~400 Mbits/sec (so while you can access disks with ~100 MB/s there you can't benefit that much from with NAS use cases). But with more recent Allwinner SoC's that's not the case. GbE with A64, H3 or A83T/H8 (all SoCs use almost identical implementation) is able to use full bandwidth. At Armbian we even support ARM devices using just a dual-core ARMv7 SoC being able to max out 3 SATA 3.0 lines in parallel while maxing out a few GbE connections: http://forum.armbian.com/index.php/topic...s/?p=15265

This won't be possible with A64 but since we already know from H3 devices running mainline kernel what's possible there (maxing out all 4 USB 2.0 ports there while also maxing out GbE -- H3 is just like A64 just with less USB ports and Cortex-A7 cores instead of Cortex-A53 as on Pine64+) 80 MB/s look realistic with a rather unrealistic RAID-0 implementation.

[cdslashetc]

My original plan in getting 5x Pine64 was to play around with Gluster and maybe Tahoe LAFS. Streaming data from multiple boards simultaneously should be able to produce higher throughput than a single board.

Sent from my Nexus 6 using Tapatalk

[tkaiser]

My original plan in getting 5x Pine64 was to play around with Gluster and maybe Tahoe LAFS.

Well, if it's just about playing around then such storage cluster setups are nice. But anyone trying this out should keep in mind that the added redundancy with more cluster nodes is pretty useless unless all nodes use ECC memory (which is not the case here and with any other affordable ARM board out there). We should also keep in mind that no one so far tested DRAM reliability for Pine64+ so maybe the 672 MHz used are too high (when we -- linux-sunxi community -- did that for H3 devices we had to realize that the 672 MHz there don't work on all boards which is why we at Armbian chose to use 624 MHz on all H3 devices).

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

Since we're already at it (netbooting), my wishlist for a new Pine64+ PCB revision:

• a small SPI NOR flash on board (to store at least u-boot and to be able to run then from USB storage or network)
  
• 1 or better 2 additional custom leds (able to be used for feedback which will greatly increase user experience and reduce false 'DOA' cases)
  
• a barrel jack (preferably 4.0/1.7mm) instead of Micro USB for DC-IN