Skip to content
linux-nerds.org

linux-nerds.org
  1. Übersicht
  2. Pine64
  3. ROCKPro64
  4. ROCKPro64 Übersicht - was geht?

ROCKPro64 Übersicht - was geht?

ROCKPro64
4 1 659
  • FrankMF

    Start der neuen Übersicht, die alte findet ihr unter diesem Link

    Noch nicht fertig!!

    Eingesetzte Hard- und Software.

    Kernel/Images

    • Kernel 4.20.0-1090-ayufan
    • Kernel 4.4.154-1132-rockchip-ayufan

    Kernelversionen

    Kernel 4.4.154

    rock64@rockpro64:/mnt/home/rock64$ uname -a
          Linux rockpro64 4.4.154-1132-rockchip-ayufan-g8260cd865508 #1 SMP Sun Feb 24 12:07:56 UTC 2019 aarch64  aarch64 aarch64 GNU/Linux

    Kernel 4.20.0

    rock64@rockpro64:~$ uname -a
Linux rockpro64 4.20.0-1090-ayufan-gd1277c20e10d #ayufan SMP PREEMPT Sun Feb 24 11:51:32 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux

    Hardware

    • ROCKPro64 v2.1 2GB RAM
    • Pine64 WiFi-Modul montiert
    • irgendeine SD-Karte 😉
    • Samsung 960 EVO m.2 mit 256GB
    • USB3/SSD-Adapter Fa. Simpletech
    Funktion 4.4.154 Bemerkungen 4.20.0 Bemerkungen
    Youtube 1080p Ja bionic-lxde...-arm64
    Netflix Ja bionic-mate...-armhf
    WLan Ja Seit 0.7.13 auch mit Ayufan Image (4.4.154-1134) Nein
    Bluetooth Nein Nein
    LAN 825/940 Mbit/s iperf3 -c / iperf3 -R -c 943/941Mbit/s iperf3 -c / iperf3 -R -c
    USB2 34,4 MB/s 34,4 MB/s 750 EVO 120GB
    USB3 258 MB/s 225 MB/s 750 EVO 120GB
    USB-C Ja HDMI-Ausgabe (4.4.167) ---
    USB-C Ja LAN-Adapter (4.4.167-1188) 938/941 Mbit/s ---
    PCIe Ja PCie & WiFi-Modul zusammen möglich! Es darf keine UART Nr.10 Verbindung bestehen! Ja PCie & WiFi-Modul zusammen möglich! Es darf keine UART Nr.10 Verbindung bestehen!
    SATA Ja Ja
    HDMI Ja Ja
    Power OFF Ja LED's aus Ja LED's aus
    Suspend Power Button Ja 0,2W - 0,4W Nein Suspend Modul fehlt im Mainline
    Reboot Ja Ja
    SSH-Reboot Ja Ja
    USB-Boot Ja USB2 - OK / USB3 - OK Ja USB2 - OK / USB3 - OK
    SPI Flash Ja Ja Flash-Image
    SPI Erase Ja Ja Erase-Image
    eMMC Boot Ja getestet mit 0.7.13 ---
    Sound Ja über HDMI ---
    GPU --- ---
    Energieverbrauch 4,6W - 5,6W Idle mit USB3-SSD 4,6W - 5,6W Idle mit USB3-SSD

    4.4.154 Tests

    iperf3

    rock64@rockpro64:/mnt/home/rock64$ iperf3 -c 192.168.3.213
Connecting to host 192.168.3.213, port 5201
[  4] local 192.168.3.3 port 57906 connected to 192.168.3.213 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   102 MBytes   856 Mbits/sec    0    723 KBytes       
[  4]   1.00-2.00   sec  98.5 MBytes   826 Mbits/sec    0    723 KBytes       
[  4]   2.00-3.00   sec  98.7 MBytes   826 Mbits/sec    0    788 KBytes       
[  4]   3.00-4.00   sec  98.1 MBytes   825 Mbits/sec    0    788 KBytes       
[  4]   4.00-5.00   sec  98.2 MBytes   822 Mbits/sec    1    395 KBytes       
[  4]   5.00-6.00   sec  97.5 MBytes   817 Mbits/sec    0    396 KBytes       
[  4]   6.00-7.00   sec  97.5 MBytes   819 Mbits/sec    0    396 KBytes       
[  4]   7.00-8.00   sec  98.4 MBytes   825 Mbits/sec    0    396 KBytes       
[  4]   8.00-9.00   sec  97.5 MBytes   818 Mbits/sec    0    396 KBytes       
[  4]   9.00-10.00  sec  97.5 MBytes   818 Mbits/sec    0    396 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   984 MBytes   825 Mbits/sec    1             sender
[  4]   0.00-10.00  sec   981 MBytes   823 Mbits/sec                  receiver

