(11-06-2016, 08:24 PM)stepw Wrote: (11-06-2016, 06:35 AM)MarkHaysHarris777 Wrote: (11-03-2016, 10:43 AM)waldo Wrote: What is the difference between the HW method and the SW patch ?
What we are trying to do is to enable only the Tx-delay and to disable ONLY the Rx-delay. Both approaches are a hardware solution ; one sets the GMAC register with a program call ( this uses the longsleep kernel patch to achieve the hardware result ) , and the other uses a physical resistor on the board to 'pull-down' the line to ground which will also afffect the same hardward change -- namely , the Rx-delay will be disabled and only the Tx-delay will be enabled.
This either works or it doesn't. It is sad to hear that register setting is not working for people; I am preparing to implement the resistor fix on my ubuntu board ( my non working board ); I'll be reporting back here with the results soon. In the mean time it would be interesting to note which ones ( if any ) the register setting to disable the Rx-delay is actually working in the field.
Twleve out of twelve boards were 'fixed' in the lab by setting the register; so something is 'off' in the field. Just a note, setting Rx-delay = 0 does not work since that setting still results in a 2ns delay regardless; the Rx-delay actually has to be disabled.
It's actually PHY register, not GMAC register. It's controlled by GMAC via MII though.
BTW, it looks like "magic" CONFREG value 0xd591 disables BOTH TX and RX delay; per RTL8211E datasheet bit 1 controls TX delay state and bit 2 controls RX delay state and 0xd591 disables both by writing zero to those bits. Interestingly, datasheet defines only 9 bits (corresponding to 9 CONFIG pins on the PHY IC), but upper byte is also modified beyond its lowest bit when CONFREG is changed in longsleep's patch (which is ultimately supplied by Pine64 engineering).
If only bits 1 and 2 are modified in the CONFREG, it doesn't make any difference in terms of Gigabit performance on my Pine64. So there seems to be some significance behind changes in (undocumented) upper byte of CONFREG or bits other than 1 and 2 of the lower byte.
It would be great if Pine64 could disclose specific details of what this CONFREG change achieves, beyond sharing the sequence of MII register writes which is expected to fix the issue.
(11-06-2016, 11:44 AM)seaniefs Wrote: OK - I think in my case this is the same issue which is being exhibited in a different way.
If I connect directly from my laptop to my main router wirelessly and ping the pine64 (which is connected to the router via ethernet and configured to run at 10/100mbs) I get packet loss of about 5%.
However, if I introduce an extra 'hop' by ensuring the laptop connects to a wireless extender and repeat the test, then I do not seem to get any packet loss so far.
I think that the extra delay introduced by the wireless extender is masking the problem...?
It's probably best to test from a directly connected wired device rather than a host multiple wired/wireless segments away...
The value provided by Realtek folks when we work with them. We don't have the additional information beyond the datasheet. However, we will explore further with the Realtek engineer.
(11-06-2016, 06:35 AM)MarkHaysHarris777 Wrote: (11-03-2016, 10:43 AM)waldo Wrote: What is the difference between the HW method and the SW patch ?
What we are trying to do is to enable only the Tx-delay and to disable ONLY the Rx-delay. Both approaches are a hardware solution ; one sets the GMAC register with a program call ( this uses the longsleep kernel patch to achieve the hardware result ) , and the other uses a physical resistor on the board to 'pull-down' the line to ground which will also afffect the same hardward change -- namely , the Rx-delay will be disabled and only the Tx-delay will be enabled.
This either works or it doesn't. It is sad to hear that register setting is not working for people; I am preparing to implement the resistor fix on my ubuntu board ( my non working board ); I'll be reporting back here with the results soon. In the mean time it would be interesting to note which ones ( if any ) the register setting to disable the Rx-delay is actually working in the field.
Twleve out of twelve boards were 'fixed' in the lab by setting the register; so something is 'off' in the field. Just a note, setting Rx-delay = 0 does not work since that setting still results in a 2ns delay regardless; the Rx-delay actually has to be disabled. it occurs to me that using a program call to set a hardware register is a software solution. that , to me, is one of the basic reasons/purposes of software, the manipulation of the present hardware to achieve a goal. can you explain to me why it is not? thanks.
(11-07-2016, 12:23 AM)dkryder Wrote: it occurs to me that using a program call to set a hardware register is a software solution. that , to me, is one of the basic reasons/purposes of software, the manipulation of the present hardware to achieve a goal. can you explain to me why it is not? thanks.
I suspect it was just not the best phrasing... both approaches are related to hardware - it isn't a software bug per se that needs to be fixed - there's no magic bit of translation software that needs to get changed, but some sort of conflict with the hardware chip. The parameters of the chip can either be set with physical resistors (negating need for registers to be set via software), or can be set with software (negating the needs to have resistors used to set the registers). That's my understanding of the situation anyway.
(11-10-2016, 07:46 PM)pfeerick Wrote: (11-07-2016, 12:23 AM)dkryder Wrote: it occurs to me that using a program call to set a hardware register is a software solution. that , to me, is one of the basic reasons/purposes of software, the manipulation of the present hardware to achieve a goal. can you explain to me why it is not? thanks.
I suspect it was just not the best phrasing... both approaches are related to hardware - it isn't a software bug per se that needs to be fixed - there's no magic bit of translation software that needs to get changed, but some sort of conflict with the hardware chip. The parameters of the chip can either be set with physical resistors (negating need for registers to be set via software), or can be set with software (negating the needs to have resistors used to set the registers). That's my understanding of the situation anyway.
Yes, Pete, you are correct.
Another thing to add is that with modern hardware ( hardware may be programmed ). No, programming hardware is NOT software. Back in the day IBM used to call this micro-code, and more recently we refer to it as firmware; but its essentially "hardware" in that within its register configuration it does one thing or another, but is NOT turing complete meaning that it could do 'anything' or another. The idea here is that ( however it happens ) the hardware setting Rx-delay must be disabled ! We may disable it with a pulldown resistor ( hardware ) or we may disable it by setting a hardware register ( also 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! )
Have we heard anything from manufacturer yet, regarding the GbE issue on new boards? Has this finally been fixed?
I'm hoping that the board I ordered this morning will not be affected by the issue.
(12-16-2016, 06:32 AM)Learnincurve Wrote: Have we heard anything from manufacturer yet, regarding the GbE issue on new boards? Has this finally been fixed?
I'm hoping that the board I ordered this morning will not be affected by the issue.
The GbE issue should has been resolved. The new Android (both Pine64 and Ayufan) and Ubuntu builds have been released. Please download and check out.
(12-16-2016, 09:05 PM)tllim Wrote: (12-16-2016, 06:32 AM)Learnincurve Wrote: Have we heard anything from manufacturer yet, regarding the GbE issue on new boards? Has this finally been fixed?
I'm hoping that the board I ordered this morning will not be affected by the issue.
The GbE issue should has been resolved. The new Android (both Pine64 and Ayufan) and Ubuntu builds have been released. Please download and check out.
I can confirm that at least for me (having a long time problems with this issue) now with the actual kernel by @ longsleep all is working fine!
So in the end its a real GbE board now!
Still a linux newbie with several EEE-PCs, PI's, LattePanda and some Desktops/Laptops running Win10. Now also proudly using Pine64+ 2GB and gigabit LAN
I can confirm too that now I get decent speeds with GbE using latest longsleep kernel. Good job!
Pine64+ 2GB
I have a pair of 2GB Pine64 boards. One board (Pine64_B) fairs poorly on the iperf3 send test at under 300Mb/s (a large improvement) while achieving over 800Mb/s receiving. The other board (Pine64_A) exceeds 800Mb/s in Tx and Rx. Outwardly, these boards are indistinguishable, same date code, revision, and both lack a serial number on the bottom.
I have conducted the iperf tests using Gentoo linux with longsleep's current kernel and confirmed the poor results on Pine64_B with an Ubuntu base image (avg 333Mb/s). Tests were rerun after swapping the ethernet patch cables between boards to confirm the problem is the 'B' board. USB power cables and power supplies are over spec'ed (5VDC, >2amp).
For me this is not a solved issue. Worse, I had thought about buying another board or two but wonder if I'd get another 'B' board.
Thanks,
HenryD
Code: Pine64_A gentoo # iperf3 -sV
iperf 3.1.4
Linux Pine64_A 3.10.104-2-pine64-longsleep #113 SMP PREEMPT Thu Dec 15 21:46:07 CET 2016 aarch64
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Time: Wed, 28 Dec 2016 14:55:23 GMT
Accepted connection from 192.168.1.163, port 59894
Cookie: nehalem.1482936923.145601.313dc79138
TCP MSS: 1448 (default)
[ 5] local 192.168.1.184 port 5201 connected to 192.168.1.163 port 59896
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 96.7 MBytes 809 Mbits/sec
[ 5] 1.00-2.00 sec 99.9 MBytes 838 Mbits/sec
[ 5] 2.00-3.00 sec 99.2 MBytes 832 Mbits/sec
[ 5] 3.00-4.00 sec 99.9 MBytes 838 Mbits/sec
[ 5] 4.00-5.00 sec 99.9 MBytes 838 Mbits/sec
[ 5] 5.00-6.00 sec 99.3 MBytes 833 Mbits/sec
[ 5] 6.00-7.00 sec 100 MBytes 842 Mbits/sec
[ 5] 7.00-8.00 sec 99.6 MBytes 835 Mbits/sec
[ 5] 8.00-9.00 sec 100 MBytes 840 Mbits/sec
[ 5] 9.00-10.00 sec 100 MBytes 841 Mbits/sec
[ 5] 10.00-10.03 sec 3.00 MBytes 812 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-10.03 sec 0.00 Bytes 0.00 bits/sec sender
[ 5] 0.00-10.03 sec 998 MBytes 834 Mbits/sec receiver
CPU Utilization: local/receiver 39.5% (0.4%u/39.1%s), remote/sender 0.0% (0.0%u/0.0%s)
rcv_tcp_congestion cubic
iperf 3.1.4
Linux Pine64_A 3.10.104-2-pine64-longsleep #113 SMP PREEMPT Thu Dec 15 21:46:07 CET 2016 aarch64
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Time: Wed, 28 Dec 2016 14:55:45 GMT
Accepted connection from 192.168.1.163, port 59898
Cookie: nehalem.1482936945.361608.6941393051
TCP MSS: 1448 (default)
[ 5] local 192.168.1.184 port 5201 connected to 192.168.1.163 port 59900
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 5] 0.00-1.02 sec 104 MBytes 857 Mbits/sec 0 219 KBytes
[ 5] 1.02-2.01 sec 106 MBytes 896 Mbits/sec 0 222 KBytes
[ 5] 2.01-3.02 sec 108 MBytes 895 Mbits/sec 0 222 KBytes
[ 5] 3.02-4.02 sec 106 MBytes 896 Mbits/sec 0 222 KBytes
[ 5] 4.02-5.02 sec 108 MBytes 896 Mbits/sec 0 222 KBytes
[ 5] 5.02-6.01 sec 104 MBytes 877 Mbits/sec 0 222 KBytes
[ 5] 6.01-7.02 sec 108 MBytes 896 Mbits/sec 0 222 KBytes
[ 5] 7.02-8.02 sec 106 MBytes 896 Mbits/sec 0 223 KBytes
[ 5] 8.02-9.02 sec 108 MBytes 896 Mbits/sec 0 223 KBytes
[ 5] 9.02-10.00 sec 105 MBytes 896 Mbits/sec 0 225 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-10.00 sec 1.04 GBytes 890 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 0.00 Bytes 0.00 bits/sec receiver
CPU Utilization: local/sender 44.0% (0.0%u/44.0%s), remote/receiver 3.2% (0.1%u/3.0%s)
snd_tcp_congestion cubic
iperf 3.1.4
Linux Pine64_A 3.10.104-2-pine64-longsleep #113 SMP PREEMPT Thu Dec 15 21:46:07 CET 2016 aarch64
===================================================================================================================
Pine64_B gentoo # iperf3 -sV
iperf 3.1.4
Linux Pine64_B 3.10.104-2-pine64-longsleep #113 SMP PREEMPT Thu Dec 15 21:46:07 CET 2016 aarch64
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Time: Wed, 28 Dec 2016 15:04:43 GMT
Accepted connection from 192.168.1.163, port 42768
Cookie: nehalem.1482937483.873451.0f7a588834
TCP MSS: 1448 (default)
[ 5] local 192.168.1.183 port 5201 connected to 192.168.1.163 port 42770
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 96.4 MBytes 807 Mbits/sec
[ 5] 1.00-2.00 sec 99.7 MBytes 836 Mbits/sec
[ 5] 2.00-3.00 sec 99.8 MBytes 837 Mbits/sec
[ 5] 3.00-4.00 sec 99.3 MBytes 834 Mbits/sec
[ 5] 4.00-5.00 sec 99.0 MBytes 830 Mbits/sec
[ 5] 5.00-6.00 sec 99.8 MBytes 837 Mbits/sec
[ 5] 6.00-7.00 sec 99.6 MBytes 836 Mbits/sec
[ 5] 7.00-8.00 sec 99.9 MBytes 837 Mbits/sec
[ 5] 8.00-9.00 sec 99.7 MBytes 837 Mbits/sec
[ 5] 9.00-10.00 sec 99.1 MBytes 831 Mbits/sec
[ 5] 10.00-10.04 sec 3.38 MBytes 821 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-10.04 sec 0.00 Bytes 0.00 bits/sec sender
[ 5] 0.00-10.04 sec 996 MBytes 832 Mbits/sec receiver
CPU Utilization: local/receiver 57.9% (0.2%u/57.6%s), remote/sender 0.0% (0.0%u/0.0%s)
rcv_tcp_congestion cubic
iperf 3.1.4
Linux Pine64_B 3.10.104-2-pine64-longsleep #113 SMP PREEMPT Thu Dec 15 21:46:07 CET 2016 aarch64
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Time: Wed, 28 Dec 2016 15:05:01 GMT
Accepted connection from 192.168.1.163, port 42772
Cookie: nehalem.1482937501.033443.2291a8e70b
TCP MSS: 1448 (default)
[ 5] local 192.168.1.183 port 5201 connected to 192.168.1.163 port 42774
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 5] 0.00-1.00 sec 30.6 MBytes 257 Mbits/sec 133 5.66 KBytes
[ 5] 1.00-2.00 sec 31.8 MBytes 267 Mbits/sec 141 7.07 KBytes
[ 5] 2.00-3.00 sec 34.3 MBytes 287 Mbits/sec 150 8.48 KBytes
[ 5] 3.00-4.00 sec 35.9 MBytes 301 Mbits/sec 143 12.7 KBytes
[ 5] 4.00-5.00 sec 33.6 MBytes 282 Mbits/sec 115 12.7 KBytes
[ 5] 5.00-6.00 sec 28.9 MBytes 242 Mbits/sec 145 8.48 KBytes
[ 5] 6.00-7.00 sec 27.7 MBytes 232 Mbits/sec 141 7.07 KBytes
[ 5] 7.00-8.00 sec 30.3 MBytes 254 Mbits/sec 149 7.07 KBytes
[ 5] 8.00-9.00 sec 30.5 MBytes 256 Mbits/sec 139 5.66 KBytes
[ 5] 9.00-10.00 sec 29.1 MBytes 244 Mbits/sec 113 4.24 KBytes
[ 5] 10.00-10.03 sec 568 KBytes 158 Mbits/sec 3 4.24 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-10.03 sec 313 MBytes 262 Mbits/sec 1372 sender
[ 5] 0.00-10.03 sec 0.00 Bytes 0.00 bits/sec receiver
CPU Utilization: local/sender 6.3% (0.5%u/5.9%s), remote/receiver 3.2% (0.2%u/3.0%s)
snd_tcp_congestion cubic
iperf 3.1.4
Linux Pine64_B 3.10.104-2-pine64-longsleep #113 SMP PREEMPT Thu Dec 15 21:46:07 CET 2016 aarch64
01-03-2017, 10:26 PM
(This post was last modified: 01-03-2017, 11:18 PM by aegrotatio.)
Hello, I am running Armbian 5.20 Jessie and have tried all sorts of iperf3 permutations, like parallel, single, large and small packets. With iperf3 server on the PINE A64, and I am consistently seeing above 900 MBytes/sec and sometimes 1 GBytes/sec. When iperf3 client is run on the PINE A64, I get a higher number of "Retr" but speeds remain between 850 MBytes/sec and 900 MBytes/sec. I'm not sure that could indicate a problem, but my network isn't all that quiet.
I have an original Kickstarter PINE A64+ with 2 GB. The one thing that I can tell you that is different from most other SBC users is that I use a 3.5 Amp micro-USB power supply from PWR+. These were designed for that short-lived generation of netbooks that were powered by micro-USB. They are still widely available. I use them on other SBCs with lots of bus-powered peripherals and fans hanging off them, too, with no undervoltage or corruption problems.
*EDIT*: I just tried 5.24 Xenial and the numbers increased about 3% higher with far fewer retries, too, but that is probably the multi-threading happening there.
|
