Skip to content

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

ROCKPro64
  • @frankm
    Vielen Dank für die schnelle Antwort.
    Danke für dein Ausführliche Bericht, sehr Informationsreich, übersichtlich!
    Dann fehlt mir die Entscheidung mit der Karte leicht. BEYIMIE PCIe SATA Karte 4 Port und Stromadapter sind im Warnkorb.

    Zur deiner Frage: JA die ASM1062 läuft störungsfrei, bzw. keine große Probleme schon seit ca. 3 Jahren!

    Zum Netzteil nochmal, wie erwähnt hat bis jetzt alles gut gelaufen, glaubst du dass nach meinem vorhaben (Umbau) mehr Strom benötigt wird? Es kommt ja so gesehen nichts dazu.
    Ich bin kein großer Bastler bzw. soll alles schön klein und fein bleiben im Metal Desktop/NAS Casing. Gibt es ein anderen Netzteil der zur ROCKPro64 passt?

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

  • ROCKPro64 - PCIe Probleme

    Hardware
    3
    0 Stimmen
    3 Beiträge
    330 Aufrufe
    FrankMF

    Danke für dein Feedback.

  • SATA - Booten jetzt möglich

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    256 Aufrufe
    Niemand hat geantwortet
  • Booten von USB3

    Verschoben ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    294 Aufrufe
    Niemand hat geantwortet
  • VON USB 4TB HD BOOTEN GEHT NICHT

    ROCKPro64
    5
    0 Stimmen
    5 Beiträge
    576 Aufrufe
    W

    Hallo FrankM,
    schade das Du mir nicht weiter helfen kannst, aber danke für Deine schnelle Antwort.
    Mit dem Bugreport kenne ich nicht aus, bin noch leihe.

    Einen schönen Abend noch.

    Winne

  • Mainline 4.20.0-rc6

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    414 Aufrufe
    Niemand hat geantwortet
  • [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
  • 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
  • 4GB Version - Out of stock

    Verschoben Archiv
    1
    0 Stimmen
    1 Beiträge
    709 Aufrufe
    Niemand hat geantwortet