LAN/NIC problem

[DonFL]

Our currently lead on this investigation is toward the power quality that RTL8211 received, namely small voltage ripping wave on the VDD and AVDD line. It seems that certain RTL8211 chip sensitive to this voltage noise. We have testing this theory on the other vendor board and initial results seems works well.

We are collecting more GbE affected Pine A64+ boards and our hardware engineering team are focusing into this path. The focus point is on one inductor (ferrite bead) at one of the VDD power line to RTL8211 chip.

P/S: Appreciate Marcus and Tom kaiser effort on this finding.

Regards,
TL Lim

Is the VDD and AVD issue that TL mentions the same as the VDD33 concern that tkaiser had discussed as a possible factor?

[MarkHaysHarris777]

Our currently lead on this investigation is toward the power quality that RTL8211 received, namely small voltage ripping wave on the VDD and AVDD line. It seems that certain RTL8211 chip sensitive to this voltage noise. We have testing this theory on the other vendor board and initial results seems works well.

We are collecting more GbE affected Pine A64+ boards and our hardware engineering team are focusing into this path. The focus point is on one inductor (ferrite bead) at one of the VDD power line to RTL8211 chip.

P/S: Appreciate Marcus and Tom kaiser effort on this finding.

Regards,
TL Lim

Is the VDD and AVD issue that TL mentions the same as the VDD33 concern that tkaiser had discussed as a possible factor?

