Skip to content
linux-nerds.org

linux-nerds.org
  1. Übersicht
  2. Pine64
  3. ROCKPro64
  4. ROCKPro64 - LAN Schnittstelle

ROCKPro64 - LAN Schnittstelle

Verschoben ROCKPro64
1 1 425
  • FrankMF

    Wie vielleicht einige von Euch wissen, gibt es schon seit längerem einige Probleme mit der LAN-Schnittstelle. Eines dieser Probleme bezog sich wohl auf ipv6, kann ich hier nicht testen, aber nun scheint es eine Lösung dafür zu geben. Gestern folgendes im IRC

    08/03/19 17:50
    <ayufan> maybe instead of disabling tx checksuming we should lower mtu to 1498?
    08/03/19 17:51
    <ayufan> it should give you full gbe performance, something that is not happening now 😞
    08/03/19 18:00
    <ayufan> forcing mtu of 1498 allows to have gbe performance and lower cpu usage
    08/03/19 18:39
    <FrankM> When i understand you correct, diabling tx checksuming helps? Ok, testing. Now i have 944/928Mbit/s before 941/825Mbit/s.
    08/03/19 18:48
    <FrankM> on mainline 5.0.0 i got 941/941
    08/03/19 19:12
    <ayufan> Not on ipv6
    08/03/19 19:40
    <ayufan> rockpro64 has the same behavior as rock64, it fails on checksum offload on tx
    08/03/19 19:40
    <ayufan> if you disable tx offload, you get around 800Mbps on rock/pro64
    08/03/19 19:40
    <ayufan> it works super stable
    08/03/19 19:40
    <ayufan> if you keep tx offload, you need mtu 1498, and you get 941Mbps on both

    Wir hatten in der Anfangszeit des ROCKPro64 immer 941/941 Mbit/s auf der Leitung, nach diesem Patch war das dann vorbei. Grund dafür waren damals irgendwelche Probleme. Danach hatten wir dann immer das hier.

    Bildschirmfoto vom 2019-03-09 10-08-41.png

    Ich habe dann gestern Abend ein wenig rumgetestet.

    Man kann den Eintrag im dts File per Hand ändern.

    sudo dtedit

    Dann STRG + W drücken. dma_mode eingeben.

    Wir finden diese Zeile

    snps,force_thresh_dma_mode;

    Ändern in

    #snps,force_thresh_dma_mode;

    STRG + X

    Neustarten!

    MTU temporär ändern

    An der uart-Konsole folgendes eingeben

    ifconfig eth0 down
ifconfig eth0 mtu 1498
ifconfig eth0 up

    Das kann man mit netstat überprüfen

    rock64@rockpro64:/mnt$ netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0      1500  1469569      0      0 0        242306      0      0      0 BMRU
lo       65536       12      0      0 0            12      0      0      0 LRU

    Da der Kamil ja auch ehrgeizig ist, hat ihm das gestern Abend wohl keine Ruhe gelassen 🙂 Es gibt nun einen neuen Kernel mit einem entsprechenden Patch.

    	- snps,force_thresh_dma_mode;
	+ rockchip,bugged_tx_coe;

    Und

    /* Including very small MTUs of 1498 for Rockchip devices */
if (priv->plat->bugged_tx_coe && (dev->mtu > ETH_DATA_LEN - 2))
		features &= ~NETIF_F_CSUM_MASK;

    Also, noch was dazu gekommen. Und hier dann das Ergebnis für

    Kernel 5.0.0

    rock64@rockpro64:~$ iperf3 -c 192.168.3.213
Connecting to host 192.168.3.213, port 5201
[  4] local 192.168.3.14 port 33896 connected to 192.168.3.213 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   114 MBytes   952 Mbits/sec    0    363 KBytes       
[  4]   1.00-2.00   sec   112 MBytes   941 Mbits/sec   11    313 KBytes       
[  4]   2.00-3.00   sec   112 MBytes   942 Mbits/sec   10    293 KBytes       
[  4]   3.00-4.00   sec   112 MBytes   941 Mbits/sec   11    293 KBytes       
[  4]   4.00-5.00   sec   112 MBytes   941 Mbits/sec   11    235 KBytes       
[  4]   5.00-6.00   sec   112 MBytes   941 Mbits/sec    0    328 KBytes       
[  4]   6.00-7.00   sec   112 MBytes   941 Mbits/sec   11    322 KBytes       
[  4]   7.00-8.00   sec   112 MBytes   941 Mbits/sec   11    321 KBytes       
[  4]   8.00-9.00   sec   112 MBytes   941 Mbits/sec   11    325 KBytes       
[  4]   9.00-10.00  sec   112 MBytes   941 Mbits/sec   11    332 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec   87             sender
[  4]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec                  receiver

