Stock debian image - rock64 - gigabit

[rhille]

When using my Rock64 with Gigabit link, network connections are unstable (I even cannot get the dmesg output via ssh connection), no problem when using 100Mbit.

dmesg doesn't indicate any problem (retrieved after set port to 100 MBit)
eth0: Link is Up - 1Gbps/Full - flow control rx/tx
eth0: Link is Up - 100Mbps/Full - flow control rx/tx

Did a sudo apt-get update/upgrade which updated a couple of things but issue persist

Current setup:
Rock64 
4GB 
official debian image on SD card
emmc plugged in but not used yet.
Router/Switch: Fritzbox 6360

When using the same FritzBox port (configured as Gigabit port) with my laptop, no issue is seen.

Any ideas?

Thank you
Reinhard

[rhille]

Some iperf statistics with configured Gigabit port

Rock64 running as server iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------

[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   697 MBytes   584 Mbits/sec
[  4]  0.0-10.0 sec   690 MBytes   578 Mbits/sec
[  4]  0.0-10.0 sec   697 MBytes   584 Mbits/sec
[  4]  0.0-10.0 sec   701 MBytes   587 Mbits/sec
[  4]  0.0-10.0 sec   692 MBytes   579 Mbits/sec


Rock64 as client iperf -c my_linux_server
------------------------------------------------------------
Client connecting to my_linux_server, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   105 KBytes  85.7 Kbits/sec
[  3]  0.0-10.0 sec   102 KBytes  55.6 Kbits/sec
[  3]  0.0-10.0 sec   103 KBytes  84.6 Kbits/sec
[  3]  0.0-10.0 sec   102 KBytes  83.4 Kbits/sec
[  3]  0.0-10.0 sec   112 KBytes  91.5 Kbits/sec


Strange - isn't it?

Thx
Reinhard

[rontant]

Here is mine tested with Odroid XU4

Code:

root@rock64:/# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.5 port 5001 connected with 192.168.1.4 port 59412
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.09 GBytes   937 Mbits/sec

root@rock64:/# iperf -c 192.168.1.4
------------------------------------------------------------
Client connecting to 192.168.1.4, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.5 port 47212 connected with 192.168.1.4 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   970 MBytes   813 Mbits/sec

Make sure you use proper ethernet cable at least CAT 6 type.

Rock64 2GB version.
Ayufan Debian Stretch Minimal
Router: Asus 1200G+

[rhille]

Hello rontant,

thanks again for your helpful info.
So this means there is no general issue and must be something on my side.

Do you really think a defect ethernet cable could explain such data?
I mean, the same cable was used when having ~600 Megabit throughput
and only ~80 Kilobit throughput. It looks like I can do this test again and again
and statistics doesn't change. When rock64 is used in client mode I do get the ~80Kb
and when used in server mode iperf reports ~600Mb. Nevertheless, I replaced
the cat6 cables with brandnew cat7 cables but result is still the same.

In the meantime I installed tcpdump on the rock64 and will do some network tracing to see
if I can figure out what's going on here. To be honest, I'm suspecting some duplex issue.
Hopefully I can get my hands on some gigabit switch to see if the fritzbox is the source of the 
problem or not.

If you or anyone else has some other ideas how to find out what could have caused this issue,
I appreciate your help.

Thank you
Reinhard

[MarkHaysHarris777]

Gbe is not supported on Android yet;

... you have two options for the time being:

1)  change the config in your switch and limit the port speed to 100M/s 

2)  modify your cat5 or cat6 cable ( open the cable sheath ) and clip (yes cut) the blue and the brown pairs


Modifying the cable forces 10|100 on your switch,  and the Android on Rock64 will work fine !

[rhille]

Hello MarkHaysHarris777,

thank you very much for tip but I'm not using Android image,
I installed the debian stock image and yes, when configuring
the port to 100 MBit I don't have any issues. Could it be that
the same problem exists on Linux and Android image?
But if so, how could it be that rontant doesn't have this problem?

Thx
Reinhard

[MarkHaysHarris777]

Hello MarkHaysHarris777,

thank you very much for tip but I'm not using Android image,
I installed the debian stock image and yes, when configuring
the port to 100 MBit I don't have any issues. Could it be that
the same problem exists on Linux and Android image?
But if so, how could it be that rontant doesn't have this problem?

Thx
Reinhard

Its going to depend on the image, the board level, and the PHY chip that was selected for that board(s).



This is like "dejavu" ;  we had a similar issue with the PineA64 too;

[rontant]

Rhile, would  you mind showing the results of 'uname -a' and 'lsb_release -d' ?

Here is mine:

Code:

rock64@rock64:~$ uname -a
Linux rock64 4.4.70-rockchip-ayufan-89 #1 SMP Sun Aug 20 13:29:12 UTC 2017 aarch64 GNU/Linux
rock64@rock64:~$ lsb_release -d
Description:    Debian GNU/Linux 9.1 (stretch)

[rhille]

Rhile, would  you mind showing the results of 'uname -a' and 'lsb_release -d' ?

Here is mine:

Code:

rock64@rock64:~$ uname -a
Linux rock64 4.4.70-rockchip-ayufan-89 #1 SMP Sun Aug 20 13:29:12 UTC 2017 aarch64 GNU/Linux
rock64@rock64:~$ lsb_release -d
Description:    Debian GNU/Linux 9.1 (stretch)

No problem

linaro@therock:~$ uname -a
Linux therock 4.4.70 #1 SMP Tue Jul 18 15:18:26 MYT 2017 aarch64 GNU/Linux
linaro@therock:~$ lsb_release -d
Description: Debian GNU/Linux 9.1 (stretch)
linaro@therock:~$ 

@MarkHaysHarris777,
>Its going to depend on the image, the board level, and the PHY chip that was selected for that board(s).

May I ask what PHY stands for? Is it short for physical? Or another term for network chip?

Thank you
Reinhard

[MarkHaysHarris777]

@MarkHaysHarris777,
>Its going to depend on the image, the board level, and the PHY chip that was selected for that board(s).

May I ask what PHY stands for? Is it short for physical? Or another term for network chip?

https://en.wikipedia.org/wiki/PHY_(chip)