It is apparently a possible factor on some of the test boards , but it is not a facotr on my three boards... the voltage is absolutely clean... no ripples at all;  particularly if the units are running on battery.  But even with the clean PHY_VDD33 voltage one of my three boards does not work in GbE mode (drops packets, drops pings, locks up on scp transfers, and fails iperf3 tests miserably even with longsleep tuning. On my failing board the PHY_VDD33 voltage is NOT an issue.

There is another way to say this... with an inductor on the PHY_VDD33 line, the iperf3 tests will probably improve on the two boards I have that do work in GbE mode ! I have shown this on my boards by running them from very clean power (battery) with filtered inputs to the euler bus; however, putting an inductor on the PHY_VDD33 line on my non working GbE board is not going to make it magically work. Whatever is wrong on that board is NOT power related, at least not on the VDD33 line; something else is wrong with that particular board.

[tkaiser]

tkaiser has a lot of knowledge.

Not regarding electrics/electronics and the stuff we're talking about. I only have some experiences. Made with a non-working board a few days ago. PSU/voltage was key.

Here the users are around that could help nailing down the problem. Unfortunately one person prevents that all the time. I can not write more since it gets deleted again. He censored a few hours ago the last try to encourage users to measure PHY_VDD33 on their boards while not using Fast Ethernet hacks/'fixes' (since then it's absolutely useless, this has to happen in GbE mode). That's the real problem unfortunately.

What are you talking about ?

... if you would bother to read my post directly above yours you would notice that I not only encouraged others to measure the PHY_VDD33 , but told them how I did that , and I gave you my results of that measurement ( in GbE mode ).  All voltages normal, solid, and stable.

To prove a claim to be false, all that is needed is one case.  I have proven that the VDD33 voltage is not the problem. Why do you keep insisting that it is?  This makes little sense.

Do YOU have a solution yet ?

Since the thread is opened again (thanks TL Lim for not allowing that Pine64 community gets totally destroyed) I will now post my answer here that got rejected some hours ago since you did what you do all the time: closing threads, censoring stuff, banning users.

"No, of course I don't have a solution, I'm just interested in finding the culprit. By following sources outside of this forum (here contribution is useless since censorship happens all the time -- please be aware that your actions are documented publicly so think first before deleting/censoring again!) you could really be able to understand that at least on one board there is a strong correlation between DC-IN (PSU used, method used, voltage fed) and GbE behaviour.
 
Therefore it would be really nice if people affected by the issue could measure PHY_VDD33 on their boards:

 
To get the idea whether there is a correlation on more than one board (if it helps you to understand: this is some sort of a poll -- you like polls don't you?). Possible results: No, there is none (search has to continue) or there is one.
 
Of course it's important that NO WORK-AROUND is used when these measurements happen (no destroyed cables, no ethtool 'fix'). And of course it doesn't play a role what you measured in your lab since it's about getting results from the field.
 
And all you do is constantly censoring everything that is beyond your imagination and discourage users to try this out ('I have proven that the VDD33 voltage is not the problem'). How did you do that and when? Isn't your board on its way to TL Lim: https://irclog.whitequark.org/linux-sunx...9#17502646; (or is he speaking of someone else?).
 
Anyway: I'm pretty confident that you don't get why it could be important to accept other issues than those your 'expert soldering eyes' are able to see. And that's the reason you should resign from your moderator role rather sooner than later."

We are collecting more GbE affected Pine A64+ boards and our hardware engineering team are focusing into this path. The focus point is on one inductor (ferrite bead) at one of the VDD power line to RTL8211 chip.

Thanks, that's interesting. I summarized my findings here (being absolutely no expert at all in this area, just trying different things out and documenting it): http://forum.armbian.com/index.php/topic...entry15432

BTW: In this thread alone 3 users haven been banned (temporarely), countless postings have been censored or completely deleted and all because one person who is enabled to act as a censor didn't accept that the whole issue could also be about 'environmental' conditions (the PSU being used). Congratulations!

[MarkHaysHarris777]

Thanks tkaiser,  that is precisely where I took the PHY_VDD33 measurement with my board in GbE mode (big RED arrow in your pic) with no hackyfix, nor ethtool work-around,  connection up  1000 /full  in GbE mode with a perfectly clean VDD33 line.

My board was powered via euler bus, pin(4 5v+) pin(6 ground) with heavy pi passive low-pass filtering on the supply line... all boards in my lab are powered this way.

Again, battery operation improves the iperf3 test speeds on the boards that work...  but on the board that does not work (GbE mode) the battery operation does not help, and the VDD33 line is clean.

[tkaiser]

the VDD33 concern that tkaiser had discussed as a possible factor?

This was more of a question than a 'concern'. All I (an absolute electrics noobie) did was testing @androsch's board with different equipment, experiencing strange voltage drops and also different results depending on the PSU used. One difference between those PSU was the voltage provided so it seemed logical to me to look into this specific environmental condition (the PSU used, the voltage available to the PHY and also the voltage available at the USB ports).

It was just about asking those users for help that are affected and that could contribute isolating the problem. Guess what happened. The usual person unfortunately enabled to act as main censor here did what he's doing all the time: https://github.com/igorpecovnik/lib/issu...-246578306

[waldo]

tkaiser has a lot of knowledge.

Not regarding electrics/electronics and the stuff we're talking about. I only have some experiences. Made with a non-working board a few days ago. PSU/voltage was key.

Here the users are around that could help nailing down the problem. Unfortunately one person prevents that all the time. I can not write more since it gets deleted again. He censored a few hours ago the last try to encourage users to measure PHY_VDD33 on their boards while not using Fast Ethernet hacks/'fixes' (since then it's absolutely useless, this has to happen in GbE mode). That's the real problem unfortunately.

What are you talking about ?

... if you would bother to read my post directly above yours you would notice that I not only encouraged others to measure the PHY_VDD33 , but told them how I did that , and I gave you my results of that measurement ( in GbE mode ).  All voltages normal, solid, and stable.

To prove a claim to be false, all that is needed is one case.  I have proven that the VDD33 voltage is not the problem. Why do you keep insisting that it is?  This makes little sense.

Do YOU have a solution yet ?

Since the thread is opened again (thanks TL Lim for not allowing that Pine64 community gets totally destroyed) I will now post my answer here that got rejected some hours ago since you did what you do all the time: closing threads, censoring stuff, banning users.

-snip-
 
And all you do is constantly censoring everything that is beyond your imagination and discourage users to try this out ('I have proven that the VDD33 voltage is not the problem'). How did you do that and when? Isn't your board on its way to TL Lim: https://irclog.whitequark.org/linux-sunx...9#17502646; (or is he speaking of someone else?).
 
Anyway: I'm pretty confident that you don't get why it could be important to accept other issues than those your 'expert soldering eyes' are able to see. And that's the reason you should resign from your moderator role rather sooner than later.

BTW: In this thread alone 3 users haven been banned (temporarely), countless postings have been censored or completely deleted and all because one person who is enabled to act as a censor didn't accept that the whole issue could also be about 'environmental' conditions (the PSU being used). Congratulations!

Hear hear,... Thanks for thay tkaiser wouldn't dare to say it myself.... Was banned till few hours ago, for a post containing amongst other things yet another link to the olimex gbe autoneg patch.

Tkaiser... You need that measured oscilloscope style (talking about ripples) ,  or would the difference be great enough for a multimeter?

[MarkHaysHarris777]

tkaiser has a lot of knowledge.

Not regarding electrics/electronics and the stuff we're talking about. I only have some experiences. Made with a non-working board a few days ago. PSU/voltage was key.

Here the users are around that could help nailing down the problem. Unfortunately one person prevents that all the time. I can not write more since it gets deleted again. He censored a few hours ago the last try to encourage users to measure PHY_VDD33 on their boards while not using Fast Ethernet hacks/'fixes' (since then it's absolutely useless, this has to happen in GbE mode). That's the real problem unfortunately.

What are you talking about ?

... if you would bother to read my post directly above yours you would notice that I not only encouraged others to measure the PHY_VDD33 , but told them how I did that , and I gave you my results of that measurement ( in GbE mode ).  All voltages normal, solid, and stable.

To prove a claim to be false, all that is needed is one case.  I have proven that the VDD33 voltage is not the problem. Why do you keep insisting that it is?  This makes little sense.

Do YOU have a solution yet ?

Since the thread is opened again (thanks TL Lim for not allowing that Pine64 community gets totally destroyed) I will now post my answer here that got rejected some hours ago since you did what you do all the time: closing threads, censoring stuff, banning users.

-snip-
 
And all you do is constantly censoring everything that is beyond your imagination and discourage users to try this out ('I have proven that the VDD33 voltage is not the problem'). How did you do that and when? Isn't your board on its way to TL Lim: https://irclog.whitequark.org/linux-sunx...9#17502646; (or is he speaking of someone else?).
 
Anyway: I'm pretty confident that you don't get why it could be important to accept other issues than those your 'expert soldering eyes' are able to see. And that's the reason you should resign from your moderator role rather sooner than later.

BTW: In this thread alone 3 users haven been banned (temporarely), countless postings have been censored or completely deleted and all because one person who is enabled to act as a censor didn't accept that the whole issue could also be about 'environmental' conditions (the PSU being used). Congratulations!

Hear hear,... Thanks for thay tkaiser wouldn't dare to say it myself.... Was banned till few hours ago,  for a post containing amongst other things yet another link to the olimex gbe autoneg patch.

Tkaiser... You need that measured oscilloscope style (talking about ripples) ,  or would the difference be great enough for a multimeter?

hi waldo, yes, you absolutely need a scope !

... but the scope won't help much with my board... its got a clean VDD33 line and it does not work in GbE mode.  

(no a multimeter won't get it)

[martinayotte]

The kind of scope can be relevant too ...
In my case, I can't trust my scope since the ripples can be high frequency and my scope won't be able to show them !

[tkaiser]

Tkaiser... You need that measured oscilloscope style (talking about ripples) ,  or would the difference be great enough for a multimeter?

I've not the slightest idea, I'm not an expert at all in this area. I'm a software (server) guy and my only real contribution is to emphasize why software/settings matter. In this forum certain people spread the rumour that Pine64+ would not be able to benefit from GbE at all and that it's even useless to use GbE since there would be no performance gains compared to Fast Ethernet. And while this might be true when using OS images from pine64.pro or Pine64 wiki this is not true if people would use good OS images (the only original Ubuntu Xenial image from longsleep for example or maybe Armbian in the meantime -- but it really doesn't matter, you get also full GbE performance when switching from ondemand to interactive cpufreq governor with any of the 'official' OS images).

I'm getting tired repeating that again, all information available at Armbian forum. Time to finally resign here (had to do that already back in May when another moderator started censoring posts -- unfortunately TL Lim and the pine64 guys don't care about stuff like that)

[MarkHaysHarris777]

... it's even useless to use GbE since there would be no performance gains compared to Fast Ethernet. And while this might be true when using OS images from pine64.pro or Pine64 wiki this is not true if people would use good OS images (the only original Ubuntu Xenial image from longsleep for example or maybe Armbian in the meantime -- but it really doesn't matter, 

I think it does matter. 

... the official images offered at pine64.pro are what we are recommending as a team, and what we are supporting not only here, but on the irc as well. Essentially I'm saying that we are working with what we have to work with, and doing the best we can with what we have.  And how things have changed; back when I was a young man getting started in electronics computers did not exist (as we know them) and nobody could make anything oscillate in the Ghz range. (my first scope used a long CRT and was populated with vacuum tubes).

Most people are not going to have the equipment necessary to monitor the VDD33 line voltage properly while the unit is in GbE mode.  I don't know, but perhaps TL Lim and company might be willing to replace just enough boards to get some samples back to the lab.  In other words, an exchange.  Maybe a dozen of us send our boards in, and Pine Inc sends replacements back... and then they have our field units to test with and we have functioning boards to get on with our lives with...  I'm just suggesting it, and have no idea how TL Lim might feel about the proposition (just something to think about ).