ui spannend .. magst du mal die i/o nvme geschwindigkeiten anschauen (sofern noch das image auf der sd karte klebt) ?
Spannend wäre auch ob die 970 Pro hier ggü. einer evo dann etwas mehr leistung entfalten darf ... vermutlich sind wir jetzt schon am leistungslimit vom chipdesign / controller Design ... wobei der 4.14 ggü. dem 4.4 ja schon etwas performanter war (wenn ich mich an deine "Aufzeichnungen" richtig erinnere)
@FrankM
genau .. 5.er Kernel , nvme i/o tests ... mit der evo gibt es bestimmt auch schon valide daten ggü. dem 4.4 bzw. 4.14 er Kernel ..
Genau .. das kommende es-gibt-wohl-wieder-schnee Wochenende ist doch ideal für ein paar dd und iozone tests 
vielleicht schaffe ich es dann auch auf dem nanopc-t4 mit einer 970-er pro und armbian 5.0 nightly build anzuwerfen .. dann stimmen wir uns in den dd parametern ab und dann wirds spannend 
ach halt .. deine 970er ist ja gerade geblockt .. egal ..
Ich habe die Beiträge in einen neuen Thread gepackt, macht mehr Sinn. Anfangen möchte ich mit dem 4.4er Kernel.
Wie immer bionic-minimal vom Kamil als arm64 Variante. Frisch geflasht
root@rockpro64:/mnt# uname -a
Linux rockpro64 4.4.167-1169-rockchip-ayufan-g3cde5c624c9c #1 SMP Thu Apr 4 19:38:24 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
root@rockpro64:/mnt# sudo iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Iozone: Performance Test of File I/O
Version $Revision: 3.429 $
Compiled for 64 bit mode.
Build: linux
Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
Al Slater, Scott Rhine, Mike Wisner, Ken Goss
Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
Vangel Bojaxhi, Ben England, Vikentsi Lapa.
Run began: Sat Apr 13 07:15:59 2019
Include fsync in write timing
O_DIRECT feature enabled
Auto Mode
File size set to 102400 kB
Record Size 4 kB
Record Size 16 kB
Record Size 512 kB
Record Size 1024 kB
Record Size 16384 kB
Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
102400 4 53691 74726 95278 100406 32336 73397
102400 16 141512 230736 270608 276241 117088 219330
102400 512 765527 618320 460791 466663 421756 574738
102400 1024 548344 618267 477060 482809 455256 616447
102400 16384 981282 1025945 1042460 1070255 1060418 1077068
iozone test complete.
rock64@rockpro64:/mnt/home/rock64$ sudo iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Iozone: Performance Test of File I/O
Version $Revision: 3.429 $
Compiled for 64 bit mode.
Build: linux
Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
Al Slater, Scott Rhine, Mike Wisner, Ken Goss
Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
Vangel Bojaxhi, Ben England, Vikentsi Lapa.
Run began: Sat Apr 13 07:34:27 2019
Include fsync in write timing
O_DIRECT feature enabled
Auto Mode
File size set to 102400 kB
Record Size 4 kB
Record Size 16 kB
Record Size 512 kB
Record Size 1024 kB
Record Size 16384 kB
Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
102400 4 52724 85611 96132 96179 43825 73438
102400 16 173917 242533 272914 275620 128849 228634
102400 512 618052 587583 475708 482322 471034 583193
102400 1024 574190 654421 504860 508539 506036 652748
102400 16384 1058751 1084003 1094041 1131672 1131219 1174033
iozone test complete.
Und jetzt geht es an den Test mit Kernel 5.0, kann was dauern. Ich nehme an, das mein WLan-Modul rumzickt und ich das erst ausbauen muss.
Ok, WLan-Modul konnte drin bleiben.
rock64@rockpro64:~$ uname -a
Linux rockpro64 5.0.0-1105-ayufan-g2d7c76c290dc #ayufan SMP PREEMPT Wed Apr 10 20:57:24 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
rock64@rockpro64:/mnt$ sudo iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Iozone: Performance Test of File I/O
Version $Revision: 3.429 $
Compiled for 64 bit mode.
Build: linux
Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
Al Slater, Scott Rhine, Mike Wisner, Ken Goss
Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
Vangel Bojaxhi, Ben England, Vikentsi Lapa.
Run began: Sat Apr 13 07:55:10 2019
Include fsync in write timing
O_DIRECT feature enabled
Auto Mode
File size set to 102400 kB
Record Size 4 kB
Record Size 16 kB
Record Size 512 kB
Record Size 1024 kB
Record Size 16384 kB
Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
102400 4 106118 155876 170478 174076 55705 152829
102400 16 325935 419464 446687 454111 200115 417213
102400 512 1008052 997206 902058 943787 761051 994723
102400 1024 1142701 1131917 1069307 1116475 973106 1126759
102400 16384 1376096 1379277 1397557 1473713 1458105 1368219
iozone test complete.
rock64@rockpro64:/mnt/home/rock64$ sudo iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Iozone: Performance Test of File I/O
Version $Revision: 3.429 $
Compiled for 64 bit mode.
Build: linux
Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
Al Slater, Scott Rhine, Mike Wisner, Ken Goss
Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
Vangel Bojaxhi, Ben England, Vikentsi Lapa.
Run began: Sat Apr 13 07:51:04 2019
Include fsync in write timing
O_DIRECT feature enabled
Auto Mode
File size set to 102400 kB
Record Size 4 kB
Record Size 16 kB
Record Size 512 kB
Record Size 1024 kB
Record Size 16384 kB
Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
102400 4 105916 156590 172350 172827 67990 152875
102400 16 315801 432155 448563 456037 227274 425530
102400 512 1046853 1060371 984766 1040722 984416 1062911
102400 1024 1111569 1045536 980203 1039013 1011528 1099751
102400 16384 1379277 1391045 1435614 1519402 1518702 1387184
iozone test complete.
Es lohnt sich, bei einem Webserver den 5er Kernel zu nutzen. Man kommt an die angegebenen Grenzwerte zwar nicht ganz ran, aber es sollte reichen
Schreiben soll die 960 EVO mit bis zu 1900 MB/s, 1,45 erreichen wir. Die 970 EVO soll bis zu 2300MB/s erreichen.
Wir erreichen also nicht die maximalen Datenraten. Wir haben aber mit der NVMe SSD das deutlich schnellste Speichermedium auf einem ROCKPro64. Auch der wichtigste Grund, warum ich dieses SOC gewählt hatte.
Und zum Schluss noch ein Test von meinem Haupt-PC mit LinuxMint Cinnamon. Verbaut ist eine 970 PRO mit 512GB RAM.
frank@frank-MS-7A34:~$ sudo iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Iozone: Performance Test of File I/O
Version $Revision: 3.429 $
Compiled for 64 bit mode.
Build: linux-AMD64
Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
Al Slater, Scott Rhine, Mike Wisner, Ken Goss
Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
Vangel Bojaxhi, Ben England, Vikentsi Lapa.
Run began: Sat Apr 13 10:07:45 2019
Include fsync in write timing
O_DIRECT feature enabled
Auto Mode
File size set to 102400 kB
Record Size 4 kB
Record Size 16 kB
Record Size 512 kB
Record Size 1024 kB
Record Size 16384 kB
Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
102400 4 91288 109229 125357 111882 48602 113120
102400 16 212148 290553 315840 324209 143475 255918
102400 512 529645 519399 594357 369504 358862 557379
102400 1024 513924 527201 472714 612531 459192 564747
102400 16384 1382033 1464444 1780091 2142542 2130013 1566495
iozone test complete.
nur auf die schnelle zwischendurch .. Super, dass du Dir die Mühe gemacht hast. Ich bin überhaupt kein Experte in iozone Werten deuten, jedoch schaut dies auf den ersten und zweiten Blick schon stark nach einer fetten Leistungssteigerung im 5.er Kernel aus .. Wow ... und jetzt geh ich mal ans basteln .. (während draussen der Schnee fällt)
@webstudio Mit Sicherheit, irgendwann schon mal. Sollte normalerweise genauso funktionieren. Ist aber was tricky mit den Kerneln. Ich würde erst alles auf der SD-Karte machen. Wenn das klappt, dann alles auf die SSD kopieren. Root-Device Eintrag ändern und neustarten.
Ich habe bis heute immer noch nicht zu 100% kapiert, wie das mit dem Kernelupdate auf so einem System einwandfrei funktioniert. Bekomme es zwar immer hin, ist aber furchtbar viel Fummelei. Vermutlich bin ich dafür zu blöd
Wird Zeit das der u-boot direkt von einem PCIe Device booten kann träum
Hmmpf .. so richtig erfolgreich war der 5.00er Kernel-Einsatz leider nicht.
Jedoch:
der Nanopc-t4 ist in seinem acrylglas Käfig eingebaut und mit Strom und einer 970 Pro - 500 Gb unterfüttert ... Das "Update" System beim Nano ist etwas anderst als bei unserem RockPro64, da er einen eingebauten emmc 16 GB Speicher hat und hier gerne selbst seine Flashes durchführen möchte. Mein Erstversuch (okay .. ich hätte wohl rtfm zuvor machen sollen) einfach ein Armbian-5.00er Kernel Image per etcher auf eine SD zu kopieren, wurde dann beim Neustart mit Stillstand quittiert .. Achja, dank des eingebauten emmc Speichers, war beim Erst-Start das System schon mit einem Android OS versorgt und wäre damit auch Einsatzbereit gewesen ..
Dann Schrittweise durch die Wikis gegangen und irgendwann war der Bogen raus. Flasher-Image auf eine SD Karte (aber bitte nur mit win32diskimager 
) und die gewünschten Images auf einen USB Stick .. Dann per schöner Desktop-Oberfläche, das Image auswählen und 30 Sekunden später war der Neustart da .. Ich habe dann mal so einiges was in der 4.4er Kernel Welt war ausprobiert, jedoch liegt der Scherpunkt der meisten Images auf Desktop / Tablet Einsatz. Dank eingebautem WLAN mit zwei schnuckeligen Antennen und sonstigem Schnick Schnack (IR Epmfänger, Bluetooth (?) usw. ) wäre hier vermutlich sein Haupteinsatzgebiet .. Setop-Box / Multimedia / Retrogaming . Aber ich will ja, I/O Speed, Server, MariaDB, Node.js ...
Das Armbian 5.00er Dev-Image wollte gar nicht, egal ob mit oder ohne oder doch per USB-C (das war dann allerletzte Versuch, mit "schwindeligen" Windows-Device Treibern von irgendeinem Shanghai-Server (ich will nicht wissen, was ich da jetzt alles im Hintergrund laufen habe .. NIx .. nada .. 5.00er / Armbian OS will (noch) nicht (bei mir).
Dann war ja noch die Idee, den Rocky mit einem 5.00er Kernel zu versorgen (die 30 - 50 % Transferspeed gewinn aus deinen Tests machen hier Appetit ..) Jedoch, mein RockPro64 will einfach kein 0.7er Image mehr laden. Brücken von Pin 23-25 oder Ersase SPI mehrfach durchgeführt .. das interessiert ihn nicht. Er startet, wenn ein Ladbares Image auf SD oder EMMC Modul, dann immer mit rot-und-weißer LED , was bei mir erst nach 0.8 Image "eingeschaltet" wurde .. Und irgendwann nochmals die RS232 andocken, war mir dann doch zu blöd .. Dann bleibts halt wie es ist ..
Und die Messwerte habe ich trotzdem mal abgespeichert und hier dran-gehängt:
Rot = RockPro64, 970 EVO , 500 GB, Ayufan / 4.4er Kernel
Ocker = NanoPC T4, 970 PRO , 500 GB, Armbian / 4.4er Kernel
Ergo, momentan ist der Kernel 4.4 der Bottelneck, hattest du ja auch schon vor x-Monaten ermessen .. die 970 PRO kann sich hier zwar ein wenig besser aus der Affäre ziehen, jedoch sind deine 5.0er Werte nicht zu erreichen.
Achja, nachdem mein Monitor heute auch mal am Nano hing, ist mir aufgefallen, dass mein RockPro64 ohne angeschlossenen Monitor (der auch gerne im Standby sein darf) nicht startet ...
Und bzgl. dem System auf nvme kopieren .. ist das Armbian einfach zucker .. Das fehlt dem Ayufan .. so richtig ..
Wenn jemand richtig Zeit und Lust hätte könnte man sich ja am Armbian nand-sata Script orientieren:
Armbian Linux build framework generates custom Debian or Ubuntu image for x86, aarch64, riscv64 & armhf - build/packages/bsp/common/usr/sbin/nand-sata-install at master · armbian/build
GitHub (github.com)
Achja #2 .. BTRFS unter Armbian auf das Pro auch mal ausgetestet (wäre dann eine Vergleichseinheit für mein mysql-jbd2-nvme-nachhink-thema gewesen .. ) aber ganz schnell wieder runtergemacht, da er seltsamen "Schluckauf" beim Kopieren von ein paar 20 GB Files bekommen hat .. Irgendwie wollen die RK3399/NVME mit BTRFS nicht so richtig bei mir ...
Achja #3: .. der NanoPC-T4 ist bei mir ggü. dem Rockpro wie eine hochgeschaltene Herdplatte .. Das RockPro64 Mainboard Design scheint hier etwas besser zu sein, was die Wärem-Verteilung / Ableitung angeht .. (ist ja auch rd. 30 Prozent größer) ... Aber .. und ich merke erst, wie ich ihn vermisst habe: ein Shutdown -r geht beim nano einwandfrei .. ohne meine Fritz-Box-Dect-Stromschalt Logistik .. Ach .. wie man sich doch an Kleinigkeiten erfreuen kann
Und nur für-s Protokoll meine Werte
Oh, morgens beim Kaffee viel zu lesen
Kurz was zum Nanopc-t4, das war das Board, wo ich damals schon geschrieben habe, wie man da die Wärme weg bekommt!? Ok, bleiben wir beim ROCKPro64
Dann war ja noch die Idee, den Rocky mit einem 5.00er Kernel zu versorgen (die 30 - 50 % Transferspeed gewinn aus deinen Tests machen hier Appetit ..) Jedoch, mein RockPro64 will einfach kein 0.7er Image mehr laden. Brücken von Pin 23-25 oder Ersase SPI mehrfach durchgeführt .. das interessiert ihn nicht. Er startet, wenn ein Ladbares Image auf SD oder EMMC Modul, dann immer mit rot-und-weißer LED , was bei mir erst nach 0.8 Image "eingeschaltet" wurde .. Und irgendwann nochmals die RS232 andocken, war mir dann doch zu blöd .. Dann bleibts halt wie es ist
Den Teil verstehe ich nicht. Woher soll er denn das 0.7er Image laden???
Achja, nachdem mein Monitor heute auch mal am Nano hing, ist mir aufgefallen, dass mein RockPro64 ohne angeschlossenen Monitor (der auch gerne im Standby sein darf) nicht startet ...
Kurzer Test, mit einem container image, kein Problem. Ob mit oder ohne Monitor am HDMI. (0.8rc5)
Wenn jemand richtig Zeit und Lust hätte könnte man sich ja am Armbian nand-sata Script orientieren:
Da habe ich auch schon mal drüber nachgedacht....
Achja #2 .. BTRFS unter Armbian auf das Pro auch mal ausgetestet (wäre dann eine Vergleichseinheit für mein mysql-jbd2-nvme-nachhink-thema gewesen .. ) aber ganz schnell wieder runtergemacht, da er seltsamen "Schluckauf" beim Kopieren von ein paar 20 GB Files bekommen hat .. Irgendwie wollen die RK3399/NVME mit BTRFS nicht so richtig bei mir ...
Die Probleme kenne ich, selbe Erfahrung gemacht.
@FrankM sagte in NVMe SSD Speed auf Kernel 5.0 von Kamil:
Kurz was zum Nanopc-t4, das war das Board, wo ich damals schon geschrieben habe, wie man da die Wärme weg bekommt!? Ok, bleiben wir beim ROCKPro64
Hmm .. nix dazu im Forum bei dir gefunden .. nach wärme , nano usw. gesucht ..
Den Teil verstehe ich nicht. Woher soll er denn das 0.7er Image laden???
Von seiner SD .. ein bisschen wirr von mir beschrieben.
Nackter Rockpro, ohne USB-Devices, ohne NVMe, ohne emmc, ..
Ablauf 1:
SD Karte mit 0.7er Image (das bisher immer funktioniert hatte) rein -> Rockpro geht an, beide LEDs gehen an (was aber bisher nur die weisse war), kein weiterer Boot-Vorgang.
Ablauf 2:
SD Karte mit 0.8er Image (gleiche SD Karte) rein -> Rockpro geht an, perfekter Boot Vorgang.
Das Monitor "Problem" und das 0.7er scheinen hier ggf. zusammen zu hängen, jedoch - mehr debugging nur mit der RS232 möglich, ggf. Mist im First-Stage-Loader ..
(Erase SPI , etc. alles hatte nichts verändert ..)
Wenn jemand richtig Zeit und Lust hätte könnte man sich ja am Armbian nand-sata Script orientieren:
Da habe ich auch schon mal drüber nachgedacht....
Ich würde 5$ Patreon Money dazu geben
Einen schönen Sonntag.