Skip to content

ROCKPro64 - USB3

ROCKPro64
  • Man liest ja immer viel über Probleme mit dem USB3-Port auf dem ROCKPro64. z.B. hier

    Nachdem ich heute mein NAS mal wieder ins Gehäuse eingebaut habe, habe ich ein wenig gespielt. Hier lag eine SanDisk Ultra 3D SSD mit 1TB rum, da die SD-Karte ziemlich voll war, bot es sich an diese SSD zum Rootdevice zu machen.

    Alles so gemacht, wie immer. Alles kopiert, SSD umbenannt in linux-root und neugestartet. So sieht das jetzt aus.

    rock64@rp64v_2_1_NAS:~$ df -h
    Filesystem      Size  Used Avail Use% Mounted on
    udev            978M     0  978M   0% /dev
    tmpfs           198M  664K  198M   1% /run
    /dev/sda        916G   63G  807G   8% /
    tmpfs           990M     0  990M   0% /dev/shm
    tmpfs           5,0M  4,0K  5,0M   1% /run/lock
    tmpfs           990M     0  990M   0% /sys/fs/cgroup
    /dev/mmcblk0p6  112M  4,0K  112M   1% /boot/efi
    tmpfs           198M     0  198M   0% /run/user/1000
    /dev/md0        1,8T  723G 1018G  42% /mnt/raid
    

    Es gibt ein Raid, die SSD am USB3 die das Rootdevice darstellt. Diese Konstruktion hat den Vorteil, das man auch den Kernel updaten kann, weil das Bootdevice weiterhin auf der SD-Karte liegt. Aktuell läuft dieser Kernel.

    rock64@rp64v_2_1_NAS:~$ uname -a
    Linux rp64v_2_1_NAS 5.0.0-1101-ayufan-g41eeb7cd789e #ayufan SMP PREEMPT Fri Mar 8 22:14:59 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
    

    Ok, dann mal ein kleiner Test. Wir kopieren mal alle Star Wars Filme vom Haupt-NAS. Das NAS bilden zwei mechanische HDD's. Der Kopiervorgang erfolgt auf die an USB3 hängende SSD.

    rock64@rp64v_2_1_NAS:~$ scp -r root@192.168.3.243:/mnt/nas/Videos/"Star_Wars" /home/rock64/
    root@192.168.3.243's password: 
    Star_Wars_I.ts                       100% 6753MB  83.7MB/s   01:20    
    Star_Wars_IV.ts                      100% 7668MB  83.5MB/s   01:31    
    Star_Wars_VI.ts                      100% 7871MB  83.4MB/s   01:34    
    Star_Wars_V.ts                       100% 7409MB  83.3MB/s   01:28    
    Star_Wars_III.ts                     100% 7169MB  83.0MB/s   01:26    
    Star_Wars_II.ts                      100% 6268MB  83.3MB/s   01:15
    

    Schwupps, alles da. Hätte ect. noch was schneller sein können, vermute aber das die mechanischen HDD's der Flaschenhals sind.

    So, kurz die SSD testen.

    rock64@rp64v_2_1_NAS:~$ 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, 10,7109 s, 401 MB/s
    

    Der dmesg ist völlig sauber, keine Auffälligkeiten in Bezug auf den USB3-Port. Da @tkaiser öfter von "Undervoltage" schreibt, ich nutze an diesem NAS das Original Netzteil von Pine64 in der 5A Ausführung.

  • 0 Votes
    5 Posts
    564 Views
    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

  • 0 Votes
    1 Posts
    531 Views
    No one has replied
  • 0 Votes
    5 Posts
    2k Views
    FrankMF

    Die Pinne für den Adapter liegen ja nur parallel zum Eingang des Steckers vom Netzteil. Also, solange da nichts abfackelt kann man da eine Menge Strom drüber jagen 🙂

    Wenn es funktioniert ist ja alles gut.

  • SPI funktioniert

    ROCKPro64
    4
    0 Votes
    4 Posts
    843 Views
    FrankMF

    Wie ich jetzt mehrmals festgestellt habe, ist das System von der USB3 Platte instabil.

    [111985.654653] EXT4-fs error (d4: inode #16354: comm systemd: r[111985.837719] EXT4-fs error

    Das killt dann das komplette System.

    Ob das an meiner Hardware liegt, weiß ich nicht. Also, wer da draußen so ein System einsetzen will, Vorsicht! Die USB3-Schnittstelle scheint noch einige Bugs zu haben!!

    Mein NVMe System dagegen ist absolut stabil!

  • 0 Votes
    1 Posts
    570 Views
    No one has replied
  • 0 Votes
    5 Posts
    2k Views
    FrankMF

    Ich sehe gerade, das könnte hier auch mal neu gemacht werden.

  • Benchmark Mainline 4.17.0-rc6

    Moved Archiv
    4
    0 Votes
    4 Posts
    961 Views
    FrankMF
    iozone 5GT/s x2 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 Jun 16 06:34:43 2018 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 48672 104754 115838 116803 47894 103606 102400 16 168084 276437 292660 295458 162550 273703 102400 512 566572 597648 580005 589209 534508 597007 102400 1024 585621 624443 590545 599177 569452 630098 102400 16384 504871 754710 765558 780592 777696 753426 iozone test complete. 2,5GT/s x2 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: Sun Jun 17 06:54:02 2018 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 49420 91310 102658 103415 47023 90099 102400 16 138141 202088 224648 225918 141642 202457 102400 512 335055 347517 375096 378596 364668 350005 102400 1024 345508 354999 378947 382733 375315 354783 102400 16384 306262 383155 424403 429423 428670 377476 iozone test complete.
  • 0 Votes
    5 Posts
    4k Views
    FrankMF

    Das Problem sollte mit Kernel 4.19.0-rc4-1069-ayufan behoben sein.