LAN/NIC problem

[waldo]

Iperf shows bandwidth from client to server, so it looks like RX is still far off from GbE, but at least now my board is useable .... maybe we can tweak this further now ?
ubuntu@pine64:~$ iperf3 -c Waldo-DesktopL -P4
[SUM]   0.00-10.01  sec   915 MBytes   767 Mbits/sec                  receiver

waldo@Waldo-DesktopL:~$ iperf3 -c Pine64 -P4
[SUM]   0.00-10.00  sec   335 MBytes   281 Mbits/sec                  receiver


I'm coming from a situation where the onboard NIC would just crap out in GbE so this is a whole lot better

edit: just a remark .... in trying to tune somewhat further i applied 
https://raw.githubusercontent.com/longsl...network.sh
which longsleep advises in http://forum.pine64.org/showthread.php?tid=2052 

I get consistent worse  RX results after running the tuning script, TX remains the same
[SUM]   0.00-10.00  sec   189 MBytes   158 Mbits/sec                  receiver
instead of the 281 before

[tllim]

Wow, 0x28 PHY/MII register doesn't even exist, so  phy_write(phydev, 0x28, 0xd591);//only enable TX. call is not valid

According to longsleep's driver patch, the following calls are actually used:

Code:

+ phy_write(phydev, 0x1f, 0x0007);//sel ext page
+ phy_write(phydev, 0x1e, 0x00a4);//sel page 164
+ phy_write(phydev, 0x1c, 0xd591);//only enable TX
+ phy_write(phydev, 0x1f, 0x0000);//sel page 0

That sequence is more feasible and does appear to improve TX performance, but RX is still garbage on my Pine64.

My iperf3 tests under armbian:

100Mbps link:
Pine64->PC
TCP: 96Mbps
UDP: 96Mbps generated 96Mbps received

PC->Pine64
TCP: 96Mbps
UDP: 96Mbps generated 96Mbps received


1Gbps link, with RX/TX delay (e.g. CONFREG = 0x8577 = 0b1000010101110111)
Pine64->PC
TCP: 500kbps
UDP: 670Mbps generated 50Mbps received

PC->Pine64
TCP: 1.16kbps
UDP: 900Mbps generated 0kbps received


1Gbps link, without RX/TX delay (e.g. CONFREG = 0xd591 = 0b1101010110010001)
Pine64->PC
TCP: 500Mbps
UDP: 690Mbps generated 690Mbps received

PC->Pine64
TCP: 1.5Mbps
UDP: 900Mbps generated 20Mbps received


Interestingly, some of the changed CONFREG bits are not even in Realtek's data sheet. Changing TX/RX delay (bits 1 and 2) alone doesn't make a difference. This still doesn't look like something that can be fixed in software

Sorry, should be 0x1C which is 28.

[tllim]

Here is the drawings for adjust LED2_RXDLY line pull up resistor GR70 to pull low position GR69. This hardware method disable the RX_DLY. Interesting parties can try out. 



[img] http://files.pine64.org/doc/photo/GbE%20..._DLY-2.jpg[/img]

[tllim]

Here is the drawings for adjust LED2_RXDLY line pull up resistor GR70 to pull low position GR69. This hardware method disable the RX_DLY. Interesting parties can try out. 



[img] http://files.pine64.org/doc/photo/GbE%20..._DLY-2.jpg[/img]

[umiddelb]

The patch doesn't work for my board ...

[waldo]

What is the difference between the HW method and the SW patch ?

[seaniefs]

Hi there,

Firstly, thanks to everyone for their hard work on this issue (longsleep, tlim and others) - it's much appreciated.

Sadly, however I still get packet loss on my board even when using the latest longsleep default or gbe kernels in 10/100 mode, although the settings suggested in pine64_tune_network.sh do help somewhat.

Gigabit is so unreliable for me that it's not worth using as it eventually stops working completely. Even on 10/100 I get about 5% packet loss on average in ping tests. 

I don't get packet loss on any other devices on my LAN when doing the same tests, so can only conclude it's the pine64 at fault.

Just wondering if there's anything else I can try to reduce the packet loss?

Many thanks,

Sean.

[MarkHaysHarris777]

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.

[seaniefs]

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

[stepw]

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. 

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