PINE64

My home network consist of 3 > 8 port and 2 > 5 port switches, all gigabit with mostly cat 6 and a few 5e cables. I avoid WiFi on my stationary devices. For me Ethernet not working on Android and Remix OS is a killer.

(08-15-2016, 05:23 PM)androsch Wrote: [ -> ]

(08-15-2016, 03:01 PM)amc2012 Wrote: [ -> ]

(08-15-2016, 02:44 PM)yusijs Wrote: [ -> ]Yes. It seems very much like an issue with auto neg. Basically I set it to force 1000m Full Duplex on that port. If I didnt set anything, I got 0.2-1 mbps at best. This was on ubuntu, pretty sure it's the same for android though.

This is the most helpful/hopeful thing anyone has suggested so far. I now have a 5-port managed switch coming Saturday. Guess it makes sense it would be an auto-negotiate issue. If so, I still have hopes there is some kind of firmware fix that could happen for our boards. But this is a reasonable workaround if it works. Will report back this weekend. 

Cheers.

Would be very interesting to get those results. As you maybe know, i sent my board to longsleep and it worked fine in his environment, but i could not get it to stable GbE with all 4 of my routers and switches and some of them are pretty new (Fritzbox 7490 e.g.). So if you get it running with a new switch also, would be very interested in the type of switch also....

Good luck

Ah yes, I thought it was waldo that sent in to longsleep. Sorry. None of your switches are managed? Does the Fritzbox allow you to set the speed of any of the ports? Some routers do.

Yes, two routers allow to set their port speed, but only the speed, no fixed setup including negotiation or duplex mode. My switches are auto-managed, so i'm keen to see the effect of a managed port.....

Gesendet von meinem XT1032 mit Tapatalk

(08-15-2016, 03:35 PM)MarkHaysHarris777 Wrote: [ -> ]

(08-15-2016, 02:20 PM)amc2012 Wrote: [ -> ]Not sure what you mean by GbE being "too new." Having been around for the better part of two decades, and having been RAPIDLY deployed even when it first emerged, GbE is actually one of the more mature ethernet technologies out there. Check out the Ethernet Alliance Roadmap. I work in IT, and we've been relying on GbE for a long long time now. I think it's probably safe to say that the Cisco and Netgear routers I use at home have "figured it out."  I have *never* run into any kind of issue like this in my home or work environment. 

I have never run a GbE network at home;  most people have not.  My entire network is 10/100 as are most people's home networks; why--?  Because once a network is setup (mine years and years ago) why setup another one.  All of my devices are 100 now. None of my devices are GbE. 

it takes a full twenty-five years to fully adopt a new technology to the 'common place' status. GbE is not there yet. And, as you can see not only by the varying opinions on the subject but also by the varying status reports, GbE is not the standard some of you have been hoping it would be. 

This issue seems to be a 'tolerance' timing environment specific problem that can be resolved with the right hardware and configuration. There have been some recent developments in that direction.  I hope your situation may be corrected also. Obviously packets are going to be lost and through-put is going to be low if auto negotiation occurs every couple of seconds. 

Best of luck to you.

Mark, as a network professional i can't let this go; in the past years we've actually gone to 5Gb over copper (5GBASE-T) ... so the 1GbE over copper standard is perfectly described and implemented on all my swicthes for the past 10 years at least.
If it took 25 years to get to commonplace status, we'd probably be using thick coax in our datacenters instead of fibre, so i call BS

Please stop the BS on the GbE issue, This is not an issue where the standard is to blame , this is something the PINE64+ is to blame for.
"GbE is not the standard some of you have been hoping it would be." => thats odd, it seems to be a perfect standard ; except for the PINE :S

Also remember that I have one Pine that does good GbE and one that has the issue; so you can't just put blame on the environment. (same sd card, power supply, eth cable, switch)

All fine and dandy that someone has swapped switch and it works for him now; but I'm not planning on swapping out a perfectly good Cisco Catalyst that performs PERFECT for ALL other devices.

Once again , this needs to be resolved, if necessary the boards need to be swapped.
Hoping to see some official response to this ....

---

(06-10-2016, 11:12 AM)longsleep Wrote: [ -> ]I received the board from , plugged it in, tested - works fine.

iperf2 pine64 is server

Code:

root@pine64:~# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.29 port 5001 connected with 192.168.1.232 port 40359
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   320 MBytes   267 Mbits/sec

iperf2 pine64 is client

Code:

