Kinda upset at the lack of response to GBe issues
(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.


Attached Files Thumbnail(s)
   
  Reply
(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).

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.

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..

Sad
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
(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).

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.

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..

Sad

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 Wink
  Reply
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.

#######################################
Data
#######################################

###############
BOARD "B" specs

1) Pine64+ 2Gb with wifi/BT 201-A64DB110-02 A64-DB-V1.1 2G C106358 04.10
2) RTL chip numbers:  RTL8211E G3E16P1 GG12B
###############

###############
BOARD "A" specs

1) Pine64+ 2Gb with wifi/BT 201-A64DB110-02 A64-DB-V1.1 2G C106358 04.12
2) RTL chip numbers:  RTL8211E G3E16P1 GG12B
###############

Network Switch used during test: TRENDnet TEG-S80g
Network cable used throughout testing is a CAT 6 cable

#############################################################################################
BOARD "A" test output running Debian
#############################################################################################

Linux pine64 3.10.102-3-pine64-longsleep #98 SMP PREEMPT Sat Aug 20 22:28:17 CEST 2016 aarch64 GNU/Linux

Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes:   10baseT/Half 10baseT/Full
                       100baseT/Half 100baseT/Full
                       1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full
                       100baseT/Half 100baseT/Full
                       1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Link detected: yes

Connecting to host 192.168.0.3, port 5201
[  4] local 192.168.0.9 port 57805 connected to 192.168.0.3 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   108 MBytes   906 Mbits/sec    0    273 KBytes      
[  4]   1.00-2.00   sec   109 MBytes   918 Mbits/sec    0    273 KBytes      
[  4]   2.00-3.01   sec   108 MBytes   902 Mbits/sec    0    273 KBytes      
[  4]   3.01-4.01   sec  93.8 MBytes   785 Mbits/sec    0    273 KBytes      
[  4]   4.01-5.00   sec  97.6 MBytes   826 Mbits/sec    0    273 KBytes      
[  4]   5.00-6.02   sec   111 MBytes   913 Mbits/sec    0    273 KBytes      
[  4]   6.02-7.01   sec  92.5 MBytes   783 Mbits/sec    0    273 KBytes      
[  4]   7.01-8.00   sec  98.0 MBytes   828 Mbits/sec    0    273 KBytes      
[  4]   8.00-9.01   sec   101 MBytes   844 Mbits/sec    0    273 KBytes      
[  4]   9.01-10.00  sec   102 MBytes   854 Mbits/sec    0    273 KBytes      
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1021 MBytes   856 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1020 MBytes   856 Mbits/sec                  receiver

iperf Done.
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.0.3, port 54294
[  5] local 192.168.0.9 port 5201 connected to 192.168.0.3 port 54295
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec   102 MBytes   853 Mbits/sec                  
[  5]   1.00-2.00   sec   112 MBytes   940 Mbits/sec                  
[  5]   2.00-3.00   sec   112 MBytes   936 Mbits/sec                  
[  5]   3.00-4.00   sec   112 MBytes   941 Mbits/sec                  
[  5]   4.00-5.00   sec   112 MBytes   938 Mbits/sec                  
[  5]   5.00-6.00   sec   112 MBytes   939 Mbits/sec                  
[  5]   6.00-7.00   sec   112 MBytes   940 Mbits/sec                  
[  5]   7.00-8.00   sec   112 MBytes   942 Mbits/sec                  
[  5]   8.00-9.00   sec   112 MBytes   942 Mbits/sec                  
[  5]   9.00-10.00  sec   111 MBytes   933 Mbits/sec                  
[  5]  10.00-10.04  sec  3.62 MBytes   727 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.04  sec  1.09 GBytes   930 Mbits/sec                  sender
[  5]   0.00-10.04  sec  1.09 GBytes   930 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------



#############################################################################################
BOARD "B" test output running Debian
#############################################################################################

Linux pine64 3.10.102-3-pine64-longsleep #98 SMP PREEMPT Sat Aug 20 22:28:17 CEST 2016 aarch64 GNU/Linux

Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes:   10baseT/Half 10baseT/Full
                       100baseT/Half 100baseT/Full
                       1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full
                       100baseT/Half 100baseT/Full
                       1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Link detected: yes

