USB Geschwindigkeit

  • Mich würde brennend interessieren was für Geschwindigkeiten man mit dem RPI maximal über eine USB Festplatte (bzw SSD) erreichen kann - habt ihr da Erfahrungen?


    Kann man damit höhere Geschwindigkeiten erreichen als über den SD Slot?




    Würde das überhaupt funktionieren zB eine SSD über ein 2,5" USB-Gehäuse nativ anzuschliesen, also ohne extra USB-Hub?


  • ...
    Würde das überhaupt funktionieren zB eine SSD über ein 2,5" USB-Gehäuse nativ anzuschliesen, also ohne extra USB-Hub?


    Hallo mein fleissiger Post-Freund ;) ...


    Am USB stehen Dir ca. 200 - 300 mA für beide USB-Ports zusammen zur Verfügung, sofern der RPi über den micro-USB Anschluss mit Strom versorgt wird.
    Du müsstest halt gewährleisten, dass Deine SSD in diesem Fall diesen Wert nicht erreicht bzw. überschreitet.


    Wenn die Versorgung des RPi über die GPIOs oder "rückwärtig" erfolgt, kannst Du da halt alles an Strom nutzen, was nach Abzug des RPi (ca. 700 mA) und der Peripherie übrig bleibt.


    Zu den Geschwindigkeiten kann ich im Moment nicht sagen ... hab' ich schon wieder verdrängt ... mal sehen,, ich stolpere schon mal wieder drüber.


    cu,
    -ds-


  • Mich würde brennend interessieren was für Geschwindigkeiten man mit dem RPI maximal über eine USB Festplatte (bzw SSD) erreichen kann - habt ihr da Erfahrungen?
    Kann man damit höhere Geschwindigkeiten erreichen als über den SD Slot?


    ich denke niemals


    wie soll das auch gehen, im SD sitzt die Software und der PI muss daraus seine Befehle lesen, interpretieren ggflls. auch zwischenspeichern und class10 Karten können gerne mal zicken, also nehmen wir lieber class6 oder langsamer und vorbei ist es mit der SD Geschwindigkeit


    http://de.wikipedia.org/wiki/SD_Memory_Card (class6 6MB/s class10 10MB/s wobei es da heftige Unterschiede in Lesen/Schreiben gibt !)


    Dein USB ist ja nur ein Teil der Kette, von wo nach wo sollen denn die Daten gehen ?
    Ich lese immer wieder alle müssen sich die theoretische USB2 Bandbreite teilen, also ist es egal ob es von USB nach USB geht oder von/nach Netzwerk, die Bandbreite wird mindestens halbiert. Ich hatte netto am USB2 selten mehr als 20 MB/s gesehen, im günstigsten Fall mal 22-25 MB/s nun teile das durch 2 von hin nach her höchstens 12 MB/s

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Die Class von SD Karten legt aber doch nur die Mindestrate fest, oder nicht? Also Class10 sind nicht alle 10MB/s schnell sondern auch schneller



    Warum ich frage ist das ich die ganzen Rom's und Iso's von Spielen die ich mit den Emulatoren von RetroPie nutzen möchte, ungerne alle auf die System SD kopieren möchte und irgendwie kommt mir meine SD auch lahm vor - einen brauchbaren schnelleren USB-Stick habe ich aber ebenfals nicht, aber noch eine SSD herrumliegen und die würde ja zumindest an einem PC eine höhere Geschwindigkeit erreichen :)


    Also netzwerk würde nur für Putty beansprucht werden und auch nur solange ich am rum basteln bin ;)


    Würde also bedeuten, mit einer SSD könnte ich problemlos Geschwindigkeiten von 20MB/s erreichen? (USB <-> RPI)

  • Tjaa ... also das mit der class 10 z.B. trifft ja nur eine Aussage über die Schreibgeschwindigkeit. Da muss aber jetzt imho nicht zwangsläufig ein Zusammenhang mit der Lesegeschwindigkeit bestehen.


    Das zweite, was mir da im Zusammenhang mit diesen Retro-Spielen einfällt, ist
    A: an welche Spiele Du speziell gedacht hast und
    B: welchen Emulator Du einsetzen willst.


    In meiner Vorstellung werden die ROMs der älteren Spiele wohl im Speicher gehalten, da ich mal davon ausgehe, dass sie nicht besonders gross sind und dadurch natürlich auch höhere Zugriffsgeschwindigkeiten möglich sind.


    Bei neueren Spielen, hier ist mal das SNES mit Zelda als Beispiel gefallen (übrigens imho das Beste, was Nintendo jemals geliefert hat).
    Ich fürchte fast, dass Du da ganz andere Probleme wie Zugriffszeiten bekommen wirst.
    Ich würde so vom Gefühl her sagen, dass der RPi damit mindestens aus- wenn nicht sogar überlastet ist.
    Diese SNES-Konsole (und meines Wissens erst recht die PS) hat imho einen ziemlich ausgefuchsten Grafikchipsatz und ist auf Spielekonsole optimiert. Und das zu emulieren ist schon heftig ....


    cu,
    -ds-


  • Würde also bedeuten, mit einer SSD könnte ich problemlos Geschwindigkeiten von 20MB/s
    erreichen? (USB <-> RPI)


    nö !


    wohin sollen denn 20MB/s ? OK der PI Version B hat 512 MB RAM


    ich zweifel aber stark das der die mit 20 MB/s füllen kann, kurzfristig vielleicht, aber nicht dauerhaft. Wohin willst du jede Sekunde die Daten schaufeln ? Der RAM ist irgendwann voll, allenfalls in den GPU MEM für Grafik (muss da nicht auch ab und an mal was von der CPU berechnet werden ?)


    lege eine RAMDISK an und messe mal kopieren von SD zu RAMDISK oder von USB zu RAMDISK und von SD zu USB


    aber RAMDISK im RAM anlegen wüsste ich jetzt nicht wie bei Debian z.B.
    Du setzt ja ein OS ein und das schnappt sich normalerweise den verfügbaren RAM, abzüglich von dir festgelegten GPU MEM, das würde also auf Kernel neu proggen hinauslaufen, das sich das OS nicht den Rest RAM vollständig nimmt.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Ja hallo,


    also ... jetzt hab' ichs wieder gefunden:



    Quote


    The Pi supports USB 2.0 specification which allows for transfer speeds up to 480Mbit/s or 60Mbyte/s. USB flash drives can reached up 33MBytes/s, but there seems to be some limitations in the NAND itself so it will come down to the type of stick you get. Also while these are bus speeds, I'm not sure the Pi is able to hit those full rates just because of the CPU speed in general. Also SD cards are more then capable of hitting that same read speed, so I see little benefit in booting from an USB flash stick.


    ist ein Ausschnitt von hier.


  • wohin sollen denn 20MB/s ?


    Vom USB-Device sachen laden, ob das dann in den Ram geladen wird weiss ich nicht - bei ROMs ist das vielleicht so aber nicht unbedingt bei 1GB ISO's :)


    Auf dem PC werden Spiele ja auch nicht vollständig in den Ram geladen, sondern es wird halt das geladen was gerade gebraucht wird - Spieledaten oder Videosequenzen usw und damit das schneller als über meine lahme SD geht suche ich halt nach brauchbaren Alternativen ;)



    lege eine RAMDISK an und messe mal kopieren von SD zu RAMDISK oder von USB zu RAMDISK und von SD zu USB


    aber RAMDISK im RAM anlegen wüsste ich jetzt nicht wie bei Debian z.B.



    Das anlegen einer tatsächlichen RAM-Disk geht so:

    Code
    sudo mkdir /media/RAM-Disk
    sudo mount -t ramfs ramfs /media/RAM-Disk


    Damit erhält man eine RAM-Disk, die sich (wie tmpfs) dynamisch der benötigten Größe anpasst.
    Aber im Gegensatz zu tmpfs wird bei ramfs kein SWAP verwendet (tmpfs nutzt irgendwann SWAP wenn es voll is).. Sobald aber das System (oder tmpfs) auf den SWAP zugreift, würde der Geschwindigkeitsvorteil der RAM-Disk komplett wieder zunichte gemacht werden..



    Du setzt ja ein OS ein und das schnappt sich normalerweise den verfügbaren RAM, abzüglich von dir festgelegten GPU MEM, das würde also auf Kernel neu proggen hinauslaufen, das sich das OS nicht den Rest RAM vollständig nimmt.


    Jein, Linux verbraucht nur soviel Ram wie es tatsächlich benötigt..
    Es mag nach einiger Zeit so aussehen als sei der Ram voll aber in Wirklichkeit ist der meiste Ram weiterhin als Cache/Buffer verfügbar, siehe free -m

    Code
    root@raspberrypi:~# free -m
                 total       used       free     shared    buffers     cached
    Mem:           121         94         26          0         20         47
    -/+ buffers/cache:         26         94
    Swap:          611          0        611
    root@raspberrypi:~#


    Das Ram-Managment von Linux ist auf jedenfall wesendlich besser als das von Windoof :D


    Da ich aber nur einen rev1 RPI habe, kann ich auch nicht sooo viel damit herrum experimentieren weil ich nur 256MB Ram zur Verfügung habe (plus zZt. 512MB Swap die bereits auf einen USB-Stick ausgelagert is, die ich zum kompilieren der ganzen Emus benötige sonst dauerts EWIG)



    Hm also ist die Geschwindigkeit die man über USB erreichen kann extrem davon abhängig wie ausgelastet die CPU vom RPI ist? Dass das auch auf die CPU Leistung ankommt ist mir quasi schon klar, wusste nur nicht das es beim RPI so extrem sein könnte..


    Naja, werde ich wohl ausprobieren müssen - aber "mindesten 30MB/s" wäre auf jedenfall schon mal wesendlich angenehmer :eek:

  • Oke jetzt merke ich gerade erstmals wie stark das Kopieren die CPU vom raspberry belastet...


    Kopiere gerade ein 1,3GB Image über WinSCP auf die SD und die auf 900MHz übertaktete CPU ist umdie 94% ausgelastet, die Geschwindigkeit betragt leider auch nur umdie 2,7MB/s :-/



  • Kopiere gerade ein 1,3GB Image über WinSCP auf die SD und die auf 900MHz übertaktete CPU ist umdie 94% ausgelastet, die Geschwindigkeit betragt leider auch nur umdie 2,7MB/s :-/


    so geht das doch nicht, dann ist das Netzwerk und win beteiligt,


    wenn dann teste das über putty mit Linux Befehle cp o.ä.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)


  • und über LAN gehen und nicht das wiederum verschlüsselte WLAN nutzen.


    Ich hab hier garkein WLAN ;)



    so geht das doch nicht, dann ist das Netzwerk und win beteiligt,


    wenn dann teste das über putty mit Linux Befehle cp o.ä.


    Ja ich weiss, das is ein bischen Offtopic gewesen aber war das erste mal überhaupt das ich eine grössere Datei (kein bash/php Script wie sonst) auf den RPI kopiert habe


    Aber kann man "cp" selber Geschwindigkeiten messen?
    kenne nur die gepatchten fileutils aber das zeigt soweit ich weiss auch nur die Zeit an...


    Mir wär nur "dd" und "hdparm" bekannt, wobei hdparm auch nicht "von - nach" kopiert


    Mit "dd" hab ich zB folgendes gemacht:


    Danach hab ich die 512MB Datei auf einen USB-Stick von mir kopiert und davon die Zeit bemessen:

    Code
    root@raspberrypi:~# date && cp datei1 /mnt/usbstick/ && date
    Di 20. Aug 10:50:45 CEST 2013
    Di 20. Aug 10:53:06 CEST 2013
    root@raspberrypi:~#


    ..also ca. 2min 21sec .. wären 141sec .. 512MB / 414sec = 3,63MB/s ?


    Mein USB-Stick wäre beim schreiben also wesendlich lahmer als meine SD...


    Nun besorg ich mir nachher wenn ich Feierabend habe ein USB Gehäuse für meine SSD und teste das dann noch mal damit - hoffentlich wird das besser ;)





    Achja, um genauere Werte (sekunden) zu kriegen und auch eine Berechnung, hab ich mir ein kleines PHP Script " speed " für die Konsole geschrieben
    Vorraussetzung: apt-get install php5


    Ausführbar machen: chmod +x speed


    Anwenden: ./speed /mnt/usbstick/datei1 /root/


    Ausgabe:

  • Moin,


    das mit der Zeitmessung hättest Du auch einfach mit:


    Code
    $ time cp /xy/z /uv/w


    machen können.
    Zudem weiss ich nicht, ob es eine gute Idee ist, die Zeiten von dd und cp zu vergleichen ... sind halt unterschiedliche Methoden und unterchiedliche Ansätze.


    Und - was auch schon erwähnt wurde: vergiss nicht zu berücksichtigen, dass sich LAN und USB den Bus teilen ...


    Wie gesagt, ich weiss nicht so recht, ob sich der Aufwand lohnt.
    Wenn es so ist, wie ich es mir eben bei Spielen vorstelle, dann wird es wohl komplett - oder zumindest möglichst komplett - in den Hauptspeicher geladen werden.
    Danach kommen u.a. andere Parameter ins Spiel, wie z.B. die Positionierungsgeschwindigkeit wenn Teile nachgeladen werden.


    cu,
    -ds-

  • Zudem weiss ich nicht, ob es eine gute Idee ist, die Zeiten von dd und cp zu vergleichen ... sind halt unterschiedliche Methoden und unterchiedliche Ansätze.


    Ist das nicht egal welche Methode dd oder cp verwenden? Beide schreiben auf den Dateinträger und benötigen dafür eine gewisse Zeit - anhand meiner Messung sind die Werte auch fast identisch, also wieso kann man das nicht vergleichen? ;)



    Und - was auch schon erwähnt wurde: vergiss nicht zu berücksichtigen, dass sich LAN und USB den Bus teilen ...


    Wie gesagt, ich weiss nicht so recht, ob sich der Aufwand lohnt.


    Naja ich möchte später ja nicht über LAN auf USB kopieren ... Die Images kopier ich einmal über den Windoof PC auf den USB-Datenträger und dann findet nur noch ein Transfer der Dateien zwischen USB und RPI statt, wie gesagt zum laden der Spiele -- bitte umgehend das mit LAN oder WLAN oder derartiges hierbei gleich wieder vergessen :D




    Wenn es so ist, wie ich es mir eben bei Spielen vorstelle, dann wird es wohl komplett - oder zumindest möglichst komplett - in den Hauptspeicher geladen werden.
    Danach kommen u.a. andere Parameter ins Spiel, wie z.B. die Positionierungsgeschwindigkeit wenn Teile nachgeladen werden.


    Hm wie gesagt, das mag vielleicht bei ROMs so sein aber nicht alle Emulatoren haben ROMs


    Damals hatten die Konsolen auch keine 1GB Ram, weswegen die auch damals schon nicht die Spiel-Daten komplett in den Ram geladen werden konnte, also wieso jetzt über die Emulatoren?


    Aber diesen Teil der Diskusion kann man sich denk ich getrost sparen.. Das laden würde, wenn es so abläuft wie ich es mir vorstelle, so oder so schneller sein - ob die Daten nun vom Datenträger komplett in den Ram geladen werden oder nur teilweise ist nebensächlich.. Komplett oder teilweise, das "laden" wäre durch einen wesendlich schnelleren Datenträger ebenfals wesendlich schneller und somit angenehmer = weniger wartezeit


    Da viele der schnelleren SD's probleme machen, wäre es für mich weniger Aufwand eine bereits vorhandene SSD über USB anzuschliesen anstatt 10 verschiedene SD's zu kaufen bis ich irgendwann mal eine hab die sowohl schnell wäre als auch mit dem RPI keine Probleme macht...


  • Hi,


    ist nicht ganz egal. Mag sein, dass der Unterschied bei Dir bezüglich der Dauer nur marginal ist. Aber bei richtiger Last summieren sich ein paar Tausend Zugriffe schnell auf. Zudem kommen bei verschiedenen Zugriffsmethoden Dinge wie User-/Kernelspace, Prozess- bzw pthread-Prioritäten, locking ... mit ins Spiel.


    Das mit dem LAN ist ja nur ein Hinweis das nicht aus den Augen zu verlieren, falls Du da mal was remote machen willst oder meinetwegen mit vnc. Dass Du das nur zum Kopieren verwendest ist, denke ich, schon klar ;) ...


    Dass die Emulatoren vermutlich so ein Spiel evtl. komplett ins RAM laden, falls möglich, hat aus meiner (Entwickler-)Sicht folgende Gründe:
    1. Die Konsolen hatten damals vermutlich zu wenig RAM und es war evtl. nicht notwendig hier zu versuchen Geschwindigkeit rauszuolen, weil sie eh auf Konsole optimiert waren. Heutzutage hast Du in der Regel ausreichend RAM zur Verfügung ... warum dann nicht nutzen?
    2. Der Aufwand und die Rechenpower, die für einen Emulator notwendig sind, wird gerne mal unterschätzt. Ich kann mich erinnern, dass es sehr lange Zeit keinen vernünftigen Emulator für die PS2 gabe, weil ein Dual- oder Quadcore PC damit überfordert war. Und da spart man natürlich Zeit, wo es nur geht.


    Und was das Nachladen betrifft ... das kann schon ganz schön was ausmachen. Ich erinnere mich an Textadventures die tierisch nervig waren, weil sie dauernd irgendwas nachluden.
    Und - wie vorher schon erwähnt - bei ein paar Tausend Zugriffen da kommt schon was zusammen.


    cu,
    -ds-

  • Hab mal noch ne blöde Frage:


    Wie sieht es mit AHCI beim RaspberryPI aus?
    Wird das irgendwie unterstützt, zB vom Kernel oder so durch laden eines Modules?


    Stehe jetzt nämlich vor einem möglichen Problem das kein TRIM Support vorhanden ist, obwohl meine SSD das definitiv kann


    Oder liegt das am USB3.0-Gehäuse?



    http://wiki.siduction.de/index…Linux_optimal_nutzen#BIOS



    /EDIT: Kann mich mal bitte jemand Ohrfeigen? Hab vergessen nen Aktiven USB-Hub zu nutzen und jetzt wird auch TRIM supportet :blush:



    Aber jetzt weiss ich immer noch nicht ob ich eine versteckte 1GB Partition anlegen muss (stichwort: partition alignment) um die Geschwindigkeit zu optimieren - unter Windows ist das ja der Fall :-/


    /EDIT2: Wie ich nun rauslesen konnte wird das mit Kernel 3.x bereits beim ausführen von fdisk -c -u /dev/sda automatisch erkannt und First sector default 2048 genutzt, somit hat sich das hoffentlich auch erledigt - nun erzeuge ich ein ext4 Dateisystem auf der SSD und über /etc/fstab eine entsprechend angepasste Zeile

    Code
    discard,noatime,errors=remount-ro

    einfügen.. Anschliesend teste ich die Speed und berichte dann... :)

  • So, nun hab ich mit der SSD einige Geschwindigkeits-Tests gemacht, gleiche Vorgehensweise wie in post#12


    Mit dd direkt auf der SSD:

    Code
    root@raspberrypi:/mnt/SSD# time dd if=/dev/zero of=datei1 bs=1M count=512
    512+0 Datensätze ein
    512+0 Datensätze aus
    536870912 Bytes (537 MB) kopiert, 20,6986 s, 25,9 MB/s
    
    
    real    0m20.727s
    user    0m0.020s
    sys     0m13.420s
    root@raspberrypi:/mnt/SSD#


    Kopieren mit cp von SD auf SSD:

    Code
    root@raspberrypi:/mnt/SSD# time cp /root/datei1 /mnt/SSD/
    
    
    real    0m29.583s
    user    0m0.090s
    sys     0m18.740s
    root@raspberrypi:/mnt/SSD#


    Kopieren mit cp von SSD auf SD:

    Code
    root@raspberrypi:/mnt/SSD# time cp /mnt/SSD/datei1 /root/
    
    
    real    0m57.282s
    user    0m0.030s
    sys     0m20.510s
    root@raspberrypi:/mnt/SSD#



    ..Aber da sieht man ja leider nicht die Geschwindigket - also nochmal mit meinem Script:



    Das ist zwar noch nicht so gut wie gedacht, aber trotzdem schneller als mit meinem USB-Stick :lol:



    Fällt einem da vielleicht noch was ein zum optimieren der Geschwindigkeit - was ich beim einrichten der SSD vielleicht falsch gemacht hab?


    [hr]


    Noch ein Test mit einer RAM-Disk:


    ..hmm.. :(


    Erneuter Versuch mit etwas dollerer Übertaktung


    Vorher:
    force_turbo=1
    arm_freq=900
    core_freq=250
    sdram_freq=450
    over_voltage=2
    temp_limit=68


    Aktuell:
    force_turbo=1
    arm_freq=900
    core_freq=300
    sdram_freq=500
    over_voltage=2
    temp_limit=68



    Und nochmal:



    Mein Windows7 Rechner kriegt über USB aber auch nur 20-21MB/s beim schreiben hin, also sind die Werte vom RaspberryPI eigentlich gut