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

  • FrankMF

    SATA - Booten jetzt möglich

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

    ROCKPro64 - Booten von USB3

    ROCKPro64
    3
    0 Stimmen
    3 Beiträge
    379 Aufrufe
    FrankMF

    Yeah, genau das worauf ich auch warte.

    Wenn ich das richtig mitbekommen habe, könnte das Kamil's nächster Punkt auf seiner Liste sein.

  • FrankMF

    ROCKPro64 - RP64.GPIO

    Angeheftet Verschoben Hardware
    6
    0 Stimmen
    6 Beiträge
    6k Aufrufe
    FrankMF

    Hallo zusammen,

    da ich weiß das dieser Artikel recht beliebt ist, wollen wir den heute mal aktualisieren. Vieles aus den vorherigen Beiträgen passt noch. Es gibt aber kleine Anpassungen.

    Hardware ROCKPro64v21. 2GB RAM Software Kamils Release 0.10.9 Linux rockpro64 5.6.0-1132-ayufan-g81043e6e109a #ayufan SMP Tue Apr 7 10:07:35 UTC 2020 aarch64 GNU/Linux Installation apt install python

    Danach laden wir das Projekt

    git clone https://github.com/Leapo/Rock64-R64.GPIO

    PIN Nummern anpassen

    cd Rock64-R64.GPIO/R64 nano _GPIO.py

    Datei ergänzen

    # Define GPIO arrays #ROCK_valid_channels = [27, 32, 33, 34, 35, 36, 37, 38, 64, 65, 67, 68, 69, 76, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 96, 97, 98, 100, 101, 102, 103, 104] #BOARD_to_ROCK = [0, 0, 0, 89, 0, 88, 0, 0, 64, 0, 65, 0, 67, 0, 0, 100, 101, 0, 102, 97, 0, 98, 103, 96, 104, 0, 76, 68, 69, 0, 0, 0, 38, 32, 0, 33, 37, 34, 36, 0, 35, 0, 0, 81, 82, 87, 83, 0, 0, 80, 79, 85, 84, 27, 86, 0, 0, 0, 0, 0, 0, 89, 88] #BCM_to_ROCK = [68, 69, 89, 88, 81, 87, 83, 76, 104, 98, 97, 96, 38, 32, 64, 65, 37, 80, 67, 33, 36, 35, 100, 101, 102, 103, 34, 82] ROCK_valid_channels = [52,53,152,54,50,33,48,39,41,43,155,156,125,122,121,148,147,120,36,149,153,42,45,44,124,126,123,127] BOARD_to_ROCK = [0,0,0,52,0,53,0,152,148,0,147,54,120,50,0,33,36,0,149,48,0,39,153,41,42,0,45,43,44,155,0,156,124,125,0,122,126,121,123,0,127] BCM_to_ROCK = [43,44,52,53,152,155,156,45,42,39,48,41,124,125,148,147,124,54,120,122,123,127,33,36,149,153,121,50]

    Abspeichern.

    Datei test.py anlegen

    nano test.py

    Inhalt

    #!/usr/bin/env python # Frank Mankel, 2018, LGPLv3 License # Rock 64 GPIO Library for Python # Thanks Allison! Thanks smartdave! import R64.GPIO as GPIO from time import sleep print("Output Test R64.GPIO Module...") # Set Variables var_gpio_out = 156 var_gpio_in = 155 # GPIO Setup GPIO.setwarnings(True) GPIO.setmode(GPIO.ROCK) GPIO.setup(var_gpio_out, GPIO.OUT, initial=GPIO.HIGH) # Set up GPIO as an output, with an initial state of HIGH GPIO.setup(var_gpio_in, GPIO.IN, pull_up_down=GPIO.PUD_UP) # Set up GPIO as an input, pullup enabled # Test Output print("") print("Testing GPIO Input/Output:") while True: var_gpio_state_in = GPIO.input(var_gpio_in) var_gpio_state = GPIO.input(var_gpio_out) # Return State of GPIO if var_gpio_state == 0 and var_gpio_state_in == 1: GPIO.output(var_gpio_out,GPIO.HIGH) # Set GPIO to HIGH print("Input State: " + str(var_gpio_state_in)) # Print results print("Output State IF : " + str(var_gpio_state)) # Print results else: GPIO.output(var_gpio_out,GPIO.LOW) # Set GPIO to LOW print("Input State: " + str(var_gpio_state_in)) # Print results print("Output State ELSE: " + str(var_gpio_state)) # Print results sleep(0.5) exit() Beispiel

    Bild Text

    Wenn der Taster im Bild betätigt wird, soll die LED blinken.

    Wir benutzen folgende Ein- Augänge des ROCKPro64.

    # Set Variables var_gpio_out = 156 var_gpio_in = 155

    Das heißt:

    an Pin 1 (3,3V) kommt eine Strippe des Tasters an Pin 29 (Input) kommt eine Strippe des Tasters an Pin 31 (Output) kommt der Plus-Pol der LED an Pin 39 (GND) kommt der Minus-Pol der LED

    Somit wird auf den Eingang (Pin 29) bei Betätigung des Tasters 3,3 Volt angelegt. Damit wird dann der Eingang als High (1) erkannt. Die LED wird über den Ausgang (Pin 31) gesteuert.

    Starten kann man das Script mit

    python test.py

  • FrankMF

    Bionic Minimal 0.7.7 - Vergleich 4.4.132 & 4.18.0-rc3-1046

    Verschoben Archiv
    1
    0 Stimmen
    1 Beiträge
    581 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    [HOWTO] SMD Widerstand Preproduction Board

    Verschoben Hardware
    2
    0 Stimmen
    2 Beiträge
    782 Aufrufe
    FrankMF

    Offizielle Bestätigung -> http://files.pine64.org

  • FrankMF

    [HOWTO] ROCKPro64 - PCIe NVMe Karte mit Samsung 960 EVO m.2

    Verschoben Hardware
    2
    0 Stimmen
    2 Beiträge
    2k Aufrufe
    FrankMF
    Ergänzung

    Eine andere SATA-Karte und eine Riser-Karte mit angeschlossener GPU startet nicht.

    rock64@rockpro64v2_1:~$ uname -a Linux rockpro64v2_1 4.4.132-1075-rockchip-ayufan-ga83beded8524 #1 SMP Thu Jul 26 08:22:22 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
  • FrankMF

    stretch-minimal-rockpro64

    Verschoben Linux
    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
    2
    0 Stimmen
    2 Beiträge
    901 Aufrufe
    FrankMF

    Ich habe das jetzt mal endlich getestet 🙂

    https://forum.frank-mankel.org/topic/296/rockpro64-docker-image