LAN/NIC problem

[pfeerick]

You are apparently not aware of cross-talk.  I suggest you read up on it, because it dramatically affects this particular hardware problem.

Seriously? You're saying that the very reason that ethernet cables are in twisted pairs (i.e. to PREVENT crosstalk) has some connection with the GbE issues pine64 users are experiencing? And whilst I may not have read every single post on the GbE thread as I'm only following it out of interest, not for a need to fix the issue, I haven't seen any evidence that would suggest that length is an issue. Earlier in this thread, the second poster indicated that this was not the case in relation to his issue, as neither long nor short Cat6 cables made any different.

In fact, a longer cable was more reliable in one instance, but there was the suggestion that it was a Cat5/100T cable (and more crosstalk would have been expected, but it still worked fine). Everything I have seen to date points to auto-negotiation. Which is why tkasier kept asking for consist, repeatable, hard data, so that all the false flags could be eliminated. For instance, if we can start identifying that there really are different NIC chips used on certain boards. That some made it past QC with poor solder joints. Or that the Pine64s GbE is not compatible with certain chipset GbE networks due to a hardware clash (which could be the fault of either device). Or a power issue. Or a register configuration. Or a combination of any?!

[MarkHaysHarris777]

You are apparently not aware of cross-talk.  I suggest you read up on it, because it dramatically affects this particular hardware problem.

Seriously? <snip> I haven't seen any evidence that would suggest that length is an issue. Earlier in this thread, the second poster indicated that this was not the case in relation to his issue, as neither long nor short Cat6 cables made any different.

You are mixing ( and again, confusing ) this conversation.  No one ( not me ) said the issue is the length; that is both a red herring and a straw man argument at the same time.

All that I said, and all that I meant, is that changing the length of the cable 'has in fact' changed the measurable out-comes in this situation (that's all !).  And it is measurable and it is repeatable !

That's just science bubba.

There is a very good write-up in the link I posted earlier about the inherent problems in twisted pairs with cross-talk and how the hardware (and software) at each end are employed to negate the noise.  This is especially true with GbE (which is why all eight wires, all four pairs) are necessary.  

The issue IS NOT the length of the cable; however, the length of the cable has made a difference in the measurements made in relation to this thread. It should also be restated that the inconsistent and intermittent results obtained in the measurement process are very much indicative of a hardware problem; at this point I am almost 100% sure that the situation is hardware only at its root cause.

[jandvs]

I have DietPi installed now and did some more testing. With both a 6 foot cat6 or 1 foot cat 5, it does negotiate the connection and pickup an IP address from DHCP (first time it took about a minute before it got an IP). However, I experience severe packet loss with both cables. The 1ft cat5 seems like it might be "slightly" better. But not enough to call it a workaround. I saw anywhere from 15% to 80% packet loss when trying to ping another local network device using either of these cables. I could not run speedtest-cli script, it would simply throw python errors. I was able to connect to an SSH server on the internet, but just briefly before it spontaneously disconnected. Many times, even name resolution failed.

So a short 1 foot cable does not resolve the problem, nor makes it even good enough to call it better.

Using the "ethtool -s eth0 speed 100 duplex full", forcing it down to 100Mb/s, with either the cat5 or cat6 cable gives me 0% packet loss pinging local or internet hosts.

Let me know how the solder reflow goes.

[MarkHaysHarris777]

Let me know how the solder reflow goes.

The solder reflow did not damage the board, but it also did not correct the problem. At least in my case, the cold solder joints I found on the ethernet port were not the root cause.

[amc2012]

a friend of mine also has a pine64.  said he never had a problem with Gigabt.  I asked him how long the cable was, and he said about 6 inches.   I don't have a cable that short on hand.  if I get a chance I'll make one and see what that does.  I also asked him to try a longer cable to see what t does to his.

Doesn't matter. I tried this a couple days ago. Used a purchased 6" cable that I had been working fine in the wiring closet. Did nothing for the GbE issue with my Pine.

I wish people would stop talking about cables as a possible solution. It's not. Take five minutes to enjoy doing something you love vs. making yet another cable that's not going to do anything to help your situation.  

[jandvs]

a friend of mine also has a pine64.  said he never had a problem with Gigabt.  I asked him how long the cable was, and he said about 6 inches.   I don't have a cable that short on hand.  if I get a chance I'll make one and see what that does.  I also asked him to try a longer cable to see what t does to his.

Doesn't matter. I tried this a couple days ago. Used a purchased 6" cable that I had been working fine in the wiring closet. Did nothing for the GbE issue with my Pine.

I wish people would stop talking about cables as a possible solution. It's not. Take five minutes to enjoy doing something you love vs. making yet another cable that's not going to do anything to help your situation.  

Agreed.  My friend tried a 100ft cable on his and it worked fine.  Wonder if it's worth replacing the port?  Doesn't look like it would be hard to remove.

The soldering on the RTL chip is pretty low quality.  I see 2 pins that might actually be shorted.  I'll have to find my meter and see if i can test it.

[cdslashetc]

The crosstalk is ON THE BOARD. If you improve SNR getting into the traces on the PCB it may improve just enough to get it to work.

Sent from my Nexus 6 using Tapatalk

[MarkHaysHarris777]

The crosstalk is ON THE BOARD. If you improve SNR getting into the traces on the PCB it may improve just enough to get it to work.

Sent from my Nexus 6 using Tapatalk

No doubt.   There is an array of caps and resistors on the board near the RTL8211E chip; and lots of cold solder joints on the ones on my three boards. There are differences in these devices between the three boards... and some of the 000 values (devices that look like a resistor, but have zero ohms) are soldered straight across on one of my boards with cold solder joints !  I honestly think the problem is a cap or solder problem, if not on the RTL8211E chip itself, perhaps on the 'mods' field of resistors and caps near the 8211E.  

If there were cross-talk on the board itself...   what is your test procedure, and what is your solution?  Do you have some empirical test data to share ?

[amc2012]

The crosstalk is ON THE BOARD. If you improve SNR getting into the traces on the PCB it may improve just enough to get it to work.

No doubt.   There is an array of caps and resistors on the board near the RTL8211E chip; and lots of cold solder joints on the ones on my three boards. There are differences in these devices between the three boards... and some of the 000 values (devices that look like a resistor, but have zero ohms) are soldered straight across on one of my boards with cold solder joints !  I honestly think the problem is a cap or solder problem, if not on the RTL8211E chip itself, perhaps on the 'mods' field of resistors and caps near the 8211E.  

I hadn't even looked at how poor the soldering was on that chip on my board.

It's bad.

[jandvs]

Yeah.. it's pretty bad. Mine is much the same. It looked like 2 pins were shorted, but it was just some gunky waxy stuff between them.

Would Pine64 replace these defective boards? Obviously it's only some of them that have this issue.

---

I opened a support ticket with them to see if they would just replace the board.