iperf Done.
rock64@rockpro64:~$ iperf3 -R -c 192.168.3.213
Connecting to host 192.168.3.213, port 5201
Reverse mode, remote host 192.168.3.213 is sending
[  4] local 192.168.3.14 port 33900 connected to 192.168.3.213 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   111 MBytes   932 Mbits/sec                  
[  4]   1.00-2.00   sec   112 MBytes   937 Mbits/sec                  
[  4]   2.00-3.00   sec   112 MBytes   942 Mbits/sec                  
[  4]   3.00-4.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   4.00-5.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   5.00-6.00   sec   112 MBytes   942 Mbits/sec                  
[  4]   6.00-7.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   7.00-8.00   sec   112 MBytes   942 Mbits/sec                  
[  4]   8.00-9.00   sec   112 MBytes   942 Mbits/sec                  
[  4]   9.00-10.00  sec   112 MBytes   941 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.09 GBytes   940 Mbits/sec                  receiver

iperf Done.
rock64@rockpro64:~$ netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0      1500   873482      0      0 0        842381      0      0      0 BMRU
lo       65536        4      0      0 0             4      0      0      0 LRU
rock64@rockpro64:~$ sudo mount /dev/nvme0p1 /mnt
[sudo] password for rock64: 
mount: /mnt: special device /dev/nvme0p1 does not exist.
rock64@rockpro64:~$ sudo mount /dev/nvme0n1 /mnt
rock64@rockpro64:~$ cd /mnt
rock64@rockpro64:/mnt$ ls
lost+found  ubuntu-18.04.2-desktop-amd64.iso
rock64@rockpro64:/mnt$ sudo wget http://ftp.belnet.be/mirror/ubuntu.com/releases/bionic/ubuntu-18.04.2-desktop-amd64.iso
--2019-03-09 08:43:31--  http://ftp.belnet.be/mirror/ubuntu.com/releases/bionic/ubuntu-18.04.2-desktop-amd64.iso
Resolving ftp.belnet.be (ftp.belnet.be)... 193.190.67.98, 2001:6a8:3c80:2::21
Connecting to ftp.belnet.be (ftp.belnet.be)|193.190.67.98|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1996488704 (1.9G) [application/x-iso9660-image]
Saving to: ‘ubuntu-18.04.2-desktop-amd64.iso.1’

ubuntu-18.04.2-desktop 100%[============================>]   1.86G  12.4MB/s    in 2m 38s  

2019-03-09 08:46:09 (12.1 MB/s) - ‘ubuntu-18.04.2-desktop-amd64.iso.1’ saved [1996488704/1996488704]

rock64@rockpro64:/mnt$ netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0      1500  2343002      0      0 0       1099074      0      0      0 BMRU
lo       65536        8      0      0 0             8      0      0      0 LRU

    Kernel 4.4.167-1140

    rock64@rockpro64:~$ iperf3 -c 192.168.3.213
Connecting to host 192.168.3.213, port 5201
[  4] local 192.168.3.14 port 54640 connected to 192.168.3.213 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   116 MBytes   969 Mbits/sec    0   1.03 MBytes       
[  4]   1.00-2.00   sec   112 MBytes   943 Mbits/sec   10    529 KBytes       
[  4]   2.00-3.00   sec   112 MBytes   942 Mbits/sec   11    325 KBytes       
[  4]   3.00-4.01   sec   112 MBytes   940 Mbits/sec   10    327 KBytes       
[  4]   4.01-5.00   sec   112 MBytes   943 Mbits/sec    0    396 KBytes       
[  4]   5.00-6.00   sec   112 MBytes   941 Mbits/sec    0    413 KBytes       
[  4]   6.00-7.00   sec   111 MBytes   935 Mbits/sec   11    355 KBytes       
[  4]   7.00-8.00   sec   113 MBytes   947 Mbits/sec    0    410 KBytes       
[  4]   8.00-9.00   sec   112 MBytes   942 Mbits/sec    0    424 KBytes       
[  4]   9.00-10.00  sec   112 MBytes   941 Mbits/sec   11    303 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.10 GBytes   944 Mbits/sec   53             sender
[  4]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec                  receiver

