Skip to content

ROCKPro64: NAS mit PCI-e SATA-III Aufrüsten

ROCKPro64
  • @neo Hab nochmal genauer gelesen. Du verbaust

    • 2 * 3,5 Zoll HDD
    • 1 * 2,5 Zoll HDD

    Das sollte mit dem Netzteil kein Problem sein. Sollte die 2,5 Zoll das System sein, könnte man eine flotte SSD einbauen und noch was Strom sparen.

    Seltsam, ich hatte mit der ASM1062 nur Theater und ich weiß, das ich nicht alleine war.

    Viel Spaß beim Bauen und in Betrieb nehmen. Ich werde bei Gelegneheit mein NAS auch noch mal anfassen. Ziel soll sein, alles zu verschlüsseln. System, Flatten usw.

    Dabei wird dann auch mal ein aktueller U-boot installiert und ein frisches System. Da ich das aber produktiv nutze, brauche ich da ein wenig Zeit für. Die suche ich noch 😉

    Dir viel Spaß beim Umbauen und in Betrieb nehmen. Über Berichte ob es klappt usw. freue ich mich immer wieder sehr.

  • @frankm sagte in ROCKPro64: NAS mit PCI-e SATA-III Aufrüsten:

    Das sollte mit dem Netzteil kein Problem sein. Sollte die 2,5 Zoll das System sein, könnte man eine flotte SSD einbauen und noch was Strom sparen.

    Sehr gut, werde es mit dem "Standard" Netzteil probieren!

    10 TB 3,5 ZOLL HDD - Sollte auch kein Problem für die BEYIMIE PCIe SATA Karte 4 Port sein, oder?

    Zur SSD:
    Derzeit wird für das System 64GB eMMC Module benutzt.
    Frage:

    • Lohnt sich das System über eine SSD zu booten? Wie sind da die Erfahrungen oder Technische Daten wie Geschwindigkeit etc. ?

    Ich habe gesehen du hast in deinem Post hdparm "manuel" eingerichtet. Ich dagegen habe das im OMV eingestellt. Gibt es ein unterschied bzw. besser "manuel" als über OMV?

    Des weiteren habe ich eine frage zur Lüfter seitlich im NAS Casing 80x80 mm bzw. zur Kühlung.
    Auf dem ROCKPro64 ist nur ein Stecker für ein Lüfter vorgesehen (4 J8 +FAN- 2 PWM controlled fan header), den ich für die CPU verwende und über ATS steuere. Derzeit läuft der besagter seitlicher Lüfter über ein separaten micro-Arduino mit einem Temperatur Sensor, den ich Pi*Auge auf ca. 43 °c ON und ca. 60sec OFF eingestellt habe (schon lange her).
    Frage:

    • Es gibt garantiert eine bessere Lösung!? Ist es möglich die Pi-2 bus zB. Pin 14 (wie bei RaspberryPi) zu nutzen und die HDD Temperatur abgreifen und den Lüfter ON OFF zu steuern? Ein Script dazu?

    @frankm sagte in ROCKPro64: NAS mit PCI-e SATA-III Aufrüsten:

    Seltsam, ich hatte mit der ASM1062 nur Theater und ich weiß, das ich nicht alleine war.

    Vll habe ich keine große Ansprüche. Die Festplatten wird mit Daten gefüllt um auf Endgeräten es wiederzugeben, nicht viel mehr. Funktioniert schon Jahre lang!

    @frankm sagte in ROCKPro64: NAS mit PCI-e SATA-III Aufrüsten:

    Viel Spaß beim Bauen und in Betrieb nehmen. Ich werde bei Gelegneheit mein NAS auch noch mal anfassen. Ziel soll sein, alles zu verschlüsseln. System, Flatten usw.

    Dabei wird dann auch mal ein aktueller U-boot installiert und ein frisches System. Da ich das aber produktiv nutze, brauche ich da ein wenig Zeit für. Die suche ich noch 😉

    Dir viel Spaß beim Umbauen und in Betrieb nehmen. Über Berichte ob es klappt usw. freue ich mich immer wieder sehr.

    Vielen dank, den Spaß werde ich garantiert haben 😊
    Deine weitere Posts werde ich weiter verfolgen, sehr interessant und immer was neues zu lernen! Danke dafür!

  • @neo

    Ob eine 10TB an dem Adapter geht, kann ich dir leider nicht sagen, ich würde aber davon ausgehen.

    Ah, er nutzt ein eMMC Modul fürs System. Wenn es das macht, was es soll, würde ich es so laufen lassen. Zu Geschwindigkeiten sollte sich hier im Forum, tief vergraben weil schon länger her, sicher was finden lassen.

    Wie Du hdparm einstellst, sollte egal sein. Wenn Du es über das Webinterface von OMV machen kannst und es funktioniert ist ja alles prima. Ich nutze ja meine Systeme fast alle Headless, darum muss ich da immer an die Konsole 😉

    Zum Thema Lüfter, ja habe ich mal getestet, brauch ich nicht auf einem ROCKPro64. Ich hasse Lüfter! Der große Kühlkörper reicht völlig aus, mein NAS läuft so schon ewig und in dem Gehäuse ist zwar ein zusätzlicher Lüfter verbaut aber nicht angeschlossen. Was da evt. noch was Wind macht ist das Netzteil, das war's.
    Man sollte das evt. im Auge behalten, wenn man da permanent die CPU am Limit benutzt. Mein NAS sichert morgens alle Webseiten, Datenbanken usw. Danach ist Pause bis ich wieder zu Hause bin. Dann nutze ich das NAS noch als NFS Server. Aber, so oft greife ich da auch nicht drauf zu. Soll heißen, der ROCKPro64 wird sich sicherlich die meiste Zeit langweilen...

  • @frankm
    Sehr gut! Dann werden ich die Lieferung nächste Woche abwarte und über Erfolg oder Probleme Berichten!

  • @neo Stand der Dinge? Erfahrungen, Probleme?

  • @frankm aus Zeit mangel hat sich der Umbau in die Länge gezogen, jetzt ein kleinen Einblick auf den jetzigen Stand!

    SBC:

    $ uname -a
    Linux RockHomeServer 5.10.21-rockchip64 #21.02.3 SMP PREEMPT Mon Mar 8 01:05:08 UTC 2021 aarch64 GNU/Linux
    

    Eingebauten HDD:

    • 500GB Disk model: WDC WD5000LUCT-63RC2Y0
    • 8TB - Disk model: ST8000VN0022-2EL
    • 10TB - Disk model: ST10000VN0008-2PJ103

    Aufrüst Artikel:

    Test:

    $ lspci
    00:00.0 PCI bridge: Fuzhou Rockchip Electronics Co., Ltd RK3399 PCI Express Root Port
    01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9215 (rev 10)
    

    Eingebunden über OMV
    mount.png

    $ blkid
    /dev/mmcblk2p1: UUID="4c710410-bb67-49b3-8272-e7d1fdf5e9ae" TYPE="ext4" PARTUUID="df7a56c6-01"
    /dev/sda1: LABEL="Daten4" UUID="f2d5e525-2aa1-44f0-aa53-df5d03d4b6cb" TYPE="ext4" PARTUUID="1d7e383d-1c7d-4d1e-ac34-7942bb0eb304"
    /dev/sdb1: LABEL="Daten2" UUID="8d1e1a98-758c-43a7-bf48-383db52c96f8" TYPE="ext4" PARTUUID="ab473501-0aff-4914-934c-3c47c9951cdd"
    /dev/sdc1: LABEL="Daten3" UUID="8859d90b-152f-4a9e-a426-90280878631c" TYPE="ext4" PARTUUID="7ee795e3-6792-41d8-959f-3dc74649d47a"
    /dev/mmcblk2: PTUUID="df7a56c6" PTTYPE="dos"
    

    OMV Physikalische Platteneinstellungen (hdparm)
    Platteneinstellungen

    Speed Test der bei mir Standard mäßig verwendet wird:
    speed

    Temperatur:

    $ 'date' && sudo hddtemp /dev/sda && sudo  hddtemp /dev/sdc && sudo hddtemp /dev/sdb && sudo hdparm -C /dev/sda && sudo hdparm -C /dev/sdc && sudo hdparm -C /dev/sdb
    Do 11. Mär 13:30:17 CET 2021
    /dev/sda: ST10000VN0008-2PJ103: Laufwerk schläft
    /dev/sdc: ST8000VN0022-2EL112: Laufwerk schläft
    /dev/sdb: WDC WD5000LUCT-63RC2Y0: 39°C
    
    /dev/sda:
     drive state is:  unknown
    
    /dev/sdc:
     drive state is:  unknown
    
    /dev/sdb:
     drive state is:  active/idle
    

    Standby Temperatur ca. 40°C im Metal Desktop/NAS Casing.
    Temperatur.png

    Mein farzit:
    Ich bin zu 85% Prozent zufrieden. Es funktioniert und macht was es soll!
    Somit habe ich leider nicht viel gewohnen, das einzige dass meine 500GB HDD 2,5 Zoll platz im NAS Casing gefunden hat (vorher über externe USB Adapter angeschloßen).

    +

    • Festplatten wurden ohne Probleme erkant und Eingebunden.
    • Platteneinstellungen sind konfigurierbar.
    • Kein Ausfahl beobachtet.

    -

    • Seitliche LED leuchten permanent. (stört etwas)
    • Schreib / Lese geschwindigkeit ist langsamer geworden. (ca. 90 MiB/s vorher ca. 130 MiB/s)

    Desweiteren: (hängt aber am Software)
    hddtemp und hdparm zeigen falsche werde an.

    • Ausgabe von hddtemp ist permanent Laufwerk schläft
    • Ausgabe von hdparm ist drive state is: unknown

    Was erst zur verwirrung bei mir sorgte.
    Nach langem ausprobieren ist einfach, die Ausgabe von hddtemp: Laufwerk schläft ist zu ignorieren und nur bei Laufender / Aktiver HDD zu beachten um die Temperatur auszulesen.
    Beim hdparm: drive state is: unknown bedeutet das die HDD Aktiv ist. Und nur bei output standby ist auch würklich die HDD im standby und schläft!

    Thu Mar 11 18:22:15 CET 2021
    /dev/sda: ST10000VN0008-2PJ103: drive is sleeping
    /dev/sdc: ST8000VN0022-2EL112: drive is sleeping
    /dev/sdb: WDC WD5000LUCT-63RC2Y0: 40°C
    
    /dev/sda:
     drive state is:  standby
    
    /dev/sdc:
     drive state is:  standby
    
    /dev/sdb:
     drive state is:  active/idle
    

    Wird weiter beobachtet, scheint aber gut zu funktionieren!
    Frage:

    • Wurde alles korrekt durchgeführt?
    • Kann man die Schreib / Lese geschwindigkeit beeinflussen?
  • @neo Danke für den tollen Einblick in dein NAS Projekt 👍

    Geschwindigkeit der Platten!? @tkaiser Liest Du hier noch mit?

  • @frankm Mit Geduld und Spucke recht die Leistung für meine Zwecke, schnellere Schreib / Lese Geschwindigkeit sind wahrscheinlich nicht zu erreichen?

  • @neo Ich denke, da wird nicht viel mehr gehen.

    In einem per Gigabit-LAN angebundenen NAS kommen wir auf konstant 113 Megabyte pro Sekunde – sehr gut! Bei einem büropraxisnahen "4K Random"-Test im NAS kommen wir sowohl beim Lesen als auch beim Schreiben auf Werte von 70 bis 100 Megabyte pro Sekunde.

    Ist nicht exakt die gleiche Platte, nur so als Anhaltswert.

    Quelle: https://www.pc-magazin.de/testbericht/seagate-nas-hdd-8-tb-test-st8000vn0002-review-praxis-3196172.html

  • @frankm Alles Klar!
    Wie schon erwähnt, für meine Zwecke rechts! Die Jahre über hat gute Dienste geleistet (PCI-e und HDD) und wird hoffentlich auch noch ein paar Jahre bis zum nächsten Umbau tun!
    Vielen Dank!

  • 0 Stimmen
    8 Beiträge
    1k Aufrufe
    FrankMF

    Die Verlinkung hatte ich überlesen, sorry.

    Es gibt nur eine Handvoll Karten, die im PCIe Port funktionieren. Warum, kann ich dir leider nicht beantworten. Es liegt aber mit Sicherheit an falschen Einstellungen im Kernel und an fehlenden Treibern. Ich habe hier auch eine andere Karte rumliegen, die erzeugt immer nur eine Kernel Panic 😞

    In diesem Thread steht einiges was geht und was nicht.
    https://forum.pine64.org/showthread.php?tid=6459

  • 0 Stimmen
    1 Beiträge
    463 Aufrufe
    Niemand hat geantwortet
  • 0 Stimmen
    8 Beiträge
    1k Aufrufe
    FrankMF

    Nach

    make modules_install

    kommt am Ende

    INSTALL net/netfilter/xt_physdev.ko INSTALL sound/core/snd-rawmidi.ko INSTALL sound/soc/codecs/snd-soc-es8316.ko DEPMOD 4.18.8-77394-g8cce48cacf88

    Das brauchen wir 😉

    Dann wie vom André geschrieben, einfach weitermachen. Danach neustarten

    sudo reboot

    Der neue Kernel wird geladen

    rock64@rockpro64:~$ uname -a Linux rockpro64 4.18.8-77394-g8cce48cacf88 #1 SMP PREEMPT Mon Sep 17 18:50:57 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

    Ich habe aber zwei Probleme.

    Ich sehe nicht wo der Kernel schneller sein soll als der vom Kamil!?

    Bei Updaten mit apt-get upgrade wird in meinen Augen, die falsche initrd.img aktualisiert.

    update-initramfs: deferring update (trigger activated) Setting up initramfs-tools (0.130ubuntu3.3) ... update-initramfs: deferring update (trigger activated) Processing triggers for initramfs-tools (0.130ubuntu3.3) ... update-initramfs: Generating /boot/initrd.img-4.4.132-1075-rockchip-ayufan-ga83beded8524 cryptsetup: WARNING: could not determine root device from /etc/fstab

    ABER, ich nix Kernel Guru 🙂

    Vielen Dank André, ich weiß das viele da draußen auf aktuelle Kernels stehen 🙂 Mit deinem haben sie jetzt einen sehr aktuellen Kernel. 4.18.8 ist auf kernel.org ein stable Kernel. Kann man also sehr schön für einen headless Server einsetzen. DANKE!

  • Neuer Bootprozeß seit 0.7.x

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    843 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - Der Bootvorgang

    Verschoben Hardware
    3
    0 Stimmen
    3 Beiträge
    1k 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.

  • 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
  • stretch-minimal-rockpro64

    Verschoben Linux
    3
    0 Stimmen
    3 Beiträge
    983 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
  • ROCKPro64 - PCIe x4

    Verschoben Hardware
    13
    0 Stimmen
    13 Beiträge
    5k Aufrufe
    FrankMF

    @Northstar Hallo, laut meinen Info's nicht, hat irgendwas mit der Speicheradressierung zu tuen. Und Grafikkarten benötigen wohl zu viel. Das ist das, was ich bei den vielen Diskussionen im IRC so aufgeschnappt habe.

    Ich habe es auch schon mal genauso probiert - natürlich ohne Erfolg.