iperf Done.
rock64@rockpro64:/mnt/home/rock64$ 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.3 port 57910 connected to 192.168.3.213 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   112 MBytes   937 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   938 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   939 Mbits/sec                  
[  4]   8.00-9.00   sec   112 MBytes   941 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.

    USB3

    rock64@rockpro64:/mnt$ sudo dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 16.6446 s, 258 MB/s

    USB2

    rock64@rockpro64:/mnt$ sudo dd if=/dev/zero of=sd2.img bs=1M count=4096 conv=fdatasync
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 124.727 s, 34.4 MB/s

    4.20 Test

    iperf3

    rock64@rockpro64:~$ iperf3 -c 192.168.3.213
Connecting to host 192.168.3.213, port 5201
[  4] local 192.168.3.3 port 59832 connected to 192.168.3.213 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   114 MBytes   955 Mbits/sec    0    407 KBytes       
[  4]   1.00-2.00   sec   112 MBytes   942 Mbits/sec   11    315 KBytes       
[  4]   2.00-3.00   sec   112 MBytes   941 Mbits/sec   11    325 KBytes       
[  4]   3.00-4.00   sec   112 MBytes   942 Mbits/sec   11    341 KBytes       
[  4]   4.00-5.00   sec   112 MBytes   941 Mbits/sec   11    338 KBytes       
[  4]   5.00-6.00   sec   112 MBytes   942 Mbits/sec   22    252 KBytes       
[  4]   6.00-7.00   sec   112 MBytes   941 Mbits/sec   11    305 KBytes       
[  4]   7.00-8.00   sec   112 MBytes   940 Mbits/sec    0    342 KBytes       
[  4]   8.00-9.00   sec   112 MBytes   942 Mbits/sec   11    318 KBytes       
[  4]   9.00-10.00  sec   112 MBytes   942 Mbits/sec   11    320 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.10 GBytes   943 Mbits/sec   99             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.3 port 59836 connected to 192.168.3.213 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   112 MBytes   938 Mbits/sec                  
[  4]   1.00-2.00   sec   112 MBytes   940 Mbits/sec                  
[  4]   2.00-3.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   3.00-4.00   sec   112 MBytes   942 Mbits/sec                  
[  4]   4.00-5.00   sec   112 MBytes   940 Mbits/sec                  
[  4]   5.00-6.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   6.00-7.00   sec   112 MBytes   940 Mbits/sec                  
[  4]   7.00-8.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   8.00-9.00   sec   112 MBytes   941 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    1             sender
[  4]   0.00-10.00  sec  1.09 GBytes   941 Mbits/sec                  receiver

iperf Done.

    USB3

     rock64@rockpro64:/mnt$ sudo dd if=/dev/zero of=sd3.img bs=1M count=4096 conv=fdatasync
 4096+0 records in
 4096+0 records out
 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 19.1171 s, 225 MB/s

    USB2

    rock64@rockpro64:~$ sudo dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync
