Ethernet Slow Download
#51
Thank you for the feedback!

And I had foolishly hoped for an inexpensive mini computer. Wink

I'm already at $100cdn per box, and somewhat loathe to spend more, so am against the USB solution though it would be fast enough for my needs.

Learning Android on the other hand, is a rabbit hole a colleague of mine described as deep, but with an end to it eventually.

I have home renos underway, so unless there are "hour hear hour there" kind of tasks I can help with, I will have to wait patiently for the primer...

Thank you again!
E
  Reply
#52
OK, let me give you a short walk-through at what I did:

TEST AT YOUR OWN RISK!

Make sure you have up-to-date kernel and u-boot first!

The tx- / rx- delay settings live in the devicetree file which describes your hardware (board) to the Linux kernel and configures besides many other things which drivers are used and how...

Set up a way to test your Ethernet performance against a fast machine (not a NAS or some other embedded device), I use a Windows box here on the same switch (Netgear GS716Tv3) with fully shielded CAT6 S/FTP patch cables of 3m length (please use proper cables....).

Using iperf3 on Windows as a server:


Code:
c:\iperf-3.1.3-win64>iperf3.exe -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

Using iperf3 on the Pine64 as client: (switch out 192.168.1.107 for your test server's IP address...)

Code:
debian@pine64:/boot/pine64$ iperf3 -c 192.168.1.107 -p 5201
Connecting to host 192.168.1.107, port 5201
[  4] local 192.168.1.116 port 57451 connected to 192.168.1.107 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  52.5 MBytes   441 Mbits/sec    0    243 KBytes
[  4]   1.00-2.01   sec  78.9 MBytes   652 Mbits/sec    0    273 KBytes
[  4]   2.01-3.00   sec  82.4 MBytes   701 Mbits/sec    0    273 KBytes
[  4]   3.00-4.01   sec   105 MBytes   873 Mbits/sec    0    273 KBytes
[  4]   4.01-5.01   sec   106 MBytes   892 Mbits/sec    0    273 KBytes
[  4]   5.01-6.01   sec   106 MBytes   886 Mbits/sec    0    273 KBytes
[  4]   6.01-7.02   sec   107 MBytes   889 Mbits/sec    0    273 KBytes
[  4]   7.02-8.00   sec   105 MBytes   889 Mbits/sec    0    273 KBytes
[  4]   8.00-9.00   sec   106 MBytes   888 Mbits/sec    0    273 KBytes
[  4]   9.00-10.01  sec   107 MBytes   888 Mbits/sec    0    273 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.01  sec   955 MBytes   800 Mbits/sec    0    sender
[  4]   0.00-10.01  sec   955 MBytes   800 Mbits/sec         receiver

As you can see, results are pretty good, we are getting about 800Mbit/s here, this is sending data towards the Windows box, so we want to adjust tx-delay if we get bad results (as opposed to the values shown above)...

The devicetree files are located in /boot/pine64/ , we are looking for sun50i-a64-pine64-plus.dtb which is the binary, compiled devicetree blob. To edit the setting we first have to decompile the binary to a text file (dts) using the devicetree compiler dtc:

Code:
debian@pine64:/boot/pine64$ sudo dtc -I dtb -O dts -o sun50i-a64-pine64-plus.dts sun50i-a64-pine64-plus.dtb

Now you should have a text file called sun50i-a64-pine64-plus.dts ... it should look something like https://github.com/longsleep/build-pine6...pine64.dts

Edit this file with your favourite text editor, search for tx-delay in the Ethernet section:

Code:
eth@01c30000 {
                       compatible = "allwinner,sunxi-gmac";
                       reg = <0x0 0x1c30000 0x0 0x40000 0x0 0x1c00000 0x0 0x30>;
                       pinctrl-names = "default";
                       interrupts = <0x0 0x52 0x4>;
                       interrupt-names = "gmacirq";
                       clocks = <0x8f>;
                       clock-names = "gmac";
                       phy-mode = "rgmii";
                       tx-delay = <0x3>;
                       rx-delay = <0x0>;
                       gmac_power1 = "axp81x_dc1sw:0";
                       status = "okay";
                       device_type = "gmac0";
                       pinctrl-0 = <0x9e>;
                       gmac_power2;
                       gmac_power3;
               };

According to the driver source in /drivers/net/ethernet/allwinner/sunxi-gma.c

Code:
static unsigned long tx_delay = 0;
module_param(tx_delay, ulong, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(tx_delay, "Adjust transmit clock delay, value: 0~7");

static unsigned long rx_delay = 0;
module_param(rx_delay, ulong, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(rx_delay, "Adjust receive clock delay, value: 0~31");

tx-delay ranges from 0 to 7, rx-delay ranges from 0 to 31.... we are adjusting tx-delay for now since we are interested in tweaking the sending of packets at the moment, so pick a value and save the file....

Now it's time to generate a binary file out of the dts again, maybe make a backup of your original dtb at this point, so if something goes wrong, you can copy it back... if you screw up the dtb, your image will most likely not boot or malfunction in some other way...

Code:
debian@pine64:/boot/pine64$ sudo dtc -I dts -O dtb -o sun50i-a64-pine64-plus.dtb sun50i-a64-pine64-plus.dts

Now reboot, and repeat the network test with iperf3, rinse repeat.... if you want to check if your devicetree changes are in effect after you reboot, you can look into the sysfs files of the driver:

Code:
debian@pine64:/boot/pine64$ cat /sys/module/sunxi_gmac/parameters/tx_delay

Happy hacking....


PS: It is by no means sure that tuning the delays will fix all the GbE issues people seem to have, I had two working boards that can get around 800Mbit/s in both directions with the default values (tx-delay 3, rx-delay 0).... BUT I can degrade my performance substantially when I move away from those values, up to a point where the GbE stops working, so testing this on a board that doesnt work with the default will be interesting...
Come have a chat in the Pine IRC channel >>
  Reply
#53
(07-18-2016, 12:26 PM)xalius Wrote: PS: It is by no means sure that tuning the delays will fix all the GbE issues people seem to have, I had two working boards that can get around 800Mbit/s in both directions with the default values (tx-delay 3, rx-delay 0).... BUT I can degrade my performance substantially when I move away from those values, up to a point where the GbE stops working, so testing this on a board that doesnt work with the default will be interesting...

Not to stop anybody trying this also, i played around with my board (BTW tested by longsleep with his network and working fine there) not working with GB-lan, but got no improvement, just worse transfer rates. Only thing that helped was setting it to a fixed 100mb port. So i'm in doubt this will fix the problems many people having here with the network speed in GB-lan....

jm2c

Androsch
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
  Reply
#54
(07-18-2016, 12:26 PM)xalius Wrote: OK, let me give you a short walk-through at what I did:

TEST AT YOUR OWN RISK!

---snipped----

Thanks, @xalius

For those interested in trying this, you might not have the package device-tree-compiler installed (for the dtc command). Just install that first obviously. 

The other thread said lower figures were better - I tried 0 for tx-delay and 0 for rx-delay. Same experience when switching to GbE - connection hangs, sometimes the putty session disconnects, data slows to a trickle. Soon as I put it back to 100Mb, it's fine.

I then tried 6 for tx-delay, thinking maybe more delay meant "lower," and moved rx-delay to 10. No matter the setting, the same results appear - the putty session starts hanging and only responds sometimes. 

All setting changes were confirmed after reboot by using the cat for tx_delay.

I don't have a way of testing directly (not over putty) right now. 

But it seems that these figures aren't making any difference on my board. I might see a bit of a difference if I ran an iperf test, but basically, for purposes of connecting over a putty session and using the PINE64 board, changing the tx-delay and rx-delay seems to have no real effect on the GbE "issue," at least for me.

(07-18-2016, 01:45 PM)androsch Wrote:
(07-18-2016, 12:26 PM)xalius Wrote: PS: It is by no means sure that tuning the delays will fix all the GbE issues people seem to have, I had two working boards that can get around 800Mbit/s in both directions with the default values (tx-delay 3, rx-delay 0).... BUT I can degrade my performance substantially when I move away from those values, up to a point where the GbE stops working, so testing this on a board that doesnt work with the default will be interesting...

Not to stop anybody trying this also, i played around with my board (BTW tested by longsleep with his network and working fine there) not working with GB-lan, but got no improvement, just worse transfer rates. Only thing that helped was setting it to a fixed 100mb port. So i'm in doubt this will fix the problems many people having here with the network speed in GB-lan....

jm2c

Androsch

Are you saying you sent your board to longsleep and GbE is working totally fine in his environment??
  Reply
#55
(07-18-2016, 01:47 PM)amc2012 Wrote:
(07-18-2016, 01:45 PM)androsch Wrote:
(07-18-2016, 12:26 PM)xalius Wrote: PS: It is by no means sure that tuning the delays will fix all the GbE issues people seem to have, I had two working boards that can get around 800Mbit/s in both directions with the default values (tx-delay 3, rx-delay 0).... BUT I can degrade my performance substantially when I move away from those values, up to a point where the GbE stops working, so testing this on a board that doesnt work with the default will be interesting...

Not to stop anybody trying this also, i played around with my board (BTW tested by longsleep with his network and working fine there) not working with GB-lan, but got no improvement, just worse transfer rates. Only thing that helped was setting it to a fixed 100mb port. So i'm in doubt this will fix the problems many people having here with the network speed in GB-lan....

jm2c

Androsch

Are you saying you sent your board to longsleep and GbE is working totally fine in his environment??

Yep, he got my board and it worked fine in his environment, so it is not only a software issue, there must be something else on the hardware side to prevent the Pine64+ board from fuull speed GB. I tried several routers in my network and all work fine with other GB-lan hosts, but not with the Pine64+ (even in longsleeps network it worked fine)

Sounds weird, but thats the actual situation....

Androsch
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
  Reply
#56
That's just wacky

Did he use your power supply as well?
  Reply
#57
No, my own PSU - i think i have posted speed test results too if i remember correctly.

Btw, a while ago i came through some threads on the Armbian forum where a patch to U-Boot for some other board (see https://patchwork.ozlabs.org/patch/602067/) forces the PHY to master mode i enabled. Could as well be something like this for the Pine64 as well.
  Reply
#58
(07-18-2016, 02:05 PM)longsleep Wrote: No, my own PSU - i think i have posted speed test results too if i remember correctly.

Btw, a while ago i came through some threads on the Armbian forum where a patch to U-Boot for some other board (see https://patchwork.ozlabs.org/patch/602067/) forces the PHY to master mode i enabled. Could as well be something like this for the Pine64 as well.

So we can potentially eliminate the PSU from the equation as well then, correct?
  Reply
#59
Ugh!

Well in the mean time I have forced my boards down to 100mbs. They all work and since I will only be using them for low bandwidth applications, 100mbs will do...

I will continue watching here for a fix...

Thank you all!
E
  Reply
#60
V.TOP USB 3.0 with ASIX AX88179 chip at $13.99 didn't work for me, kernel loads the driver, but then I get a device disconnect. I think it may be a driver bug based on some discussions, may be fixed by compiling a newer module version. I'm using ubuntubase when I have more time might try some other distro or building a newer module.

Plugable USB2-E1000

ubuntu@p64e:~$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.86.114 port 5001 connected with 192.168.86.112 port 53995
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-60.0 sec 2.26 GBytes 323 Mbits/sec
ubuntu@p64e:~$ iperf -c 192.168.86.112 -t 60
------------------------------------------------------------
Client connecting to 192.168.86.112, TCP port 5001
TCP window size: 22.5 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.86.114 port 46997 connected with 192.168.86.112 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 853 MBytes 119 Mbits/sec
Backer #17,640
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Ethernet port down afert 1 day jeda 0 598 11-12-2022, 06:48 AM
Last Post: jeda
  Ethernet --> Causing boot loop podtofs 3 5,225 05-16-2017, 03:41 AM
Last Post: m17
  GbE Ethernet Port Issue Data Gathering Statistics Intel MarkHaysHarris777 19 24,176 01-17-2017, 01:17 AM
Last Post: DrunkTank
  What will it take to get the Ethernet port working? clarkss12 10 16,098 10-17-2016, 03:42 PM
Last Post: waldo
  Pine64+ 1GB Ethernet Port spec ecotack 13 15,457 08-20-2016, 09:28 PM
Last Post: pfeerick
  If you have had difficulty with the GbE ethernet please take the poll MarkHaysHarris777 0 2,345 08-17-2016, 05:44 PM
Last Post: MarkHaysHarris777
  Ethernet works on Arch Linux. Nothing elese pfunk237 4 6,014 07-23-2016, 03:07 PM
Last Post: SuperArmySoldiers

Forum Jump:


Users browsing this thread: 1 Guest(s)