iperf Done.
rock64@rockpro64:~$ iperf3 -R -c 192.168.3.213
Connecting to host 192.168.3.213, port 5201
Reverse mode, remote host 192.168.3.213 is sending
[  4] local 192.168.3.14 port 54644 connected to 192.168.3.213 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   111 MBytes   934 Mbits/sec                  
[  4]   1.00-2.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   2.00-3.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   3.00-4.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   4.00-5.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   5.00-6.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   6.00-7.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   7.00-8.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   8.00-9.00   sec   112 MBytes   938 Mbits/sec                  
[  4]   9.00-10.00  sec   110 MBytes   922 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.09 GBytes   939 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.09 GBytes   938 Mbits/sec                  receiver

iperf Done.
rock64@rockpro64:~$ netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0      1500   871955      0      0 0        842891      0      0      0 BMRU
lo       65536       84      0      0 0            84      0      0      0 LRU
wlan0     1500        0      0      0 0             0      0      0      0 BMU
rock64@rockpro64:~$ sudo wget http://ftp.belnet.be/mirror/ubuntu.com/releases/bionic/ubuntu-18.04.2-desktop-amd64.iso
[sudo] password for rock64: 
--2019-03-09 09:52:08--  http://ftp.belnet.be/mirror/ubuntu.com/releases/bionic/ubuntu-18.04.2-desktop-amd64.iso
Resolving ftp.belnet.be (ftp.belnet.be)... 193.190.67.98, 2001:6a8:3c80:2::21
Connecting to ftp.belnet.be (ftp.belnet.be)|193.190.67.98|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1996488704 (1.9G) [application/x-iso9660-image]
Saving to: ‘ubuntu-18.04.2-desktop-amd64.iso.1’

ubuntu-18.04.2-desktop-amd64.iso 100%[=======================================================>]   1.86G  12.4MB/s    in 3m 32s  

2019-03-09 09:55:41 (8.97 MB/s) - ‘ubuntu-18.04.2-desktop-amd64.iso.1’ saved [1996488704/1996488704]

rock64@rockpro64:~$ netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0      1500  2340948      0      0 0       1072892      0      0      0 BMRU
lo       65536       88      0      0 0            88      0      0      0 LRU
wlan0     1500        0      0      0 0             0      0      0      0 BMU
rock64@rockpro64:~$

    Fazit

    Mein Download auf die SD-Karte stockt immer mal wieder (Kernel 4.4.x), wenn ich auf NVMe SSD schreiben kann (Kernel 5.0.0) geht das ohne Pausen. Die Retr im iperf3 -c 192.168.3.213 sehen nicht schön aus, aber ich habe keine Ahnung ob das irgendwie wichtig ist. Mal Kamil fragen...

    Sieht so aus, als wenn man wieder ein Problem weniger hätte!?

    Im Fediverse -> @FrankM@nrw.social

    1. NanoPi R5S
    2. Quartz64 Model B, 4GB RAM
    3. Quartz64 Model A, 4GB RAM
    4. RockPro64 v2.1
    0
