LAN/NIC problem
(09-13-2016, 10:56 AM)tkaiser Wrote: 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).

Indeed. I'm getting a very decent improvement just using a GbE over USB compared to using Fast Ethernet on the board itself (using Armbian, but I even got a decent return on the pine64 images). That's significant to me. 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.
  Reply
My useless 2 cents again.  I am a novice when it comes to defining what makes the gigabit Ethernet work properly.  As an old time electrician from a factory setting, the number one weak link for electronics was the power supply.  Since the power distribution system induces all kinds of transient voltages and ripples, it is imperative to have proper filtering for the electronics, either through the power supply or on board.

I do not have a scope, and it would take a very good scope to catch the spikes and valleys of the ripples in the voltage being measured.  Most of the spikes are a very, very short frequency, so they really don't hurt the electronics, even with a high amplitude.

Since I am not an electrical engineer, I would hope that this day and time, the boards would have a built in voltage regulator, that would filter out all the transients (in the old school, the board would have coils and capacitors to filter).

But, I personally do not think it is a hardware problem.  For one, only Linux running on my 2 gig board NEVER had a problem with a standard Ethernet cable, perhaps not gigabit, but it worked OK as it was.  On the other hand, the modified Ethernet cable still did not work with Android or Remix, when I first tried the modified cable.  I put the board away in a drawer for awhile and never touched it because lack of Ethernet connection.

A couple of days ago, I tried it again, and lo and behold using the same modified Ethernet cable, that did now work earlier now works.  I know there was no little pixie that modified my board when it was packed away, so that only leaves software that changed.  That is why I don't believe it is a hardware issue.  But I am only talking in reference to the Ethernet connection, not whether it is connecting with gigabit or just fast Ethernet.  For my purposes, fast Ethernet works just fine for me.  But, if I choose to use this board as a server, then having a gigabit connection would be very critical.
  Reply
(09-13-2016, 01:47 PM)clarkss12 Wrote: A couple of days ago, I tried it again, and lo and behold using the same modified Ethernet cable, that did now work earlier now works.  I know there was no little pixie that modified my board when it was packed away, so that only leaves software that changed.  That is why I don't believe it is a hardware issue.  But I am only talking in reference to the Ethernet connection, not whether it is connecting with gigabit or just fast Ethernet.  For my purposes, fast Ethernet works just fine for me.  But, if I choose to use this board as a server, then having a gigabit connection would be very critical.

hi clarkss12,  yes,  it will work with a modified cable. (my emphasis above)

The problem is, that it will NOT work if you replace the modified cable with a standard cable...  and your board is probablly working (like mine is) wonderfully at 100mb/s.

You have circumvented the problem with the 'hackyfix' work-around.  And if you're happy with that, then no problem.  But if you want the board (or need the board) to work in GbE mode, then you still have a problem, and that problem is in the hardware specific to the board.

edit: PS:  ... nothing changed on your board... the first time you tried the cable it may not have been seated properly, or you may have had another network snag of some sort, or your carrier may have had a problem...  but the software did not change on your board which made your modified cable start working.
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
It's useless
  Reply
(09-13-2016, 05:31 PM)tkaiser Wrote: It's useless

Hahaha  Tongue


Scope-related... mine will be way too, it's an old piece of crap i saved from destruction
  Reply
(09-13-2016, 10:08 AM)DonFL Wrote:
(09-13-2016, 09:42 AM)tllim Wrote: 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?

We are looking onto three areas, VDD33, AVDD33, and VDD10. This finding close to tkaiser discussion at Sunxi IRC but pin point to ferrite bead is from the other board that suffer on sma e issue. I have recently released the Pine A64+ 2GB schematic at Pine64 wiki page so taht interest parties can explore further.
  Reply
(09-13-2016, 10:52 AM)martinayotte Wrote: 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 !

This ripples is high frequency and we thinks the inductor causing this. This finding comes out when we help to debug that similar board that also suffer on the GbE but works on 10/100 Mbps which their previous revision board doesn't have this issue but current revision board suffer. After compare both previous and new revision schematics and the inductor different. Once short that particular inductor, the new version on that board able to work on GbE. We thinks the Pine64 board may be in same situation and we currently try to collect enough GbE issued boards to check on this finding.
  Reply
(09-13-2016, 01:47 PM)clarkss12 Wrote: My useless 2 cents again.  I am a novice when it comes to defining what makes the gigabit Ethernet work properly.  As an old time electrician from a factory setting, the number one weak link for electronics was the power supply.  Since the power distribution system induces all kinds of transient voltages and ripples, it is imperative to have proper filtering for the electronics, either through the power supply or on board.

I do not have a scope, and it would take a very good scope to catch the spikes and valleys of the ripples in the voltage being measured.  Most of the spikes are a very, very short frequency, so they really don't hurt the electronics, even with a high amplitude.

Since I am not an electrical engineer, I would hope that this day and time, the boards would have a built in voltage regulator, that would filter out all the transients (in the old school, the board would have coils and capacitors to filter).

But, I personally do not think it is a hardware problem.  For one, only Linux running on my 2 gig board NEVER had a problem with a standard Ethernet cable, perhaps not gigabit, but it worked OK as it was.  On the other hand, the modified Ethernet cable still did not work with Android or Remix, when I first tried the modified cable.  I put the board away in a drawer for awhile and never touched it because lack of Ethernet connection.

A couple of days ago, I tried it again, and lo and behold using the same modified Ethernet cable, that did now work earlier now works.  I know there was no little pixie that modified my board when it was packed away, so that only leaves software that changed.  That is why I don't believe it is a hardware issue.  But I am only talking in reference to the Ethernet connection, not whether it is connecting with gigabit or just fast Ethernet.  For my purposes, fast Ethernet works just fine for me.  But, if I choose to use this board as a server, then having a gigabit connection would be very critical.

Actually on this case, the filter may be the one that causing this issue.
  Reply
(09-13-2016, 11:08 AM)MarkHaysHarris777 Wrote:
(09-13-2016, 10:56 AM)tkaiser Wrote: ... 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 ).

I plan to exchange back some board that considers suffer on GbE and check on this lead. However, this is still a finding and we still don't want whether this is valid.
  Reply
(09-13-2016, 09:42 AM)tllim Wrote: 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

That for the TL, glad to hear you're taking on board all the data people are collecting and aren't discounting anything yet Wink Hopefully the faults with the other vendors board will help you get closer to the problem. Smile
  Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)