|
Kinda upset at the lack of response to GBe issues
|
08-25-2016, 02:36 AM
(08-24-2016, 11:34 PM)MarkHaysHarris777 Wrote: I built the poll. I also edited the poll, to allow for multiple votes (2). I know you created the poll. So where on the attached screenshot of the poll does it allow me to vote a second time? Maybe you need to revist the settings in case it didn't actually apply. 
08-25-2016, 02:55 AM
(08-25-2016, 02:36 AM)pfeerick Wrote:(08-24-2016, 11:34 PM)MarkHaysHarris777 Wrote: I built the poll. I also edited the poll, to allow for multiple votes (2). You know what's happening (I think so) once you've taken the poll , you can't take it again. So, if its the first time you can choose two options, but if you come back after only choosing one option... it won't let you take the poll again.. 
marcushh777
 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! )
08-25-2016, 03:03 AM
(This post was last modified: 08-25-2016, 03:04 AM by pfeerick.
Edit Reason: and not edited, missing word
)
(08-25-2016, 02:55 AM)MarkHaysHarris777 Wrote:(08-25-2016, 02:36 AM)pfeerick Wrote:(08-24-2016, 11:34 PM)MarkHaysHarris777 Wrote: I built the poll. I also edited the poll, to allow for multiple votes (2). Yup, since polls on MyBB are designed to only let you take them once (and not edited), so the vote can't be 'rigged'. And I took it before you modified it, so was only able to choose one option. Which is all I would have been able to pick anyway since my 2nd Pine64 is nowhere to be seen, so it wouldn't be fair to say it didn't work 
08-28-2016, 10:25 AM
(This post was last modified: 08-28-2016, 04:41 PM by MarkHaysHarris777.
Edit Reason: added code blocks for readability
)
Follow-up from previous post with results from testing two boards (one bad) with two different OS's
Background: I have two PINE64 boards which run two different OS versions. One runs Ubuntu. The other, Debian. I will refer to these boards as board A and board B regardless of which OS I run on them. I have experienced poor communication performance from the new board B. What was unknown was whether the performance was due to OS, network parameters defined while setting up the OS, a network issue caused by the physical layer on the network (bad or incompatible hardware), or a faulty NIC on the board itself. The boards are running on different legs on my network. I have swapped the SD cards on the boards leaving all other hardware unchanged and the problem continues with the board that originally ran Debian (board B). The problem remained on board B regardless of OS running. Testing Methodology: Eliminate the variables: 1) Run each board separately while testing in an isolated area on the network. Plug into same network cable (CAT 6) and power supply swapping out the board so the only variable is the board. 2) Run test suite twice with each board. Once with Debian running and once with Ubuntu running. Boot the Pine64 machine Run longsleep's "pine64_tune_network.sh" script to insure NIC parameters are known. Validate communication configuration by running "ethtool eth0" and examining output for consistency. Run iperf3 as client connecting to know stable server running iperf3 as server and record output. Run iperf3 as server and connect from known stable machine running iperf3 as client and record output. Findings: Code: Board B has a faulty NIC or component that interacts with NIC.
08-29-2016, 03:16 AM
(This post was last modified: 08-29-2016, 03:21 AM by pfeerick.
Edit Reason: just saw tkaisers post on the tuning thread
)
Possibly some food for thought... and certainly something worth testing if you are having issues, and can try this. When reading on the Armbian forums about support being officially acknowledged for the Pine64... (I say official as they actually support back in May), rather than just generic support for A64 processors, there was an interesting mention of the ethernet GbE issue by tkaiser. Specifically that during the auto-negotiation process, the RTL8211E PHY needs an additional ~350 mW, so whilst this isn't much of a power increase in the grand scheme of things, since the MicroUSB port isn't the best method of providing a clean 5v supply to do connector resistance, and voltage sag over the USB lead, it might be worth trying to power the pine64 via the euler connector (i.e. pins 4 & 6).
There is also a good critical analysis by tkaiser of exactly what to expect from the pine64 generally - both in setting realistic expectations of performance, and how to get the best out of it. There is also mention of how incorrect cpufreq governor settings will result in lower ethernet speeds when running iperf as ethernet throughput scales with CPU frequency. Edit: lol... and whilst I was writing this, tkaiser posted some details again showing that iperf is not the best tool for testing speeds, and also specifically recommended trying the Euler power connector
08-29-2016, 04:17 AM
(This post was last modified: 08-29-2016, 04:24 AM by MarkHaysHarris777.)
We already know that powering the PineA64 board with the battery improves the GbE speeds significantly; probably do to the 5v rail not being 'clean' when powered via the wall wart. I experienced this in my tests even though my mains power are all well filtered.
I will be testing my units again because I realized that the ubuntu board (PineB that does not appear to do GbE) is being powered by the Pine 2A wall wart. I will substitute the 2.5A supply and retest today. edit: also, I have been studying my boards (I have three of them) and I am noticing several significant differences in the hardware near the RTL8211E (even though all three boards have the same chip!). There are places on one board where components (either caps or resistors) have been omitted and the gap has been soldered across. We probably need some micro-graphs of that area on the board so that we can cross that against the schematic that we have. I am still hopeful that a tweak (hardware mod) may correct the boards that do not work correctly. We know the chips support the GbE... so there has to be something on the board itself that is preventing the GbE from working.
marcushh777
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! )
08-29-2016, 05:19 AM
(08-29-2016, 04:17 AM)MarkHaysHarris777 Wrote: We already know that powering the PineA64 board with the battery improves the GbE speeds significantly Huh? What are you referring to? Using a LiPo battery connected to the battery port together with mains or using a battery connected to DC-IN? Also I really don't understand why two totally different issues get mixed? One is 'speed', the other seems to be a RX negotiation problem. Does anyone of those affected by the GbE negotiation problem used a sniffer in between to get an idea what might be wrong?
08-29-2016, 05:32 AM
(This post was last modified: 08-29-2016, 05:32 AM by MarkHaysHarris777.)
(08-29-2016, 05:19 AM)tkaiser Wrote:(08-29-2016, 04:17 AM)MarkHaysHarris777 Wrote: We already know that powering the PineA64 board with the battery improves the GbE speeds significantly hi tkaisser, if I use my LiPo battery my speeds (mb/s) almost double, on the board that works (this is reproducible); from 280-290 mb/s jumps up to almost 660+ mb/s. We are mixing issues because everyone is guessing. In my case the one board works very well... the other board does not work at all... maybe 1.2 mb/s Both boards work brilliantly at 10/100. The problem follows the board, not the image... it is hardware related for sure. I will be posting my results to the poll shortly.
marcushh777
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! )
Well, mixing issues and not monitoring what happens will successfully prevent finding a solution
 Regarding 'speed' it's necessary to rule out the obvious problems leading to bad iperf performance numbers (iperf being a problem itself here). We already know how CPU bound iperf is so without checking cpufreq and CPU utilization all you generate are useless numbers when posting throughput results. So at least ensure you're using performance governor (I wouldn't use any of the other longsleep optimizations since they lead to a huge variation in numbers which makes it pretty hard to interpret results while they improve overall performance for sure). Minimum requirements for any test are 3 SSH/Terminal sessions, one running htop, the other longsleep's pine64_health.sh script (sudo watch -n1 pine64_health.sh) and the 3rd with iperf3. And the following line in /etc/rc.local prior to 'exit 0': Code: (sleep 30 && echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor) &(the 'sleep 30' will ensure that the board will switch to performance governor even if the distro used installed/uses cpufrequtils -- in that case adjusting defaults in /etc/defaults/cpufrequtils should also work). There are so many crappy OS images for Pine64 around that without running htop and pine64_health.sh it's simply impossible to tell why iperf results are low. Please remember: there are still even OS images around that use horribly outdated kernels and old throttling settings. So when you run such an OS image and your board overheated sometimes between now and the last boot, then chances are great that not 4 CPU cores are active any more but maybe just one. pine64_health.sh will tell you what's going on and by looking at htop output you get an idea whether iperf is currently maxing out one CPU core or not. The best idea is of course to stop using OS images that are known to cause problems (see the 'same MAC address' issue) but instead use longsleep's original Ubuntu image -- not the one from pine64 download section but the real one from http://forum.pine64.org/showthread.php?tid=376 or Armbian/Xenial (then you would use 'sudo armbianmonitor -m' to monitor board behaviour) If you then get a difference of 280-290 mb/s vs 660+ mb/s with battery or not while htop output shows that iperf is not maxing out a CPU core and pine64_health.sh output tells you you're running with 1152 MHz clockspeed and all 4 CPU cores are active then it gets interesting. Otherwise not. Regarding the GbE negotiation problem... well, switching from GbE to Fast Ethernet changes two completely different and unrelated things: consumption of the board drops by 350 mW (that might be related to powering problems, most probably undervoltage which could be measured on test points or at least on Euler pins 4/6 if still powering through Micro USB) and Fast Ethernet does not use 2 of the 4 cable pairs so only pins 1,2,3,6 are used (they are all meant to send/receive data unidirectional while 4,5,7,8 are bidirectional) So if the workaround 'force Fast Ethernet' is working we're talking about something completely different, it's simply a different mode and both Pine64 and switch/hub/host connected to behave completely different. Don't look at iperf numbers that now tell something like 94 Mbits/sec and think about performance numbers. It's an entirely other mode, just a workaround and does not help to solve the real problem at all. Regarding this 'real problem' it needs to be confirmed whether that's always an RX GbE negotiation problem or not (so does the problem always occur when testing in the same directions or do boards behave differently?). And then I would suspect it's pretty hard to get a clue without a real sniffer between Pine64 and the switch used. Just as an example: another sunxi board (Lime2 from Olimex) shows very instable GbE links with most GbE switches in default slave mode (of course forcing the Lime2 to use Fast Ethernet workarounded the whole problem successfully) unless u-boot is patched to force the PHY into master mode: http://forum.armbian.com/index.php/topic...#entry7491 (the drawback is that with applied patch the board can not negotiate a GBit Ethernet connection with another device also forced to master mode) Maybe it's just something like this (at least one board showing this behaviour worked flawlessly when being sent to longsleep in his environment). Maybe it's a combination of more issues (you reported that the area around the RTL8211E looks different on all your 3 boards) but without some methodology and differentiating between 'general' GbE speed issues and this specific negotiation problem I don't believe there will be any progress.
08-29-2016, 01:41 PM
(This post was last modified: 08-29-2016, 02:02 PM by MarkHaysHarris777.)
@tkaiser, what is your solution?
... a zillion words that basically boil down to you're guessing too. Almost all of what you have said (at this point) is not relevant. I'm not talking about tuning. At this point I'm talking about having two theoretically 'same' boards running two different exactly same images-- one works brilliantly, one does not work at all. There is only one conclusion: one piece of hardware is dramatically different! What is the difference? This is NOT a software issue. Its a hardware problem (granted affected by the software) but its a hardware specific problem. Every one of my "crappy" images runs GbE brilliantly on one board. None of them run on the other (I'm speaking of GbE here, of course)... and performance is intermittent / that is always hardware.
marcushh777
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! ) |