root@pine64:~# iperf -c 192.168.1.232
------------------------------------------------------------
Client connecting to 192.168.1.232, TCP port 5001
TCP window size: 22.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.29 port 39981 connected with 192.168.1.232 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   813 MBytes   682 Mbits/sec

So no problem of the board itself and this is probably true for all the other non working 1000M reports here. The reason is something else / external to the Pine64. The switch, the cable, the psu, and a combination of those together with the Pine64. So its up to you folks which have the issue to find out what triggers it (start by replacing the switch).

Just as an FYI; IPERF is NOT a good test ; 
http://forum.pine64.org/showthread.php?t...7#pid17197

There are a bunch of files attached to this post, check how iperf says that it got perfect speeds while a wget is failing miserably ....

I am confidant, it is the software for the lack of Ethernet on this board and not hardware, because it works with Linux but not Android or Remix OS. I ran into the same problem two or three years ago with one of my Android boxes ( I now have about 2 dozen different Android boxes now). I replaced a new 100 ft. Cat 5e with a cat 6, that did not help, replace a 5 port Ethernet switch, that did not help. Not sure if I replaced the router, but anyway after awhile, they came out with a firmware revision, and the problem went away.

So, we are at the same point with Ethernet that I was at with one of my Android boxes 2 or 3 years ago. Someone just to accept responsibility for getting the correct Android drivers and embed them into the OS.

(08-16-2016, 08:09 AM)MarkHaysHarris777 Wrote: [ -> ],

I too am an IT professional for almost 30 years with IBM. I am fluent in over twenty-five software engineering languages, and I am a networking expert and specialist (professionally and as a hobby). You do not have to agree with me, but I would appreciate it if you would be respectful and considerate;  my opinions are not 'BS' and they are no less valid than your own.

We are not talking about a 48 port $2,860.00 Cisco N2K-C2248TP-1GE router !  We are talking about a $29 SBC running codes written by volunteers, hoping them to be helpful and useful, providing not one iota of warranty or promises for suitability for a particular purpose.

Many of these boards are running around the world satisfactorily. Several of these boards are working NOW that were previously NOT working by making adjustments to the environment. This is a fact, not an opinion, and it is a fact, not BS.

Many of us volunteers are in the process of getting to the bottom of this;  we are not getting paid for it, and we do not deserve to be abused for it either.  I am sorry that your expectations have not been met, and I certainly regret that you are not a happy Pinester. But as a moderator on this forum I am asking that your comments be respectful, and that you check ad hominem attacks at the door. Try to put this problem in perspective, and try to maintain a decorum which not only respects all users of this forum, but which is conducive for motivating volunteers to continue to work on this problem.

Thank you for your consideration.

Mark ... the N2K-C2248TP-1GE  is a switch , not even that ....its a fabric extender that nees a nexus 5000 or 7000 to be its babysitter ... so lets ignore your attack on me now 


The fact this is about cheap boards doesn't matter Gigabit is gigabit ... moreso my odroid that is in the same priceclass is also capabnle of doing it just fine.
The fact that you as a moderator feel this comment was derogatory shows, i think you have quite short fuse .... also don't forget this is not my mother tongue so nuances might get lost.

What i said was BS was your statement on gigabit still being in a stage where products are in some 'draft' standard mode that's not fully compatible yet ....
...GbE over copper was ratified in 1999 .... we're 17 years later ...... therefore i think yr statement qualifies as *hogwash*


edit : could you please explain how 2 boards react differently in the same environment, if I shouldn't blame the boards ?

hi folks, after discussing this at length with Waldo, and others, on the irc channel I realize that I need to make a clarification of my statement about 'newness' of GbE.

I did not mean in any way that the technology is NEW. ( I know full well that its been available for some years ).

I did mean that most people are not using it; and by most people I mean that most 'people with pine boards' are not using GbE, and that most 'common people' on the Internet are not connecting to the Internet with GbE either. GbE is not a common Internet standard used by most people. We have 38,000 of these Pine64 boards in the wild and very few are reporting the GbE problem. Almost all of my machines connect with wifi, and most people connecting on the Internet are connecting via wifi.

I hope this clarification helps, in some way. My primary focus, in terms of this project, is to help diagnose this problem (if possible) and help get people who need it running with GbE. Several of us are genuinely trying to help. My intent is not to minimalize the problem, just to put the problem in perspective so that everyone is focusing on a solution rather than focusing on an attack. Again, we are all either part of the solution, or we become part of the problem.

