PINE64
LAN/NIC problem - Printable Version

+- PINE64 (https://forum.pine64.org)
+-- Forum: PINE A64(+) (https://forum.pine64.org/forumdisplay.php?fid=4)
+--- Forum: Pine A64 Hardware, Accessories and POT (https://forum.pine64.org/forumdisplay.php?fid=32)
+---- Forum: Ethernet Port (https://forum.pine64.org/forumdisplay.php?fid=39)
+---- Thread: LAN/NIC problem (/showthread.php?tid=835)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

RE: LAN/NIC problem - tllim - 11-06-2016

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

RE: LAN/NIC problem - dkryder - 11-07-2016

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

RE: LAN/NIC problem - pfeerick - 11-10-2016

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

RE: LAN/NIC problem - MarkHaysHarris777 - 11-10-2016

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

RE: LAN/NIC problem - Learnincurve - 12-16-2016

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.

RE: LAN/NIC problem - tllim - 12-16-2016

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

RE: LAN/NIC problem - androsch - 12-17-2016

(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!

RE: LAN/NIC problem - Er0l - 12-20-2016

I can confirm too that now I get decent speeds with GbE using latest longsleep kernel. Good job!

RE: LAN/NIC problem - HenryD - 12-28-2016

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


RE: LAN/NIC problem - aegrotatio - 01-03-2017

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.