Ethernet Slow Download

[waldo]

The only FREE solution. I bought V.TOP gigabit USB adapter for $13.99.

Sent from my Nexus 6 using Tapatalk

Bought and free is a bit weird... 
And usb2 tops out at 480mbits.... That and probably some overhead and a lot of usb jitter. 

Lets not waste time on discussions about usb adapters or 100mbit.... 
This just needs to get solved,... 
... My hope atm is on the 'master' phy thing... 
... Otherwise it might be time to accept a HW issue... 

Ps also check olimex's try at an a64 board,  they delayed theirs because of issues with GbE and the realtek phy

Amen, waldo.

I really do apologize for being snippy, but this is exactly the case - those who have the faulty boards already are either using Gig USB to get at least a small boost, or are using the workaround of ethtool to fast ethernet speeds. 

My patience with this issue just wore thin today.

I had one working and one faulty board in the same environment, played around alot with the rx tx settings, lets wait for the master phy thing to be patched in,... 

Heres olimexes explanation for their delay https://www.olimex.com/forum/index.php?topic=5365.0

Which... Umm...   predicts interesting times

[cdslashetc]

With the PocketEthernet, I identified some cables getting 1% BER (Bit Error Rate) at 1000 Mb/s, but that was having minimal impact, although I did make sure I didn't use those cables for further testing. The flat CAT7 cable that I got seemed to have the best characteristics.

On the connection, blue and orange pairs are solid, but I am often seeing open on brown and sometimes on green, and frequently some interference on green which is interesting. I'm going to see if I can find Charles Spurgeon's excellent Ethernet website and see if it has more specific information on the role of the different pairs. I do know that only 2 pairs are used for negotiation, so a gigabit connection may be negotiated even if there's a problem with using gigabit on the other 2 pairs.

[androsch]

They do not affect what you correctly state has to be a hardware issue. I saw the post about how a specific chip was sourced from another location to try to get the orders out, but I also saw the one where someone was able to identify they had two boards with the SAME sourced chip and one worked and the other didn't. 

It seems this may be a manufacturing issue at this point that's triggered by something in the environment. Someone else sent in their board to longsleep and it worked fine in that environment.

I'm the one who sent his board to longsleep and it was fine there, but i'm still checking out with him, whether this was a iperf vs. iperf3 issue. My board reports  now also in my environment with iperf at about 300 mbits, thats similar to longsleep, but iperf3 only shows about 2-20 mbits, so this is still bad and the board is very laggy on GbE mode.
Will have my board checked deeper by tkaiser and we will report back in this forum also, even when he left resp. was forced to leave.

Edit (09/05): Got reply from longsleep, he also used iperf3 and iperf for testing, both worked fine, so really interested in tkaisers tests in the next week with my board....

Gesendet von meinem XT1032 mit Tapatalk

[tllim]

They do not affect what you correctly state has to be a hardware issue. I saw the post about how a specific chip was sourced from another location to try to get the orders out, but I also saw the one where someone was able to identify they had two boards with the SAME sourced chip and one worked and the other didn't. 

It seems this may be a manufacturing issue at this point that's triggered by something in the environment. Someone else sent in their board to longsleep and it worked fine in that environment.

I'm the one who sent his board to longsleep and it was fine there, but i'm still checking out with him, whether this was a iperf vs. iperf3 issue. My board reports  now also in my environment with iperf at about 300 mbits, thats similar to longsleep, but iperf3 only shows about 2-20 mbits, so this is still bad and the board is very laggy on GbE mode.
Will have my board checked deeper by tkaiser and we will report back in this forum also, even when he left resp. was forced to leave.

Edit (09/05): Got reply from longsleep, he also used iperf3 and iperf for testing, both worked fine, so really interested in tkaisers tests in the next week with my board....

Gesendet von meinem XT1032 mit Tapatalk

I have deep interest on the GbE finding.

[androsch]

They do not affect what you correctly state has to be a hardware issue. I saw the post about how a specific chip was sourced from another location to try to get the orders out, but I also saw the one where someone was able to identify they had two boards with the SAME sourced chip and one worked and the other didn't. 

It seems this may be a manufacturing issue at this point that's triggered by something in the environment. Someone else sent in their board to longsleep and it worked fine in that environment.

I'm the one who sent his board to longsleep and it was fine there, but i'm still checking out with him, whether this was a iperf vs. iperf3 issue. My board reports  now also in my environment with iperf at about 300 mbits, thats similar to longsleep, but iperf3 only shows about 2-20 mbits, so this is still bad and the board is very laggy on GbE mode.
Will have my board checked deeper by tkaiser and we will report back in this forum also, even when he left resp. was forced to leave.

Edit (09/05): Got reply from longsleep, he also used iperf3 and iperf for testing, both worked fine, so really interested in tkaisers tests in the next week with my board....

Gesendet von meinem XT1032 mit Tapatalk

I have deep interest on the GbE finding.

Some results from tkaiser in the armbian forum with my board:

Armbian running on Pine

Maybe there are some guys also here in pine forum able to check some of the figures and suggestions he made?

Will at least have a look for an external power unit via Euler bus asap....

[MarkHaysHarris777]