Connecting to host 192.168.0.3, port 5201
[  4] local 192.168.0.9 port 38219 connected to 192.168.0.3 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   106 MBytes   890 Mbits/sec    1   94.7 KBytes      
[  4]   1.00-2.00   sec   109 MBytes   914 Mbits/sec    0    132 KBytes      
[  4]   2.00-3.00   sec   109 MBytes   915 Mbits/sec    1    120 KBytes      
[  4]   3.00-4.00   sec  85.0 MBytes   714 Mbits/sec    2   79.2 KBytes      
[  4]   4.00-5.00   sec   108 MBytes   906 Mbits/sec    0    122 KBytes      
[  4]   5.00-6.00   sec   108 MBytes   909 Mbits/sec    2   67.9 KBytes      
[  4]   6.00-7.00   sec  79.0 MBytes   663 Mbits/sec    2   45.2 KBytes      
[  4]   7.00-8.00   sec  84.1 MBytes   705 Mbits/sec    1   82.0 KBytes      
[  4]   8.00-9.00   sec  94.3 MBytes   791 Mbits/sec    1   90.5 KBytes      
[  4]   9.00-10.00  sec   108 MBytes   904 Mbits/sec    0    129 KBytes      
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   991 MBytes   831 Mbits/sec   10             sender
[  4]   0.00-10.00  sec   991 MBytes   831 Mbits/sec                  receiver

iperf Done.
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.0.3, port 54338
[  5] local 192.168.0.9 port 5201 connected to 192.168.0.3 port 54339
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec   991 KBytes  8.12 Mbits/sec                  
[  5]   1.00-2.00   sec   978 KBytes  8.01 Mbits/sec                  
[  5]   2.00-3.00   sec  1.13 MBytes  9.52 Mbits/sec                  
[  5]   3.00-4.00   sec  1.24 MBytes  10.4 Mbits/sec                  
[  5]   4.00-5.00   sec   873 KBytes  7.15 Mbits/sec                  
[  5]   5.00-6.00   sec  75.6 KBytes   619 Kbits/sec                  
[  5]   6.00-7.00   sec   579 KBytes  4.74 Mbits/sec                  
[  5]   7.00-8.00   sec   931 KBytes  7.62 Mbits/sec                  
[  5]   8.00-9.00   sec   295 KBytes  2.42 Mbits/sec                  
[  5]   9.00-10.00  sec  1004 KBytes  8.22 Mbits/sec                  
[  5]  10.00-10.04  sec  0.00 Bytes  0.00 bits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.04  sec  8.12 MBytes  6.79 Mbits/sec                  sender
[  5]   0.00-10.04  sec  7.97 MBytes  6.66 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------


#############################################################################################
BOARD "A" test output running Ubuntu
#############################################################################################

Linux localhost.localdomain 3.10.65-7-pine64-longsleep #28 SMP PREEMPT Sat Apr 23 20:13:25 CEST 2016 aarch64 aarch64 aarch64 GNU/Linux

Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes:   10baseT/Half 10baseT/Full
                       100baseT/Half 100baseT/Full
                       1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full
                       100baseT/Half 100baseT/Full
                       1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Link detected: yes

Connecting to host 192.168.0.3, port 5201
[  4] local 192.168.0.167 port 56591 connected to 192.168.0.3 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   108 MBytes   902 Mbits/sec    0    273 KBytes      
[  4]   1.00-2.00   sec   109 MBytes   914 Mbits/sec    0    273 KBytes      
[  4]   2.00-3.00   sec   109 MBytes   918 Mbits/sec    0    273 KBytes      
[  4]   3.00-4.00   sec   109 MBytes   913 Mbits/sec    1    124 KBytes      
[  4]   4.00-5.00   sec   109 MBytes   912 Mbits/sec    0    156 KBytes      
[  4]   5.00-6.00   sec   109 MBytes   916 Mbits/sec    0    181 KBytes      
[  4]   6.00-7.00   sec   109 MBytes   912 Mbits/sec    0    201 KBytes      
[  4]   7.00-8.00   sec   109 MBytes   915 Mbits/sec    0    212 KBytes      
[  4]   8.00-9.00   sec   109 MBytes   912 Mbits/sec    0    218 KBytes      
[  4]   9.00-10.00  sec   109 MBytes   914 Mbits/sec    0    222 KBytes      
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.06 GBytes   913 Mbits/sec    1             sender
[  4]   0.00-10.00  sec  1.06 GBytes   912 Mbits/sec                  receiver

