(02-25-2016, 06:15 AM)longsleep Wrote: [ -> ]Well you can try if it makes a difference if U-Boot loads the updated dtb but please try :-)
I've built a new U-Boot image, but I cannot see if it makes any difference, it doesn't make anything worse at least.
You've certainly already seen the
hints about AW GMAC and U-Boot ("CONFIG_GMAC_TX_DELAY").
Yeah - i saw that and the timings for pine64 are in the device tree . I am somewhat concerned about the simplicity of the GMAC driver from Allwinner and it might be a better idea to try to use the new driver from linux-sunxi upstream instead.
As i was not happy with the network speeds in my network i did some experiments with the settings and came up with a change which makes things much better.
See
https://github.com/longsleep/build-pine6...4eeb09834b
With that change, I now get stable ~500Mbit/s on 1000M links and ~94Mbit/s on 100M links.
1000M switch:
Code:
Client connecting to 192.168.1.29, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.111 port 54413 connected with 192.168.1.29 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 602 MBytes 504 Mbits/sec
100M switch:
Code:
Client connecting to 192.168.1.29, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.111 port 54416 connected with 192.168.1.29 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 113 MBytes 94.4 Mbits/sec
With a 1000M USB Ethernet adapter, it maxes out at around 205Mbit/sec (using the same wire 1000M switch). It would be great if you guys could verify and give it a try by replacing the device tree for the Linux Kernel, eg by running
https://github.com/longsleep/build-pine6...l_image.sh
Thanks
Simon
I tried a few different settings, and rx 0, tx 3 does seem to work the best. Sending I'm getting ~600Mbps sustained with one thread, and 640-650 with two threads (-P 2), and receiving 820Mbps with one thread and 940 with two threads. Did you set the governor to performance to run your tests?
So I've spent some time running tests on the Gb ethernet and am getting some odd results. While it is possible to get 600Mbps throughput, it's also possible to get just 400:
Code:
[localhost.localdomain]/root: iperf -c 192.168.2.1 -t 300 -i 10 -P 1
------------------------------------------------------------
Client connecting to 192.168.2.1, TCP port 5001
TCP window size: 49.6 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.2.2 port 44710 connected with 192.168.2.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 712 MBytes 597 Mbits/sec
[ 3] 10.0-20.0 sec 716 MBytes 600 Mbits/sec
[ 3] 20.0-30.0 sec 716 MBytes 600 Mbits/sec
[ 3] 30.0-40.0 sec 716 MBytes 600 Mbits/sec
[ 3] 40.0-50.0 sec 716 MBytes 600 Mbits/sec
[ 3] 50.0-60.0 sec 710 MBytes 595 Mbits/sec
... looks okay
[localhost.localdomain]/root: ifconfig eth0 down
[localhost.localdomain]/root: ifconfig eth0 up
[localhost.localdomain]/root: ifconfig eth0 192.168.2.2
[localhost.localdomain]/root: iperf -c 192.168.2.1 -t 300 -i 10 -P 1
------------------------------------------------------------
Client connecting to 192.168.2.1, TCP port 5001
TCP window size: 90.2 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.2.2 port 44711 connected with 192.168.2.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 465 MBytes 390 Mbits/sec
[ 3] 10.0-20.0 sec 467 MBytes 392 Mbits/sec
[ 3] 20.0-30.0 sec 466 MBytes 391 Mbits/sec
[ 3] 30.0-40.0 sec 467 MBytes 392 Mbits/sec
[ 3] 40.0-50.0 sec 467 MBytes 392 Mbits/sec
[ 3] 50.0-60.0 sec 467 MBytes 392 Mbits/sec
[ 3] 60.0-70.0 sec 467 MBytes 392 Mbits/sec
[ 3] 70.0-80.0 sec 467 MBytes 392 Mbits/sec
[ 3] 80.0-90.0 sec 467 MBytes 392 Mbits/sec
...
Huh? Looks like there's something in the GMAC device or the PHY that's not being set properly (resetting the eth0 device appears to power-cycle the PHY, if the LEDs are any indication). Note that this is pretty hard to reproduce -- 9 out of 10 times the throughput doesn't change. Also, the ethernet controller doesn't always come up in the faster mode; again, it is somewhat random but skews towards the higher-speed mode.
I was able to rule out thermal throttling here, as this test can take a couple of minutes to push the SoC's temperature to the point where the CPU speed drops to 1.1GHz, and even then, the throughput only falls to around 580Mbps.
I started publishing packages which contain a compiled Kernel, initrd, device tree and the matching Kernel modules. You can use these tarballs to build your own image without having to compile the Kernel and modules or to update existing images. Just get the tarball and extract it to the root file system (while having /boot) mounted.
Get 3.10.65-2-pine64-longsleep-39 from
https://www.stdin.xyz/downloads/people/l...ges/linux/
(03-06-2016, 10:47 AM)tllim Wrote: [ -> ]This new link is a broken link "404 not found".
Whoops, i should not copy pasted the truncated links from the forum. Updated and thanks for the notification.
The Kernel package was updated to improve the thermal behavior with the results of the discussions and testing in
https://github.com/longsleep/build-pine64-image/pull/3 - also the tarball now contains the Kernel firmware and header files and no longer overwrites your uEnv.txt on update.
Get 3.10.65-2-pine64-longsleep-39-2 from
https://www.stdin.xyz/downloads/people/l...ges/linux/
To use this release, make sure you have at least U-Boot 20160311-1 so the new CPU frequencies are available with the right settings.
I have added gear to easily update U-Boot and Kernel. Update like this (as root) on any of my images:
Code:
bash <(curl -s https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/pine64_update_uboot.sh)
bash <(curl -s https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/pine64_update_kernel.sh)
The reboot.