Anmelden zum Antworten

  • FrankMF

    ROCKPro64 - Debian 11 installieren

    ROCKPro64 bullseye debian rockpro64
    1
    0 Stimmen
    1 Beiträge
    513 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    Quartz64 - Kühler

    Verschoben Quartz64 - A quartz64 rockpro64
    3
    1
    0 Stimmen
    3 Beiträge
    398 Aufrufe
    FrankMF
    @thc013 I use an thermal pad. So i think it isn't an problem.
  • FrankMF

    ROCKPro64 - PCIe Probleme

    Hardware rockpro64
    3
    0 Stimmen
    3 Beiträge
    424 Aufrufe
    FrankMF
    Danke für dein Feedback.
  • FrankMF

    ROCKPro64 - Release 0.10.6 Was geht?

    Angeheftet ROCKPro64 rockpro64
    1
    0 Stimmen
    1 Beiträge
    454 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    ROCKPro64 - Debian 10.1

    ROCKPro64 rockpro64
    1
    0 Stimmen
    1 Beiträge
    436 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    Images 0.9.x

    Images rockpro64
    13
    0 Stimmen
    13 Beiträge
    1k Aufrufe
    FrankMF
    0.9.16: gitlab-ci-linux-build-163 released 0.9.x 0.9.16: Bump kernel to 4.4.197, 0.9.15: Bump kernel to 4.4.193, 0.9.14: Bump kernel to 4.4.190, 0.9.14: Fix Firefox video playback, 0.9.13: Bump sound volume for Pinebook Pro, 0.9.12: Fix LXDE for Rock64, 0.9.10: Fix support for power/standby LEDs for all boards,
  • FrankMF

    stretch-minimal-rockpro64

    Verschoben Linux rockpro64
    3
    0 Stimmen
    3 Beiträge
    1k Aufrufe
    FrankMF
    Mal ein Test was der Speicher so kann. rock64@rockpro64:~/tinymembench$ ./tinymembench tinymembench v0.4.9 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 2812.7 MB/s C copy backwards (32 byte blocks) : 2811.9 MB/s C copy backwards (64 byte blocks) : 2632.8 MB/s C copy : 2667.2 MB/s C copy prefetched (32 bytes step) : 2633.5 MB/s C copy prefetched (64 bytes step) : 2640.8 MB/s C 2-pass copy : 2509.8 MB/s C 2-pass copy prefetched (32 bytes step) : 2431.6 MB/s C 2-pass copy prefetched (64 bytes step) : 2424.1 MB/s C fill : 4887.7 MB/s (0.5%) C fill (shuffle within 16 byte blocks) : 4883.0 MB/s C fill (shuffle within 32 byte blocks) : 4889.3 MB/s C fill (shuffle within 64 byte blocks) : 4889.2 MB/s --- standard memcpy : 2807.3 MB/s standard memset : 4890.4 MB/s (0.3%) --- NEON LDP/STP copy : 2803.7 MB/s NEON LDP/STP copy pldl2strm (32 bytes step) : 2802.1 MB/s NEON LDP/STP copy pldl2strm (64 bytes step) : 2800.7 MB/s NEON LDP/STP copy pldl1keep (32 bytes step) : 2745.5 MB/s NEON LDP/STP copy pldl1keep (64 bytes step) : 2745.8 MB/s NEON LD1/ST1 copy : 2801.9 MB/s NEON STP fill : 4888.9 MB/s (0.3%) NEON STNP fill : 4850.1 MB/s ARM LDP/STP copy : 2803.8 MB/s ARM STP fill : 4893.0 MB/s (0.5%) ARM STNP fill : 4851.7 MB/s ========================================================================== == Framebuffer read tests. == == == == Many ARM devices use a part of the system memory as the framebuffer, == == typically mapped as uncached but with write-combining enabled. == == Writes to such framebuffers are quite fast, but reads are much == == slower and very sensitive to the alignment and the selection of == == CPU instructions which are used for accessing memory. == == == == Many x86 systems allocate the framebuffer in the GPU memory, == == accessible for the CPU via a relatively slow PCI-E bus. Moreover, == == PCI-E is asymmetric and handles reads a lot worse than writes. == == == == If uncached framebuffer reads are reasonably fast (at least 100 MB/s == == or preferably >300 MB/s), then using the shadow framebuffer layer == == is not necessary in Xorg DDX drivers, resulting in a nice overall == == performance improvement. For example, the xf86-video-fbturbo DDX == == uses this trick. == ========================================================================== NEON LDP/STP copy (from framebuffer) : 602.5 MB/s NEON LDP/STP 2-pass copy (from framebuffer) : 551.6 MB/s NEON LD1/ST1 copy (from framebuffer) : 667.1 MB/s NEON LD1/ST1 2-pass copy (from framebuffer) : 605.6 MB/s ARM LDP/STP copy (from framebuffer) : 445.3 MB/s ARM LDP/STP 2-pass copy (from framebuffer) : 428.8 MB/s ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.0 ns / 0.0 ns 65536 : 4.5 ns / 7.2 ns 131072 : 6.8 ns / 9.7 ns 262144 : 9.8 ns / 12.8 ns 524288 : 11.4 ns / 14.7 ns 1048576 : 16.0 ns / 22.6 ns 2097152 : 114.0 ns / 175.3 ns 4194304 : 161.7 ns / 219.9 ns 8388608 : 190.7 ns / 241.5 ns 16777216 : 205.3 ns / 250.5 ns 33554432 : 212.9 ns / 255.5 ns 67108864 : 222.3 ns / 271.1 ns
  • FrankMF

    Images 0.6.x

    Verschoben Images rockpro64
    30
    0 Stimmen
    30 Beiträge
    7k Aufrufe
    FrankMF
    0.6.60 released 0.6.60: Fix pcie/nvme/sata support for 4.4, 0.6.60: Fix spi-flash access for 4.4/mainline, Ich bin davon ausgegangen, das 0.6.x nict mehr fortgeführt wird, okay - sieht nicht so aus. Sollte released werden, ist aber aus irgendeinem Grund gestern nicht passiert (lt. Kamil)