iperf Done.
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.0.3, port 54166
[  5] local 192.168.0.167 port 5201 connected to 192.168.0.3 port 54167
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec   105 MBytes   878 Mbits/sec                  
[  5]   1.00-2.00   sec   110 MBytes   920 Mbits/sec                  
[  5]   2.00-3.00   sec   111 MBytes   931 Mbits/sec                  
[  5]   3.00-4.00   sec   110 MBytes   919 Mbits/sec                  
[  5]   4.00-5.00   sec  62.8 MBytes   527 Mbits/sec                  
[  5]   5.00-6.00   sec  91.9 MBytes   771 Mbits/sec                  
[  5]   6.00-7.00   sec   101 MBytes   849 Mbits/sec                  
[  5]   7.00-8.00   sec  91.7 MBytes   769 Mbits/sec                  
[  5]   8.00-9.00   sec   110 MBytes   927 Mbits/sec                  
[  5]   9.00-10.00  sec   111 MBytes   934 Mbits/sec                  
[  5]  10.00-10.04  sec  4.65 MBytes   940 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.04  sec  1009 MBytes   843 Mbits/sec                  sender
[  5]   0.00-10.04  sec  1009 MBytes   843 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------



#############################################################################################
BOARD "B" test output running Ubuntu
#############################################################################################

Linux localhost.localdomain 3.10.65-7-pine64-longsleep #28 SMP PREEMPT Sat Apr 23 20:13:25 CEST 2016 aarch64 aarch64 aarch64 GNU/Linux

Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes:   10baseT/Half 10baseT/Full
                       100baseT/Half 100baseT/Full
                       1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full
                       100baseT/Half 100baseT/Full
                       1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Link detected: yes

Connecting to host 192.168.0.3, port 5201
[  4] local 192.168.0.167 port 56141 connected to 192.168.0.3 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.01   sec  83.2 MBytes   690 Mbits/sec    1    113 KBytes      
[  4]   1.01-2.01   sec  82.1 MBytes   693 Mbits/sec    1   99.0 KBytes      
[  4]   2.01-3.01   sec  80.8 MBytes   673 Mbits/sec    1    130 KBytes      
[  4]   3.01-4.01   sec  81.2 MBytes   684 Mbits/sec    1    130 KBytes      
[  4]   4.01-5.00   sec  80.0 MBytes   675 Mbits/sec    2    109 KBytes      
[  4]   5.00-6.01   sec  81.2 MBytes   675 Mbits/sec    1    127 KBytes      
[  4]   6.01-7.00   sec  80.0 MBytes   679 Mbits/sec    2    103 KBytes      
[  4]   7.00-8.00   sec  80.0 MBytes   670 Mbits/sec    2    119 KBytes      
[  4]   8.00-9.01   sec  82.5 MBytes   686 Mbits/sec    0    168 KBytes      
[  4]   9.01-10.01  sec  81.2 MBytes   687 Mbits/sec    3   60.8 KBytes      
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.01  sec   812 MBytes   681 Mbits/sec   14             sender
[  4]   0.00-10.01  sec   812 MBytes   681 Mbits/sec                  receiver

iperf Done.
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.0.3, port 54305
[  5] local 192.168.0.167 port 5201 connected to 192.168.0.3 port 54306
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  1.76 MBytes  14.8 Mbits/sec                  
[  5]   1.00-2.00   sec  1.35 MBytes  11.3 Mbits/sec                  
[  5]   2.00-3.00   sec  1.41 MBytes  11.8 Mbits/sec                  
[  5]   3.00-4.00   sec   210 KBytes  1.72 Mbits/sec                  
[  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  10.00-11.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  11.00-12.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  12.00-13.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  13.00-14.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  14.00-15.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  15.00-16.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  16.00-17.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  17.00-18.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  18.00-19.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  19.00-20.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  20.00-21.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  21.00-22.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  22.00-23.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  23.00-24.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  24.00-25.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  25.00-26.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  26.00-27.00  sec  0.00 Bytes  0.00 bits/sec                  
[  5]  27.00-28.00  sec  0.00 Bytes  0.00 bits/sec                  
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
  Reply
Question 
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
  Reply
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    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
(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?
  Reply
(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

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?

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    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
Well, mixing issues and not monitoring what happens will successfully prevent finding a solution Smile

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.
  Reply
@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    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


Forum Jump:


Users browsing this thread: 1 Guest(s)