[sudo] password for rock64: 
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 124.89 s, 34.4 MB/s

    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
  • FrankMF

    USB 2/3

    Laut Wikipedia ist die maximale Nutz-Datenrate bei

    • USB 2.0 = 40MB/s
    • USB 3.0 = 300MB/s

    Somit haben wir beide Werte recht gut erreicht. Es könnte je nach eingesetztem Adapter und SSD natürlich zu anderen Werten kommen, aber diese sind schon recht nah am Optimum.

    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
  • FrankMF

    PCIe & WiFi

    Das Pine64-Modul mit PCIe macht bei mir zusammen immer noch massiv Probleme. Mr.Fixit sein Kernel soll das hergeben, es gibt wohl drei Personen wo das zusammen funktioniert. Bei mir nur ganz selten, meistens Kernel Panic.

    Als Hinweis:
    Das Pine64-Modul funktioniert mit dem Image von Mr.Fixit astrein. Mit Kamils Image zur Zeit nicht, er hat aber geschrieben, das das im nächsten Release mit drin sein soll.

    PCie alleine funktioniert schon lange, das habe ich jetzt nicht nochmal extra getestet. Ich hätte sonst das WiFi-Modul wieder entfernen müssen, das ist aber etwas Fummelei 🙂 Meine anderen beiden ROCKPro64 sind beschäftigt LOL

    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
  • FrankMF

    WIFI

    Seit dem Release des Images 0.7.13 ist WiFi auch möglich. Weiterhin ungelöst ist das Problem PCIe & WiFi (also bei mir).

    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 - Anpassen resize_rootfs.sh

    Angeheftet ROCKPro64 rockpro64
    3
    0 Stimmen
    3 Beiträge
    545 Aufrufe
    FrankMF
    Seit Release 0.10.10 ist das automatische Vergrößern der Root Partition mit drin 0.10.10: Support automated resize when booting from nvme Einfach das Image auf die NVMe SSD schreiben, ab in den ROCKPro64 und fertig! Nach dem Booten wird die Partition dann automatisch auf die maximal mögliche Größe erweitert. Kamil hat das Script auch ein wenig angepasst. case $dev in /dev/mmcblk?p?) DISK=${dev:0:12} PART=${dev:13} NAME="sd/emmc" ;; /dev/sd??) DISK=${dev:0:8} PART=${dev:8} NAME="hdd/ssd" ;; /dev/nvme?n?p?) DISK=${dev:0:12} PART=${dev:13} NAME="pcie/nvme" ;; Das Resultat bei einer Samsung 979 EVO mit 500GB Speicher rock64@rockpro64:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 918M 0 918M 0% /dev tmpfs 192M 5.2M 187M 3% /run /dev/nvme0n1p4 459G 1.2G 439G 1% / tmpfs 957M 0 957M 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 957M 0 957M 0% /sys/fs/cgroup /dev/nvme0n1p3 229M 44M 169M 21% /boot /dev/nvme0n1p2 12M 0 12M 0% /boot/efi tmpfs 192M 0 192M 0% /run/user/1000 Perfekt. Danke Kamil!
  • FrankMF

    ROCKPro64 - Armbian - Boot Ausgabe ändern

    Verschoben Armbian armbian rockpro64
    1
    0 Stimmen
    1 Beiträge
    507 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    ROCKPro64 - Der Bootvorgang

    Verschoben Hardware hardware rockpro64
    3
    0 Stimmen
    3 Beiträge
    2k Aufrufe
    FrankMF
    Um einen neuen Kernel booten zu können, brauche ich diese 4 Dateien unter /boot config-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 initrd.img-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 System.map-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 vmlinuz-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 Und den Ordner /boot/dtbs/4.19.0-rc4-1065-ayufan-g72e04c7b3e06 mit folgendem Inhalt rock64@rockpro64v2_0:/boot/dtbs/4.19.0-rc4-1065-ayufan-g72e04c7b3e06$ ls -la total 104 drwxr-xr-x 26 root root 4096 Sep 30 09:54 . drwxr-xr-x 6 root root 4096 Sep 30 09:55 .. drwxr-xr-x 2 root root 4096 Sep 30 09:54 al drwxr-xr-x 2 root root 4096 Sep 30 09:54 allwinner drwxr-xr-x 2 root root 4096 Sep 30 09:54 altera drwxr-xr-x 2 root root 4096 Sep 30 09:54 amd drwxr-xr-x 2 root root 4096 Sep 30 09:54 amlogic drwxr-xr-x 2 root root 4096 Sep 30 09:54 apm drwxr-xr-x 2 root root 4096 Sep 30 09:54 arm drwxr-xr-x 4 root root 4096 Sep 30 09:54 broadcom drwxr-xr-x 2 root root 4096 Sep 30 09:54 cavium drwxr-xr-x 2 root root 4096 Sep 30 09:54 exynos drwxr-xr-x 2 root root 4096 Sep 30 09:54 freescale drwxr-xr-x 2 root root 4096 Sep 30 09:54 hisilicon drwxr-xr-x 2 root root 4096 Sep 30 09:54 lg drwxr-xr-x 2 root root 4096 Sep 30 09:54 marvell drwxr-xr-x 2 root root 4096 Sep 30 09:54 mediatek drwxr-xr-x 2 root root 4096 Sep 30 09:54 nvidia drwxr-xr-x 2 root root 4096 Sep 30 09:54 qcom drwxr-xr-x 2 root root 4096 Sep 30 09:54 renesas drwxr-xr-x 2 root root 4096 Sep 30 09:54 rockchip drwxr-xr-x 2 root root 4096 Sep 30 09:54 socionext drwxr-xr-x 2 root root 4096 Sep 30 09:54 sprd drwxr-xr-x 2 root root 4096 Sep 30 09:54 synaptics drwxr-xr-x 2 root root 4096 Sep 30 09:54 xilinx drwxr-xr-x 2 root root 4096 Sep 30 09:54 zte Unter /boot/extlinux liegt dann die Datei extlinux.conf Die sieht bei mir dann so aus timeout 10 menu title select kernel label kernel-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 kernel /boot/vmlinuz-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 initrd /boot/initrd.img-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 devicetreedir /boot/dtbs/4.19.0-rc4-1065-ayufan-g72e04c7b3e06 append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=TEST rootwait rootfstype=ext4 label kernel-4.19.0-rc4-1065-ayufan-g72e04c7b3e06-memtest kernel /boot/vmlinuz-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 initrd /boot/initrd.img-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 devicetreedir /boot/dtbs/4.19.0-rc4-1065-ayufan-g72e04c7b3e06 append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=TEST rootwait rootfstype=ext4 memtest Darunter kommen dann evt. die alten Kernel die installiert waren, das habe ich hier im Beispiel weg gelassen.
  • FrankMF

    Paar Info's vom Chef

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

    zram - Was das??

    ROCKPro64 rockpro64
    3
    0 Stimmen
    3 Beiträge
    1k Aufrufe
    FrankMF
    @tkaiser ; Ich hab dich vermisst Danke für die Info, ich bin vor dem ROCKPro64 da noch nie so richtig drüber gestolpert. Aber wenn ich dann was finde, schau auch immer wofür es denn bitte ist. Danke für Deine Hinweise.
  • 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

    bionic-containers-rockpro64

    Verschoben Linux rockpro64
    2
    0 Stimmen
    2 Beiträge
    978 Aufrufe
    FrankMF
    Ich habe das jetzt mal endlich getestet https://forum.frank-mankel.org/topic/296/rockpro64-docker-image
  • 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)