Until we know for *certain* what is the cause(s) of this issue (GbE not working), we shouldn't make any statements ruling anything out. The reason that we are getting off track here at times might be due to something very simple - there are multiple possible points of failure. Anything ranging from the input power (voltage and ripple), poor soldering on the connections, different PHY chips, cabling, network environment, software configuration could be responsible. And it could be just one single factor in somes cases, or any combination, or something else I haven't mentioned.
Different networking environments can also trigger completely failures (I don't go on to talk about the Wireless N router that I had which worked fine with all the B/G devices I had, but when one wireless N device connected it would prevent the other devices from working, but when connected to my new router, it works perfectly - was just a clash between that particular configuration).
tkasier has provided evidence that indicates that at on at least one production board, by changing between Euler power and USB power, there was a severe deterioration in networking performance. And repeated this with another non pine64 device to demonstrate that this sort of problem isn't pine64 specific. Data is data. It only takes one piece of evidence to disprove a theory, and this data proves that the GbE throughput is not immune to low voltage conditions, thus should not be dismissed out of hand.
Software does make a different to networking performance on any of these SoC ARM boards - since the networking is CPU bound, if the CPU is not correctly clocked and the governor appropriately configured, networking will be slow. The debian pine64.pro image
is incorrectly configured for optimum GbE networking out of the box - it is limited to sub-100M speeds when in 1000M (GbE mode). This is fixable by changing the cpu governor. This is with a sample size of one, but is 100% reproducible.
However, I don't believe auto-negotiation is affected by a software configuration, and if there is a failure there related to the mandatory syncing of clock speeds for GbE, then that is in the domain of the PHY, the pine64 build quality/design (maybe there is some crosstalk or some minimum separation of components has been compromised?) and the network environment (which includes the cabling, switches, routers, packet sizes, etc, etc).
So we may in fact have several reasons why 'the same' problem occurs... so until we can get some more conclusive evidence as to why GbE works in some cases, and doesn't work in others... we cannot rule anything out. Just because switching between micro USB power and euler bus power in one users case doesn't fix the problem, doesn't mean this problem does not exist... just means it is not the (sole) cause of GbE problem.
The goal now should be to minimise the different variables where possible, and if you get GbE working, you can then check if reverting back to x causes issues, or reverting back to y works also. You may find in your case, that the cable length is a factor, but it doesn't affect 4/5 other users. Another users says well, it works fine with xyz router/switch, but others don't have the same luck. This is where since if users are being asked to do a poll on if they are having issues or not, they should also be asked what can they change to add more data to the mix. i.e. my pine64 doesn't seem to be bothered by input power, heat, cable length, cable quality... once the linux distro is appropriately reconfigured for GbE speeds... it works reliably whatever I do it it to trip it up... but maybe the GbE PHY in the ADSL router I have is just that good (which is should be... the manufacturer is known for making reliable equipment!!).
That's enough of an essay, considering I'm probably preaching to people who are in full agreement. So, can we get back to the business of NOT saying that this or that isn't a problem, but instead focus on identifying what is.
(09-08-2016, 11:41 AM)MarkHaysHarris777 Wrote: [ -> ]That's easy... because its a hardware problem; allow me to explain.
... hardware problems are almost always NOT precisely reprocudable , and almost ARE always interpmittent, not only within their own environment but also across environments-- and particularly if the issue is border-line.
To be more precise, your board was not 'fixed' nor 'corrected' in longsleep's environment; he just knows how to tune the boards so that regardless of their condition they function better; but, its still the same board, and it still is not functioning correctly. I will absolutely guarantee that my bad board will NOT run in longsleep's environment , period (because my board is NOT border-line... at Gbe, it doesn't work at all !-- its not about tuning... its about non function. It has a serious hardware flaw.
Just to be complete here, software problems (on the other hand) are almost always reproducable , on every machine , in all environments. If you do x, y, and z the software will fail like such and so ! Also, if you make a software correction (on all boards) then the problem ceases to exist on all boards. If the problem is environmental, then the problem follows the environment (for all boards).
We have the unique situation with my boards in that one of them works perfectly (GbE) and one of them does not work at all (GbE); the problem does not follow the software, and the problem does not follow the environment ! In fact, the environment that I created for testing is perfect-- honestly , there is no better environment on earth to test these boards than in my lab. One of my boards works flawlessly, and the other one does not work at all. The conclusion is 'conclusive' ! This problem is a hardware flaw (probably manufacturing flaw, as apposed to design flaw) on the boards themselves.