tkaiser is correct about one thing, and one thing only related to this discussion, the micro-usb connector is insufficient for providing power to the Pine board.

... the micro-usb connector is insufficient for power to the Pine boards, and its insufficient for power to the PI(s)...  this has been proven empirically.

Everything else he has said about this problem is incorrect. All of my boards are powered from the bus, not via the micro-usb connector.  Also, all of my boards have more than adequate power supplies;  one of my boards works flawlessly (GbE), the other one (GbE) does not work at all.  Both boards work flawlessly at 100mb/s.   (this is NOT a software problem, and this is NOT an environment problem, nor is this a power problem)

The situation is NOT related to power.  The only power related observation I have so far is that if my working board is run from battery ( because the DC IN is very clean ) the speeds go up slightly.  This does not affect the non working GbE board at all )

To prove that tkaiser does not have a clue what he is talking about--- all you have to do is have everyone on the POLL list that reports having a non functioning GbE board power their Pines from the euler bus... if it fixes all boards (including mine) then I'm wrong... if it fixes no board (as well as mine) then I'm correct; Its an eay experiment.

[androsch]

tkaiser is correct about one thing, and one thing only related to this discussion, the micro-usb connector is insufficient for providing power to the Pine board.

... the micro-usb connector is insufficient for power to the Pine boards, and its insufficient for power to the PI(s)...  this has been proven empirically.

Everything else he has said about this problem is incorrect. All of my boards are powered from the bus, not via the micro-usb connector.  Also, all of my boards have more than adequate power supplies;  one of my boards works flawlessly (GbE), the other one (GbE) does not work at all.  Both boards work flawlessly at 100mb/s.   (this is NOT a software problem, and this is NOT an environment problem, nor is this a power problem)

The situation is NOT related to power.  The only power related observation I have so far is that if my working board is run from battery ( because the DC IN is very clean ) the speeds go up slightly.  This does not affect the non working GbE board at all )

To prove that tkaiser does not have a clue what he is talking about---   all you have to do is have everyone on the POLL list that reports having a non functioning GbE board power their Pines from the euler bus...  if it fixes all boards (including mine) then I'm wrong... if it fixes no board (as well as mine) then I'm correct; Its an eay experiment.

OK, thanks for clarifying that you are not really interested in solving the problem, i'm out from here also. Sorry for all guys have same issues with GbE and no chance to sort this out. I'm leaving, have a nice day.

[waldo]

tkaiser is correct about one thing, and one thing only related to this discussion, the micro-usb connector is insufficient for providing power to the Pine board.

... the micro-usb connector is insufficient for power to the Pine boards, and its insufficient for power to the PI(s)...  this has been proven empirically.

Everything else he has said about this problem is incorrect. All of my boards are powered from the bus, not via the micro-usb connector.  Also, all of my boards have more than adequate power supplies;  one of my boards works flawlessly (GbE), the other one (GbE) does not work at all.  Both boards work flawlessly at 100mb/s.   (this is NOT a software problem, and this is NOT an environment problem, nor is this a power problem)

The situation is NOT related to power.  The only power related observation I have so far is that if my working board is run from battery ( because the DC IN is very clean ) the speeds go up slightly.  This does not affect the non working GbE board at all )

To prove that tkaiser does not have a clue what he is talking about---   all you have to do is have everyone on the POLL list that reports having a non functioning GbE board power their Pines from the euler bus...  if it fixes all boards (including mine) then I'm wrong... if it fixes no board (as well as mine) then I'm correct; Its an eay experiment.

Mark, please abide to your own rules , do not get personal, don't bash people, ... in fact ... by your own guidelines you should realy delete this post ....

[cdslashetc]

I switched to Euler for power and with respect to the gigabit issue it made no difference on my board with the issue.

Sent from my Nexus 6 using Tapatalk

[MarkHaysHarris777]

I switched to Euler for power and with respect to the gigabit issue it made no difference on my board with the issue.

Sent from my Nexus 6 using Tapatalk

Of course not.  

The gigabit GbE issue is NOT related to power in any way, period.

---

<snip>

To prove that tkaiser does not have a clue what he is talking about---   all you have to do is have everyone on the POLL list that reports having a non functioning GbE board power their Pines from the euler bus...  if it fixes all boards (including mine) then I'm wrong... if it fixes no board (as well as mine) then I'm correct; Its an eay experiment.

Mark, please abide to your own rules , do not get personal, don't bash people, ... in fact ... by your own guidelines you should realy delete this post ....

My post is NOT bashing in any way.  I am responding to tkaiser's bogus claim (posted via Androsch) that powering the pine via the euler bus will somehow improve or correct the GbE problem.  This claim is an asinine assertion, and calling it out as such is not personal, nor is it bashing in any way.  I'm only stating the counter point that (he) has made a bogus claim and that it should not interferre with this discussion and that it should not confuse the main fact in this case.

Also, I made my own assertions easily testable (falsifiable) by giving everyone an experiment that is easily run to verify the point. One person took the challenge;  point verified. 

We are not going to allow bogus claims to confuse or contort this issue.  We are going to get to the bottom of it, and bogus claims are going to be called out on it as needs be.  End of story.