Ethernet Slow Download

[cdslashetc]

Has anyone tried a crossover connection? That would rule in or out network equipment as related to the problem. Will give that a try this upcoming weekend.

I did notice that running iperf with both client and server on the same Layer 2 switch I got 25 Mb/s still slow but not sub 1 Mb/s I was getting from the Internet.

Sent from my Nexus 6 using Tapatalk

[cdslashetc]

$15.99 Zettaguard USB 2.0 works with smsc75xx driver but upload seems relatively slow.

https://www.amazon.com/gp/product/B01A58...UTF8&psc=1

root@p64e:~# iperf -c 192.168.86.121 -t 60
------------------------------------------------------------
Client connecting to 192.168.86.121, TCP port 5001
TCP window size: 22.5 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.86.118 port 53949 connected with 192.168.86.121 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 817 MBytes 114 Mbits/sec
root@p64e:~# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.86.118 port 5001 connected with 192.168.86.121 port 51063
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-60.0 sec 2.29 GBytes 327 Mbits/sec

[cdslashetc]

I tested a crossover connection between MacBook Pro Thunderbolt gigabit adapter and Pine 64. Performance is definitely better, but still sub par at 126 Mbits/sec.

root@p64e:~# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 10.11.12.2 port 5001 connected with 10.11.12.1 port 52160
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-60.0 sec 899 MBytes 126 Mbits/sec
root@p64e:~# iperf -c 10.11.12.1 -t 60
------------------------------------------------------------
Client connecting to 10.11.12.1, TCP port 5001
TCP window size: 22.5 KByte (default)
------------------------------------------------------------
[ 3] local 10.11.12.2 port 42783 connected with 10.11.12.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 5.83 GBytes 834 Mbits/sec

[cdslashetc]

I think the best performance so far is with the more expensive Plugable device.

It's interesting that in general either RX or TX is close to 100 Mb/s and the other will be 300+ Mb/s, but it's not always the same direction. In other words, USB is a solution to get better performance in one direction, but the other performs comparable to the built-in gigabit reduced to 100 Mb/s.

$13.99 TECHTOO USB 3.0/2.0 with AX88179

https://www.amazon.com/gp/product/B00N10...UTF8&psc=1

ubuntu@p64e:~$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.86.104 port 5001 connected with 192.168.86.121 port 49918
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-60.0 sec 673 MBytes 94.0 Mbits/sec
ubuntu@p64e:~$ iperf -c 192.168.86.121 -t 60
------------------------------------------------------------
Client connecting to 192.168.86.121, TCP port 5001
TCP window size: 22.5 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.86.104 port 46200 connected with 192.168.86.121 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 1.95 GBytes 279 Mbits/sec

---

I got the $13.99 V.TOP working and it has the best performance overall in both directions. So, in short, this would be the device I would choose for additional gigabit connections.

The trick was it came up with the new style device names like enx000fc910f606 in fact some of the other USB dongles did the same. I was able to discover the device names via "ifconfig -a".

root@p64e:~# logout
ubuntu@p64e:~$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.86.123 port 5001 connected with 192.168.86.121 port 50335
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-60.0 sec 2.29 GBytes 327 Mbits/sec
ubuntu@p64e:~$ iperf -c 192.168.86.121 -t 60
------------------------------------------------------------
Client connecting to 192.168.86.121, TCP port 5001
TCP window size: 22.5 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.86.123 port 42129 connected with 192.168.86.121 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 1.95 GBytes 279 Mbits/sec

[waldo]

We should really stop using Iperf as a tool to test this issue ...
i've proven before that I could tweak the rx/tx delay to reach 926mbit with Iperf, but once i started downloading something from a local HTTP server, i got a few Kbps

[dkryder]

this rj45 has decent speeds, seems faster than port on board, is usb3 although i'm not sure if anything on rj45 is gained by that, is recognized by debian build at plug-in.
https://www.amazon.com/gp/product/B0178H...UTF8&psc=1

[cdslashetc]