(08-16-2016, 12:08 PM)MarkHaysHarris777 Wrote: [ -> ]I did mean that most people are not using it; and by most people I mean that most 'people with pine boards' are not using GbE, and that most 'common people' on the Internet are not connecting to the Internet with GbE either. GbE is not a common Internet standard used by most people.  We have 38,000 of these Pine64 boards in the wild and very few are reporting the GbE problem. Almost all of my machines connect with wifi, and most people connecting on the Internet are connecting via wifi.

I'd still be careful about making even that statement, Mark. If you mean most people with pine boards aren't using the ethernet period.... then there is a fair chance of that, depending on how many also bought the integrated wifi, and how many are using USB wifi adapters. It might be a good point to remind that (as stated on the kickstarter campaign page) that the Pine A64+ is the only one that supports GbE - the Pine64 (BASIC) only supports 10/100 Mbps ethernet. So that is another factor that could be considered. However, if you mean people with ethernet not using GbE... that is a curly one at best. Consumer grade GbE stuff has been been mainstream for several years now.

As an example, the 2010 mainboard on my desktop (which wasn't a particularly fancy or expensive one) natively supports GbE. The network switch I purchased a year or so later also supports this, as does my router. So theoretically, although my internet connection is only about 15Mbps on a good day, my network backbone is several orders of magnitude faster, which is really handy for high speed file transfers between systems. So does does the Cubietruck SoC board I bought about 2 years ago. However, that was about 4x more expensive than the pine64 :-D (And can I say that since I use if as a network file share / video streaming box, the 4x+ transfer speed increase of the GbE is well appreciated!)

However, that is beside the point. I haven't been following this thread, but I do believe that if the pine64 was promoted and advertised as supporting GbE, it should have worked out of the box with at least one of the official OS images. If that has not been the case, I see that as a failing on the part of the pine64 team, NOT the volunteers (us) on the forum. We can't be expected to know how to fix that and get it working. Heck, it has only been due to longsleeps efforts that the linux images have progressed as much as they have (and  I hope Simon has gotten some freebies / compensation / thanks for his efforts on that).

However, I suspect I digress from the OT, and I apologise for that. However, I felt a nudge redirecting the perceived (ir)relevance of GbE was needed. If people paid for this board with the intention to use the ethernet as GbE and it's not working, then it isn't fit for purpose or as advertised. If this were a retail store, you would be well within your rights to demand a refund. However, as this was a kickstarter campaign, then baring a DOA item, it will probably just take a little time for the dust to settle. I think they overcommitted - it should have been a capped campaign, but that is for another thread

hi pfeerick,  there is another way to look at this issue, as well. 

... and that is the legal way to look at it from the standpoint of the agreement on the back of every cardboard box that the PineA64 board is shipped in. 

Most of the comments made in this thread so far about the obligation of Pine, with respect to performance or suitability for a particular purpose, are mute-- legally. Every single PineA64 board was shipped in a cardboard box that served not only as its mail wrapper, but also as its EULA. Opening that box obligated the user (the customer) to certain agreements which are detailed in some very intense fine print. 

I quote in part, "... the products are provided on an 'as is' basis. The entire risk as to quality, and performance of the products is with customer, and customer assumes the cost of any servicing, repair, or replacement of the products. Whether implied, express, or statutory, including the implied warranties or conditions of mechantability, fitness for a particular purpose, title, and noninfringment or third party rights. Pine64 Inc. does not warrant that the products are error free, or will function without interruption."

The very specific and intense EULA fills the entire back panel of the shipping box of every PineA64.

The claims being made by most of the participants of this thread demanding redress of grievances for non performance of GbE are outside the legal scope of liability of Pine Inc. --- which brings things full circle back to we the volunteers who are attempting to help fix this problem. We are going to get to the bottom of it -- but, in no way has the Pine Inc been culpable of malfeasance of any kind, and in no way are they culpable of breach of contract (whether tort or otherwise) and all such claims that Pine Inc failed to provide the product suitable for any particular purpose is void. Anyone who removed their PineA64 board from the packaging material and breaking the seal on the EULA should have been aware of that fact, or should have returned the product without breaking the seal.

---

Again, I am asking for everyone to engage in some common sense cooperation and collaboration.  It would be much better for us (mostly volunteers and users) to work together to solve this issue, than to beat-up Pine Inc, or engage in silly flame-war attacks on each other.  I'm not the enemy;  I'm trying to help.  Let's work together and lets get this figured out. But let's do it in a civil polite manner that is respectful and conducive to cooperation and effective collaboration; that's all I'm asking.