We should really stop using Iperf as a tool to test this issue ...
i've proven before that I could tweak the rx/tx delay to reach 926mbit with Iperf, but once i started downloading something from a local HTTP server, i got a few Kbps

I noticed while I got 125 Mb/s from iperf with the adapter at 1000 I too was only getting a few Kbps by other means. I can't help but feel that is a clue to the nature of the problem, have been trying to remember other situations where I observed similar behavior. I remember similar behavior with a SonicWALL transparent DMZ several years ago, if I could only remember the details.

wget or curl might be good options. I also like to use mbuffer with -I and -O options a bit like netcat/nc but it can be set to load the file in memory to take storage access speed out of the equation.

speedtest-cli works pretty well for testing Internet speed, knowing that it may be limited by the speed of the connection itself.

https://www.howtoforge.com/tutorial/chec...on-ubuntu/

https://github.com/sivel/speedtest-cli

[waldo]

I have one working board and one broken one ; I've been playing around with the rx tx values.
Results are attached ...  The Pine stopped rebooting at 1 1, didn't have a monitor attached so don't know why.

The wget and iperf are from a local apache server capable of delivering over 70 MByte/s http no problem

 The good results for tx1rx1 had me hopefull but those were clearly just a fluke. Tried them again afterwards ... no luck.

I'm beginning to think there might be no software quickfix for this issue.
Anyone willing to prove me wrong ... be my guest; my script is attached too, haven't gone above 1 x 3 yet.
(Just add a line to /etc/rc.local containing the scripts location)

Godspeed

Code:

#!/bin/bash

sleep 1m

RX=$(cat /sys/module/sunxi_gmac/parameters/rx_delay)
TX=$(cat /sys/module/sunxi_gmac/parameters/tx_delay)
tx)



date > /root/r${RX}_t${TX}.txt
ethtool eth0 >> /root/r${RX}_t${TX}.txt
timeout -k 70s 68s iperf  -c 192.168.1.230 -t60 >> /root/r${RX}_t${TX}.txt
timeout -k 70s 60s wget --output-document=/dev/null http://192.168.1.230/test.img 2>&1 | grep % >> /root/r${RX}_t${TX}.txt
dmesg | tail -n 30 >> /root/r${RX}_t${TX}.txt
ifconfig eth0 >> /root/r${RX}_t${TX}.txt



if [ $RX -eq 31 ] && [  $TX -eq 7 ]; then
exit 1
fi

if [  $TX -eq 7 ]; then
 TX="0"
 ((RX++))
else
 ((TX++))
fi


# 2806                         tx-delay = <0x1>;   =>0-7
# 2807                         rx-delay = <0x0>;   =>0-31
sed -i '2806s/.*/                         tx-delay = <0x'$(printf "%X" $TX)'>;/' /boot/pine64/sun50i-a64-pine64-plus.dts
sed -i '2807s/.*/                         rx-delay = <0x'$(printf "%X" $RX)'>;/' /boot/pine64/sun50i-a64-pine64-plus.dts
dtc -I dts -O dtb -o /boot/pine64/sun50i-a64-pine64-plus.dtb /boot/pine64/sun50i-a64-pine64-plus.dts
reboot
#echo b > /proc/sysrq-trigger

Needs some explanation from http://forum.pine64.org/showthread.php?t...2#pid16062

My post on this issue in one of the many threads about this issue

[nSkaarup]

(please use proper cables....).

Kinda regret not thinking about this before, Went from 8Mbit upload on the pine64+ 2gb to 800Mbit by using a different cable thanks!

got 800/800Mbit now, but fluctuates slightly between 550-900, but is mostly around 750-850Mbit

[cdslashetc]

(please use proper cables....).

Kinda regret not thinking about this before, Went from 8Mbit upload on the pine64+ 2gb to 800Mbit by using a different cable thanks!

got 800/800Mbit now, but fluctuates slightly between 550-900, but is mostly around 750-850Mbit

I tried a mix of CAT6, CAT5e and CAT5 from 1m to 5m and CAT5e crossover to a laptop.

Sent from my Nexus 6 using Tapatalk