Hallo! Meine Frage ist, ob jemand einen Mini-PC/Einplatinencomputer/Raspberry-Pi-Verschnitt kennt, der 4 verschiedene USB Hosts hat. Was ich damit genau meine ist, dass er nicht nur 4 USB Anschlüsse haben soll, die auf einem gemeinsamen Hub hängen, wie beim Raspberry Pi 3, sondern 4 einzelne Controller, um die 4-fache Geschwindigkeit zu erzielen, wenn man von mehreren Geräten gleichzeitig liest. Kosten maximal: 100 Euro Mein Anwendungsfall: Ich habe 28 Low-Speed (~200kB/s) USB Geräte (Massenspeicher) von denen ich so schnell wie möglich Daten ziehen muss. Momentan habe ich einen Raspi 3B an dem ein 28-Port USB Hub hängt. Auf jedem Gerät sind ungefähr 150MB Daten, daher bin ich bei einer Downloadzeit von etwa 4-5h. Meine Hoffnung ist, dass ich durch 4 USB Hosts jeweils 4 USB Geräte gleichzeitig lesen kann und somit auf ein Viertel der Zeit komme. Alternativlösung wäre es, 4 Geräte wie den NANOPI NEO2 LTS über einen LAN switch zu verbinden, aber vielleicht gibt es einen Mini-PC, der billiger ist, als 4xNANO + 5fach switch. LG, Flo
Wie kommst du drauf dass, die Host-Geschwindigkeit/-Bandbreite der Flaschenhals sei? 28 * (~200kB/s) = ~5,6MBps USB 2.0 => 480Mbps => ~40MBps
:
Bearbeitet durch User
Der Flaschenhals ist die Geschwindigkeit der einzelnen USB Geräte. Ein einzelnes USB Gerät kann maximal diese 200kB/s. Ist keine normaler USB Stick, sondern etwas spezielles und von diesen Dingern muss ich 28 auslesen. Unter Windows kann ich von diesen Geräten auch nur mit den 200kB/s lesen. Edit: Ok, ich habe deine Antwort falsch verstanden. Ich hab auf den Geräten jeweils 50MB Daten. Wenn ich ein einzelnes Gerät an den 28er Hub anschließe, dauert das Lesen ungefähr 4min. Wenn ich 4 Geräte anschließe dauert das Lesen 16min. Somit addieren sich die Zeiten und das lässt mich darauf schließen, dass er einfach alle nacheinander liest. Das gleiche passiert auch ohne 28er USB Hub. Sprich: je ein Gerät an einem Anschluss vom Raspberry Pi
:
Bearbeitet durch User
Sollte vielleicht deine Auslese-Software verbessert werden, damit sie nicht sequenziell sondern alle parallel ausliest...? Solange sie sequenziell ausliest und die ~200kB/s Geschwindigkeit vorgegeben ist, wird dir die zusätzliche USB-Bandbreite am Host nicht helfen.
:
Bearbeitet durch User
St. D. schrieb: > Sollte vielleicht deine Auslese-Software verbessert werden, damit sie > nicht sequenziell sondern alle parallel ausliest...? Nutzt nix, wenn die Geräte nur Low-Speed (USB 1.1) können. > Solange sie sequenziell ausliest und die ~200kB/s Geschwindigkeit > vorgegeben ist, wird dir die zusätzliche USB-Bandbreite am Host nicht > helfen. Bei 4 Hosts wäre sequenziell natürlich sinnfrei.
Auslessoftware selber ist nicht von mir. Der Punkt, an dem die USB Geräte unter Ubuntu gemountet werden wird über samba im Netzwerk freigegeben. In Windows sehe ich alle USB Geräte dann als Ordner in einem Verzeichnis. Ich kopiere einfach alle Ordner gleichzeitig auf meine Festplatte und bekomme 200kB/s. Ich hab da also nicht wirklich viel Einfluss. Wenn ich die USB Geräte mit dem 28er Hub an Windows hänge bekomme ich das gleiche Resultat. Wenn ich ein Gerät an einen 3.0 Port hänge und ein anderes an einen 2.0 Port, dann dauert es 4min. Das macht es also wirklich besser.
Reinhard S. schrieb: > St. D. schrieb: >> Sollte vielleicht deine Auslese-Software verbessert werden, damit sie >> nicht sequenziell sondern alle parallel ausliest...? > > Nutzt nix, wenn die Geräte nur Low-Speed (USB 1.1) können. Die Geräte hängen aber an einem Hub und ich nehme an dass der Hub an dem Host (mindestens) per USB 2.0 angeschlossen ist. In dem Fall ist der Hub eigentlich ein Switch und stellt fast die ganze USB 2.0 Bandbreite zur Verfügung für die downstream Ports alle zusammen. S.P. schrieb: > https://www.tomshardware.com/reviews/usb-technology,677-3.html Toller Link! Let's hope, heutzutage in 2019 sind die Hubs alle Multi-TT geworden...
:
Bearbeitet durch User
Du bringst ein paar Begriffe durcheinander. Low Speed ist 1,5 Mbit pro sec Fullspeed ist 12MBit pro sec Highspeed ist 480 MBit pro sec. Welchen Speed hat dein Stick? Es dürfte ein 12MBit Gerät sein. Wenn das so ist hilft in der Tat ein Hub mit TT auf jedem Downstream. Da du die doppelte Rate bekommst wenn du einen 3.0 und einen 2.0 Anschluss nimmst, würde ich das als Zeichen für ein Fullspeed Device interpretieren. Cypress basierende Hubs sollten helfen die gibt's aber nur mit 4Ports. 4 Hostcontroller halte ich für unmöglich das würde ev am PC gehen mit mehreren PCI Steckkarten. Thomas
S.P. schrieb: > https://www.tomshardware.com/reviews/usb-technology,677-3.html Danke, der Link schafft Klarheit! Einfach 4 7er Hubs besorgen, die diese Eigenschaft aufweisen und ich sollte alles in einem Viertel der Zeit herunterladen können.
Thomas Z. schrieb: > Du bringst ein paar Begriffe durcheinander. > Low Speed ist 1,5 Mbit pro sec > Fullspeed ist 12MBit pro sec > Highspeed ist 480 MBit pro sec. > > Welchen Speed hat dein Stick? Es dürfte ein 12MBit Gerät sein. Wenn das > so ist hilft in der Tat ein Hub mit TT auf jedem Downstream. Da du die > doppelte Rate bekommst wenn du einen 3.0 und einen 2.0 Anschluss nimmst, > würde ich das als Zeichen für ein Fullspeed Device interpretieren. > Cypress basierende Hubs sollten helfen die gibt's aber nur mit 4Ports. > 4 Hostcontroller halte ich für unmöglich das würde ev am PC gehen mit > mehreren PCI Steckkarten. > > Thomas Ich kann nicht 100%ig sagen, um welches Gerät es sich handelt, da ich es mehr oder weniger einfach zugeworfen bekommen habe. Ich bekomme nicht die doppelte Rate, sondern kann einfach nur von mehreren Geräten gleichzeitig lesen. Jedes einzelne hat trotzdem nur 200kB/s. Was die 4 Hostcontroller angeht hab ich sowas in die Richtung erwartet. Ich hab nur einen Mini-PC gefunden, bei dem das eventuell gehen könnte und der kostet schon an die 150 Euro. Der hat auch PCI Slots.
Florian M. schrieb: > Ich bekomme nicht die doppelte Rate, sondern kann einfach nur von > mehreren Geräten Doch du schreibst ja selbst dass bei Verwendung eines 3.0 Anschlusses und eines 2.0 Anschlusses die Daten auch in 4 min übertragen werden genauso wie wenn du nur von einem Anschluss kopierst. Der Roothub im PC hat immer TT. Da dein Device ein Memory Stick ist muss es mindestens 12 MBit (Fullspeed) sein. Bei Lowspeed gibt's keine MemorySticks da Bulk immer mindestens Fullspeed vorraussetzt. Wenn du also einen 7Fach Hub mit TT an allen Downstreams findest, wird deine Mimik 4 mal so schnell kopieren. (Bei insgesamt 28 Sticks) Thomas
St. D. schrieb: > Toller Link! Let's hope, heutzutage in 2019 sind die Hubs alle Multi-TT > geworden... Nein. Allerdings ist es nur dann ein Thema, wenn man Geräte mit USB2- und mit USB1-Geschwindigkeit gleichzeitig am selben Hub betreiben will. Dann werden die USB2-Geräte ausgebremst, wenn man kein Multi-TT hat. USB3 ist außen vor. Es gibt aber eine Tücke: Die meisten Hub-Chips haben nur 4 Ports, weshalb ein größerer Hub intern meist aus mehreren Hubs besteht. Ein 7-Port-Hub z.B. besteht aus zwei 4-Port-Hubs, von denen der zweite an einem der Ports des ersten angeschlossen ist. Wenn das dann nicht Multi-TT-fähig ist und am ersten Hub ein USB1-Gerät steckt, schaltet die Verbindung zum zweiten Hub auch auf USB1 runter, und die 4 Geräte, die daran hängen, müssen sich einen USB1-Link teilen.
Thomas Z. schrieb: > Florian M. schrieb: >> Ich bekomme nicht die doppelte Rate, sondern kann einfach nur von >> mehreren Geräten > > Doch du schreibst ja selbst dass bei Verwendung eines 3.0 Anschlusses > und eines 2.0 Anschlusses die Daten auch in 4 min übertragen werden > genauso wie wenn du nur von einem Anschluss kopierst. Der Roothub im PC > hat immer TT. > Da dein Device ein Memory Stick ist muss es mindestens 12 MBit > (Fullspeed) sein. > Bei Lowspeed gibt's keine MemorySticks da Bulk immer mindestens > Fullspeed vorraussetzt. > > Wenn du also einen 7Fach Hub mit TT an allen Downstreams findest, wird > deine Mimik 4 mal so schnell kopieren. (Bei insgesamt 28 Sticks) > > Thomas Ah, ich verstehe! Im PC ist wahrscheinlich auch nur ein Hub/mehrere Hubs und nicht mehrere Controller. Dieser Hub/diese Hubs sind Hubs mit TT und deswegen kann ich gleichzeitig kopieren. Und ja, dann sinds Fullspeed Geräte.
Florian M. schrieb: > Ah, ich verstehe! Im PC ist wahrscheinlich auch nur ein Hub/mehrere Hubs > und nicht mehrere Controller. Doch, da sind schon mehrere Controller. Bei mir z.B.:
1 | 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) |
2 | 00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 (rev 04) |
3 | 00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 (rev 04) |
4 | 03:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller |
5 | 08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller |
Rolf M. schrieb: > Florian M. schrieb: >> Ah, ich verstehe! Im PC ist wahrscheinlich auch nur ein Hub/mehrere Hubs >> und nicht mehrere Controller. > > Doch, da sind schon mehrere Controller. Dann kann es aber sein, dass die beiden Geräte auf verschiedenen Controllern hängen und ich nur deshalb gleichzeitig ziehen kann oder?
Florian M. schrieb: > Wenn ich ein Gerät an einen 3.0 Port hänge und ein anderes an einen 2.0 > Port, dann dauert es 4min. Typisch sind das 2 verschiedene Kontroller-ICs. Der USB3-Chip läuft dabei auch mit USB2.
noch ein Hinweis Echte 7Port Hubs kann es meiner Meinung nach nicht geben. Das hat was mit der Spec zu tun. Wie Magnus schon geschrieben hat wird das mit der Kaskatierung von 2 4Port Hubs gemacht wobei TT am kaskatierte Hub verloren geht. In der Praxis wirst du also nie die 4fache Kopiergeschwindigkeit erreichen. Optimal wird es also nur mit 4 4fach Hubs und damit 16 Sticks. Thomas
Thomas Z. schrieb: > noch ein Hinweis > Echte 7Port Hubs kann es meiner Meinung nach nicht geben. Das hat was > mit der Spec zu tun. Wie Magnus schon geschrieben hat wird das mit der > Kaskatierung von 2 4Port Hubs gemacht wobei TT am kaskatierte Hub > verloren geht. > In der Praxis wirst du also nie die 4fache Kopiergeschwindigkeit > erreichen. > Optimal wird es also nur mit 4 4fach Hubs und damit 16 Sticks. > > Thomas Ok, das ist verständlich, stimmt... Also komm ich mit einem einzigen Controller (wie beim Raspberry) nichtmal mit TT USB Hubs weiter, weil ich beim internen USB Hub (aus einem controller werden 4 Stecker) schon TT verliere...
Florian M. schrieb: > Ok, das ist verständlich, stimmt... Also komm ich mit einem einzigen > Controller (wie beim Raspberry) nichtmal mit TT USB Hubs weiter, weil > ich beim internen USB Hub (aus einem controller werden 4 Stecker) schon > TT verliere... Doch das geht schon nur halt mit max 16 Geräten der Rest muss kaskatiert werden und nur dort verlierst du TT. OK nicht ganz korrekt da du ja auch Ports für extra Hubs brauchst. Thomas
:
Bearbeitet durch User
Thomas Z. schrieb: > Florian M. schrieb: >> Ok, das ist verständlich, stimmt... Also komm ich mit einem einzigen >> Controller (wie beim Raspberry) nichtmal mit TT USB Hubs weiter, weil >> ich beim internen USB Hub (aus einem controller werden 4 Stecker) schon >> TT verliere... > > Doch das geht schon nur halt mit max 16 Geräten der Rest muss kaskatiert > werden und nur dort verlierst du TT. > OK nicht ganz korrekt da du ja auch Ports für extra Hubs brauchst. > > Thomas Ich versteh nicht ganz, warum ich beim Schritt vom internen Hub auf weitere Hubs TT nicht verliere. Der funktioniert ja genau gleich wie die anderen 4er Hubs oder? Der hat ja theoretisch auch nur einen Controller, den er auf vier Anschlüsse teilt
https://www.delock.de/produkte/G_89365/merkmale.html Hier sind vier einzelne PCIe-USB3-Hostcontroller drauf. Das sollte Dein Problem nachhaltig lösen, vor allem, wenn Du mehrere von den Dingern in einen PC steckst. https://www.reichelt.de/usb-controller-3-0-4-port-quad-channel-pcie-delock-89365-p142333.html fchk
Beispiel: Du hast 4 Ports mit Usb2 Highspeed. An Jeden Port steckst du einen 4fach Hub. Der Hub ist ebenfalls 2.0 3 der 4ports bedienen FS Geräte dort gibt's TT Der 4. Port bedient einen weiteren Hub. An diesem Hub geht TT verloren weil die Downstreams alle auf FS laufen. Der Roothub ist da nicht vergleichbar der ist fix im Hostcontroller untergebracht und nimmt deshalb eine Sonderstellung ein. Bei allen Betrachtungen hab ich den Software Overhead komplett ignoriert. Thomas
Thomas Z. schrieb: > Beispiel: > Du hast 4 Ports mit Usb2 Highspeed. > An Jeden Port steckst du einen 4fach Hub. Der Hub ist ebenfalls 2.0 > 3 der 4ports bedienen FS Geräte dort gibt's TT > Der 4. Port bedient einen weiteren Hub. > An diesem Hub geht TT verloren weil die Downstreams alle auf FS laufen. > > Der Roothub ist da nicht vergleichbar der ist fix im Hostcontroller > untergebracht und nimmt deshalb eine Sonderstellung ein. > Bei allen Betrachtungen hab ich den Software Overhead komplett > ignoriert. > > Thomas Ok, ich verstehe! Ich schätze, dass ich erst weiterkomme, wenn ich ein Gerät mit zwei Root Hubs und jeweils 4 ports habe... Wären dann 32 Geräte, wenn ich 2 x 4 4er habs nehme.
Thomas Z. schrieb: > Beispiel: > Du hast 4 Ports mit Usb2 Highspeed. > An Jeden Port steckst du einen 4fach Hub. Der Hub ist ebenfalls 2.0 > 3 der 4ports bedienen FS Geräte dort gibt's TT > Der 4. Port bedient einen weiteren Hub. > An diesem Hub geht TT verloren weil die Downstreams alle auf FS laufen. Bist Du Dir da sicher? https://www.cypress.com/documentation/application-notes-obsolete/an1071-single-versus-multiple-transaction-translator
Hier ist beschrieben, wie man herausbekommen kann, ob ein Hub Multi-TT-fähig ist: https://community.cypress.com/docs/DOC-10835 (Der Hub in meiner Raspi-Tastatur, auf der ich gerade tippe, ist übrigens Multi-TT-fähig.)
Hi, Thomas Z. schrieb: > Beispiel: > Du hast 4 Ports mit Usb2 Highspeed. > An Jeden Port steckst du einen 4fach Hub. Der Hub ist ebenfalls 2.0 > 3 der 4ports bedienen FS Geräte dort gibt's TT > Der 4. Port bedient einen weiteren Hub. > An diesem Hub geht TT verloren weil die Downstreams alle auf FS laufen. Meinst Du mit "TT" die Multi-TT-Funktion? Wenn ja -- mir leuchtet nicht ein warum die beim kaskadierten Hub verloren geht -- habe allerdings auch erst hier im Thread davon erfahren dass es das überhaupt gibt, daher interessiert es mich gerade vom Verständnis her... Der in Deinem Beispiel "letzte" Hub fasst die 4 an ihm angeschlossenen Fullspeed-Geräte doch zu einem Highspeed-Stream zusammen -- oder?
Mathias A. schrieb: > Meinst Du mit "TT" die Multi-TT-Funktion? Ich denke, er meint TT. Das steht für "Transaction Translator". Ein USB2-Hub setzt damit die USB1-Übertragung der angeschlossenen Geräte für den Uplink auf USB2 um. Wenn das verloren geht, bedeutet das, dass der Hub auch auf dem Uplink nur USB1 spricht. Aber mir ist auch nicht ganz klar, warum das bei Kaskadierung von Hubs passieren soll. > Der in Deinem Beispiel "letzte" Hub fasst die 4 an ihm angeschlossenen > Fullspeed-Geräte doch zu einem Highspeed-Stream zusammen -- oder? So wäre auch mein Verständnis. Es sei denn, der davor sitzende Hub bedient noch direkt ein USB1-Gerät und kann kein Multi-TT.
:
Bearbeitet durch User
Ich habe mich in letzter Zeit etwas eingehender mit der TT-Problematik befasst und nach meinem Verständnis stellt sich die Sache so dar: Ein TT funktioniert so, dass er vom Host den Auftrag bekommt, eine Transaktion in einer langsameren Geschwindigkeit mit einem Device abzuwickeln. Das macht der TT autark und währenddessen kann der Host mit anderen HS-Geräten (oder TTs) kommunizieren. Zu einem späteren Zeitpunkt fragt der Host beim TT das Ergebnis der Transaktion ab und holt sich ggf. die dort zwischengespeicherten Daten des langsameren Geräts. Mit "Hub" meine ich im Weiteren ausschließlich HS-Hubs, den FS-Hubs sollten heutzutage keine Rolle mehr spielen und wären im Szenario des OP absolut kontraproduktiv. Es gibt Hubs mit einem TT, der dann für die Kommunikation mit mehreren angeschlossenen FS-Geräten für jede Transaktion auf einen anderen Downstream-Port geschaltet wird. Bei solchen Hubs stehen allen angeschlossenen FS-Geräten zusammen 12 MBit/s zur Verfügung, weil der TT sich eben immer nur einem FS-Gerät widmen kann. Dann gibt es Hubs mit separaten TTs für jeden Port (Multi-TT), an denen stehen jedem FS-Gerät volle 12 MBit/s zur Verfügung, weil der Host mehrere solcher Tranaktionen gleichzeitig laufen lassen kann. In beiden Fällen läuft die Kommunikation zwischen Hub und Host und zwischen Hub und HS-Geräten weiterhin komplett in HS ab. Die HS-Seite büßt also nur so viel an Bandbreite ein, wie nötig ist, um mit dem TT zu kommunizieren und die vom TT umgesetzten Daten der LS- und FS-Geräte in HS mit dem Host auszutauschen. Alles bis hierher gesagte funktioniert auch bei kaskadierten Hubs. Selbst ein Multi-TT-Hub, der hinter einem Single-TT- hängt, sollte jedem seiner Ports volle 12 MBit/s bieten können, denn der Host kommuniziert ja mit dem zweiten Hub in HS und dafür wird im ersten Hub kein TT belegt. Oder anders gesagt: Die Kommunikation zwischen dem Host und einem FS-Gerät muss immer nur einen TT passieren, und zwar in dem Hub, an dem das FS-Gerät direkt angeschlossen ist. (Wie gesagt, wir reden hier nur von HS-Hubs.) Ob die Spec auch HS-Hubs ganz ohne TT erlaubt, die komplett auf FS runterschalten müssen, sobald ein FS-Gerät angeschlossen wird, kann ich nicht sagen, aber bewußt untergekommen ist mir ein solcher noch nicht. Das ganze Multi-TT-Gedöns hat natürlich nur dann einen Vorteil, wenn auch der USB-Stack im Betriebssystem in der Lage ist, mehrere Transaktionen mit TTs gleichzeitig offen zu halten und während der Wartezeit auch noch mit HS-Geräten zu reden, sonst findet hier eine künstliche Begrenzung der Bandbreite statt. Wie hier die Situation bei den Betriebssystemen ist, kann ich leider nicht sagen. Was die Anzahl der Ports pro Hub angeht, gibt es sehr wohl Chips, die sich zumindest ihren Deskriptoren nach als ein Hub mit 7 Ports darstellen und nicht als zwei kaskadierte 4er. Ich habe hier z.B. einige 10-Port-Hubs, in denen zwei Chips stecken, ein 7er mit Multi-TT und dahinter ein 4er mit Single-TT. Übrigens soll im Logilink UA0148 ein recht guter 7-Port-Chip mit Multi-TT stecken.
:
Bearbeitet durch User
Rolf M. schrieb: > Mathias A. schrieb: >> Meinst Du mit "TT" die Multi-TT-Funktion? > > Ich denke, er meint TT. Das steht für "Transaction Translator". Ich war/bin mir nicht sicher, weil Thomas ja geschrieben hat dass "TT verloren geht"...da der TT an sich ja immer da ist, machte das "verloren geht" für mich keinen Sinn... Aber Du und rmax habt ja inzwischen das was ich angenommen habe bestätigt, nämlich dass Multi-TT auch bei kaskadierten Hubs funktionieren sollte. R. M. schrieb: > Ein TT funktioniert so, dass er vom Host den Auftrag bekommt, eine > Transaktion in einer langsameren Geschwindigkeit mit einem Device > abzuwickeln. Das macht der TT autark und währenddessen kann der Host mit > anderen HS-Geräten (oder TTs) kommunizieren. Zu einem späteren Zeitpunkt > fragt der Host beim TT das Ergebnis der Transaktion ab und holt sich > ggf. die dort zwischengespeicherten Daten des langsameren Geräts. So kenne ich es auch. (TT an sich war mir schon ein Begriff, nur die Tatsache dass es nur einen geben kann bzw. optional für jeden Port einen, war mir so noch nicht bewusst. Wieder was dazu gelernt :) ) R. M. schrieb: > Alles bis hierher gesagte funktioniert auch bei kaskadierten Hubs. > Selbst ein Multi-TT-Hub, der hinter einem Single-TT- hängt, sollte jedem > seiner Ports volle 12 MBit/s bieten können, denn der Host kommuniziert > ja mit dem zweiten Hub in HS und dafür wird im ersten Hub kein TT > belegt. Oder anders gesagt: Die Kommunikation zwischen dem Host und > einem FS-Gerät muss immer nur einen TT passieren, und zwar in dem Hub, > an dem das FS-Gerät direkt angeschlossen ist. (Wie gesagt, wir reden > hier nur von HS-Hubs.) Danke, genau so hatte ich es angenommen, nach dem Lesen des obigen tomshardware-Links. R. M. schrieb: > Ob die Spec auch HS-Hubs ganz ohne TT erlaubt, die komplett auf FS > runterschalten müssen, sobald ein FS-Gerät angeschlossen wird, kann ich > nicht sagen, aber bewußt untergekommen ist mir ein solcher noch nicht. Zumindest lt. tomshardware nicht...: > All USB 2.0 hubs have at least one built-in transaction translator (TT)
Ich bedanke mich für alle Antworten recht herzlich und muss mir das Ganze jetzt nochmal durchdenken... Der Root Hub am Raspberry Pi 3B ist offensichtlich nicht Multi TT fähig... 50MB von einem einzelnen USB Gerät zu lesen hat 4min gedauert. Ich habe versucht, 2 Geräte ohne irgendwelche Hubs, direkt an den USB Anschlüssen des Raspberry Pi anzuschließen. Je 50MB gleichzeitig zu kopieren kopieren hat 8min gedauert. Selbst das läuft also sequentiell ab und nicht parallel. Nächster Schritt wird sein, mir mal einen Multi TT Hub zu besorgen und das einfach auszuprobieren. Wäre es eine Möglichkeit, einen 4er Multi TT Hub anzuschließen und an den dann vier 7er Multi TT Hubs? Auf welche Geschwindigkeiten/welche Gesamtzeit würde ich dann mit 28 Geräten kommen? Hat jemand so tiefes Verständnis, das abschätzen zu können? Nochmal Eckdaten dazu: Lesegeschwindigkeit ~200kb/s. 50MB entsprechen 4min. Danke!
Neues Update mit Testresultaten: Verwendet ist ein Hub, der anscheinend Multi TT fähig ist. Es handelt sich außerdem um einen USB 3.0 Hub. Auf meinem Windows Rechner hab ich ihn immer über den USB 2.0 Anschluss verbunden. Auf jedem Gerät befinden sich 50MB Daten. Mit Linux ist ein Raspberry Pi 3B mit Raspbian gemeint. Linux einzelnes Gerät: 4min Windows einzelnes Gerät: 1min 20s Linux einzelnes Gerät auf Hub: 4min Windows einzelnes Gerät auf Hub: 1min 20s Linux 2 Geräte auf verschiedenen Ports ohne Hubs: 8min Windows 2 Geräte auf verschiedenen Ports ohne Hubs: 1min 35s Linux 2 Geräte auf Hub: 8min Windows 2 Geräte auf Hub: 1min 35s Erste Frage dazu: Warum bin ich mit Windows dreimal so schnell? Verwendet wird hier Samba, also werden die Daten nie auf die SD-Karte kopiert, sondern direkt übers Netzwerk auf meinen Windows PC. Sowohl mit LAN, als auch mit WLAN erziele ich das gleiche Ergebnis. Mit den gleichen Samba Einstellungen und dem gleichen Raspberry kann ich von einem anderen USB Stick mehr als 10MB/s lesen. Zweite Frage: Warum kann ich unter Windows die Multi TT Funktion der USB Hubs nutzen, also fast gleichzeitig Daten kopieren und unter Linux nicht? Ich muss zugeben, dass mich die Resultate sehr überraschen... Zusatz: Bei den USB-Geräten handelt es sich wirklich um USB 2.0 Geräte
:
Bearbeitet durch User
Florian M. schrieb: > Zusatz: Bei den USB-Geräten handelt es sich wirklich um USB 2.0 Geräte Falls Du mit "USB 2.0" "High-Speed" meinst und das auch für die USB-Massenspeicher gilt, die Du eingangs als "Low-Speed" bezeichnet hattest, war die ganze TT-Diskussion für die Katz', denn wenn High-Speed-Geräte über einen High-Speed-Hub mit einem High-Speed-Host kommunizieren, wird gar kein TT gebraucht. Damit wir nicht weiter aneinander vorbei reden, würde ich Dich bitten, mal die Ausgabe von "lsusb -v" auf dem RasPi für einen dieser langsamen USB-Massenspeicher zu posten.
:
Bearbeitet durch User
Nochmal im Detail: 1. Auf dem RasPi ohne das fragliche Gerät "lsusb" aufrufen 2. Gerät anstecken 3. Nochmal "lsusb" aufrufen und und die USB-ID des hinzugekommenen Geräts feststellen. 4. Diese ID an das Kommando "lsusb -v -d " anhängen und die Ausgabe hier posten.
R. M. schrieb: > Damit wir nicht weiter aneinander vorbei reden, würde ich Dich bitten, > mal die Ausgabe von "lsusb -v" auf dem RasPi für einen dieser langsamen > USB-Massenspeicher zu posten. Ja, das war eindeutig mein Fehler. Ich bin von Low Speed ausgegangen, da die Datenrate exakt übereingestimmt hat. Es handelt sich offensichtlich doch um ein USB 2.0 Gerät. Hier die Ausgabe von lsusb -v: Bus 001 Device 027: ID 0483:572a STMicroelectronics Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.01 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0483 STMicroelectronics idProduct 0x572a bcdDevice 2.00 iManufacturer 1 iProduct 2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0020 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0
Florian M. schrieb: > Verwendet ist ein Hub, der anscheinend Multi TT fähig ist. Schau auf dem Rpi mal mit lsusb -v nach. Das zeigt es dir an. Da steht für den Hub dann entweder
1 | bDeviceProtocol 1 Single TT |
oder [Code bDeviceProtocol 2 TT per port [/Code] Florian M. schrieb: > Erste Frage dazu: Warum bin ich mit Windows dreimal so schnell? > Verwendet wird hier Samba, also werden die Daten nie auf die SD-Karte > kopiert, sondern direkt übers Netzwerk auf meinen Windows PC. Dann wäre die erste Frage ja, wo der Flaschenhals liegt. Bei der USB-Verbindung oder bei der Netzwerk-Übertragung? Bedenke auch, dass der Netzwerk-Adapter beim Raspi3 ebenfalls per USB angebunden ist und sich somit den Port mit deinem angeschlossenen Gerät teilen muss. Gibt's irgendwelche Auffälligkeiten bei Prozessorlast oder Speichernutzung während der Übertragung? > Zusatz: Bei den USB-Geräten handelt es sich wirklich um USB 2.0 Geräte Was genau meinst du damit? Steht auf der Packung drauf, dass es USB2-Geräte sind, oder arbeiten sie im Highspeed-Modus? Denn jedes USB1-Gerät ist auch USB2-konform.
Rolf M. schrieb: > Schau auf dem Rpi mal mit lsusb -v nach. Das zeigt es dir an. Da steht > für den Hub dann entweder >
1 | > bDeviceProtocol 1 Single TT |
2 | > |
> oder > [Code > bDeviceProtocol 2 TT per port > [/Code] Der verwendete Hub zeigt 2 TT per port an. Rolf M. schrieb: > Dann wäre die erste Frage ja, wo der Flaschenhals liegt. Bei der > USB-Verbindung oder bei der Netzwerk-Übertragung? Bedenke auch, dass der > Netzwerk-Adapter beim Raspi3 ebenfalls per USB angebunden ist und sich > somit den Port mit deinem angeschlossenen Gerät teilen muss. Gibt's > irgendwelche Auffälligkeiten bei Prozessorlast oder Speichernutzung > während der Übertragung? Ja, das hab ich mittlerweile auch herausgefunden, aber ich habe nicht gedacht, dass es um ein Vielfaches langsamer wird dadurch. Auffälligkeiten hab ich noch keine Beobachten können, außer beim Kopieren der Daten. Wenn man die Geschwindigkeit über die zeit in einem Diagramm auftragen würde, dann sieht das Ganze ein bisschen aus, wie ein Sinus ohne "negativen Anteil" (Wenn der Offset 0 wäre). Kurz werden Daten kopiert, dann wieder für eine längere Zeit nicht. Das Ganze hab ich so mit Windows und Samba herausgefunden. Sieht aber nur danach aus, als würde der Pi ein paar Daten vom Stick in den Ram kopieren und dann erst übers Netzwerk an den PC weiterleiten. Rolf M. schrieb: > Was genau meinst du damit? Steht auf der Packung drauf, dass es > USB2-Geräte sind, oder arbeiten sie im Highspeed-Modus? Denn jedes > USB1-Gerät ist auch USB2-konform. Siehe die Ausgabe von lsusb -v in meiner vorigen Antwort. Mehr kann ich leider auch nicht sagen.
:
Bearbeitet durch User
Mir fällt gerade ein, dass die Info in den Deskriptoren nur Auskunft über die Protokollversion gibt, aber nicht über die Geschwindigkeit (es kann auch USB 2.0-Geräte geben, die nur Low- oder Full-Speed können). Die ultimative Antwort auf die Geschwindigkeitsfrage gibt der Kernel beim Anstecken des Geräts: "new low-speed USB device" vs. "new full-speed USB device" vs. "new high-speed USB device" Beim lsusb-Output fällt auf, dass die Endpoints nur 64 Bytes pro Paket übertragen können, während bei USB-Sticks 512 Bytes üblich sind. Kann es sein, dass in den Geräten ein STM32 steckt, und falls ja, welcher? Und kann es weiterhin sein, dass es Looper-Pedale sind, und falls ja, welches Modell?
Mit lsusb -t solltest du für jedes Gerät sehen können, mit welcher Link-Geschwindigkeit es tatsächlich läuft. Florian M. schrieb: > Wenn man die Geschwindigkeit über die zeit in einem > Diagramm auftragen würde, dann sieht das Ganze ein bisschen aus, wie ein > Sinus ohne "negativen Anteil" (Wenn der Offset 0 wäre). Kurz werden > Daten kopiert, dann wieder für eine längere Zeit nicht. Das Ganze hab > ich so mit Windows und Samba herausgefunden. Sieht aber nur danach aus, > als würde der Pi ein paar Daten vom Stick in den Ram kopieren und dann > erst übers Netzwerk an den PC weiterleiten. Ja, sowas hab ich auch schon mal beobachtet. R. M. schrieb: > Kann es sein, dass in den Geräten ein STM32 steckt, und falls ja, > welcher? Das wäre recht wahrscheinlich bei: >> idVendor 0x0483 STMicroelectronics
R. M. schrieb: > Mir fällt gerade ein, dass die Info in den Deskriptoren nur Auskunft > über die Protokollversion gibt, aber nicht über die Geschwindigkeit (es > kann auch USB 2.0-Geräte geben, die nur Low- oder Full-Speed können). > > Die ultimative Antwort auf die Geschwindigkeitsfrage gibt der Kernel > beim Anstecken des Geräts: > > "new low-speed USB device" > > vs. > > "new full-speed USB device" > > vs. > > "new high-speed USB device"
1 | Dez 09 10:58:20 raspberrypi kernel: usb 1-1.5: new full-speed USB device number 5 using dwc_otg |
2 | Dez 09 10:58:20 raspberrypi kernel: usb 1-1.5: New USB device found, idVendor=0483, idProduct=572a, bcdDevice= 2.00 |
3 | Dez 09 10:58:20 raspberrypi kernel: usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 |
Also hattest du Recht mit Full-Speed. > Beim lsusb-Output fällt auf, dass die Endpoints nur 64 Bytes pro Paket > übertragen können, während bei USB-Sticks 512 Bytes üblich sind. Ja, genau das ist mir auch aufgefallen, als ich es mit normalen Sticks verglichen habe. > Kann es sein, dass in den Geräten ein STM32 steckt, und falls ja, > welcher? > > Und kann es weiterhin sein, dass es Looper-Pedale sind, und falls ja, > welches Modell? Ich weiß leider selber nicht, was in den Geräten genau drinnen steckt. Dass es ein ST-Mikrocontroller ist, ist offensichtlich, aber was es genau für einer ist kann ich nicht sagen. Hab zwar auch schon des öfteren STM32 programmiert, aber das Gerät stammt nicht von mir.
Rolf M. schrieb: > Mit lsusb -t solltest du für jedes Gerät sehen können, mit welcher > Link-Geschwindigkeit es tatsächlich läuft. 12M, also Full-Speed.
Florian M. schrieb: > Also hattest du Recht mit Full-Speed. ... und die TTs sind wieder im Rennen. > Ich weiß leider selber nicht, was in den Geräten genau drinnen steckt. Im Zweifel mal aufschrauben und nachschauen. ;) > Dass es ein ST-Mikrocontroller ist, ist offensichtlich, aber was es > genau für einer ist kann ich nicht sagen. Hab zwar auch schon des > öfteren STM32 programmiert, aber das Gerät stammt nicht von mir. Aber was für ein Gerät es ist, hast Du uns noch nicht verraten. Ich hab mal nach der USB-ID gesucht und bin auf das hier gestoßen: https://github.com/reinerh/loopertrx Da ist von einem Harley Benton Mini Looper die Rede, der hat aber laut Hersteller gar keinen USB-Anschluss: https://www.thomann.de/de/harley_benton_mini_looper.htm Außerdem scheint da ein proprietäres Protokoll verwendet zu werden und eben kein USB Mass Storage.
R. M. schrieb: > Florian M. schrieb: > >> Also hattest du Recht mit Full-Speed. > > ... und die TTs sind wieder im Rennen. Ja, stimmt. >> Ich weiß leider selber nicht, was in den Geräten genau drinnen steckt. > > Im Zweifel mal aufschrauben und nachschauen. ;) Ist leider eingegossen... >> Dass es ein ST-Mikrocontroller ist, ist offensichtlich, aber was es >> genau für einer ist kann ich nicht sagen. Hab zwar auch schon des >> öfteren STM32 programmiert, aber das Gerät stammt nicht von mir. > > Aber was für ein Gerät es ist, hast Du uns noch nicht verraten. > > Ich hab mal nach der USB-ID gesucht und bin auf das hier gestoßen: > https://github.com/reinerh/loopertrx > > Da ist von einem Harley Benton Mini Looper die Rede, der hat aber laut > Hersteller gar keinen USB-Anschluss: > https://www.thomann.de/de/harley_benton_mini_looper.htm > > Außerdem scheint da ein proprietäres Protokoll verwendet zu werden und > eben kein USB Mass Storage. Es ist ein OBU, das GPS-Daten und ähnliches aufzeichnet.
Rolf M. schrieb: > Dann wäre die erste Frage ja, wo der Flaschenhals liegt. Bei der > USB-Verbindung oder bei der Netzwerk-Übertragung? Bedenke auch, dass der > Netzwerk-Adapter beim Raspi3 ebenfalls per USB angebunden ist und sich > somit den Port mit deinem angeschlossenen Gerät teilen muss. Gibt's > irgendwelche Auffälligkeiten bei Prozessorlast oder Speichernutzung > während der Übertragung? Beim Kopieren vom USB Gerät auf die SD-Karte bekomme ich auch 200kB/s. 50MB in 4min. Also das Netzwerk scheint nicht der Flaschenhals zu sein.
OK, dass ein einzelnes dieser Geräte nicht schneller kann, wird wohl an deren Hard- oder Firmware liegen und nicht zu ändern sein. Warum aber mehrere davon an einem Multi-TT-Hub unter Linux nicht insgesamt schneller sind, ist schon eine weitere Untersuchung wert. Und hier könnte durchaus das Netzwerk wieder eine Rolle spielen, z.B. falls der Samba-Server die Zugriffe so serialisiert, dass die Parallelität von Multi-TT gar nicht zum Zuge kommen kann. Deshalb würde ich Dir schon empfehlen, das erstmal nur lokal auf dem RasPi zu testen. Ich schlage folgende Testreihe vor: Du steckst eines Deiner Geräte an den Multi-TT-Hub und lässt "dd if=/dev/sdX of=/dev/null" durchlaufen. Dann ziehst Du den Hub vom RasPi ab (damit vom ersten Durchlauf nichts mehr im Cache ist), steckst ein zweites Gerät dran, stöpselst den Hub wieder an und wiederholst den Test mit zwei parallel laufenden dd-Prozessen. Das Ganze wiederholst Du dann nochmal mit einem dritten Gerät. Alternativ kannst Du statt dd auch ddrescue oder dd_rescue verwenden, die zeigen die Transfergeschwindigkeit fortlaufend an und nicht erst am Ende.
Wer sagt denn, dass es am Linux liegt und nicht an der schraddligen RasPi-Hardware? Der Pi ist vor allen eines: billig. Mehr nicht. Boote mal Deinen PC mit einem Linux (notfalls ein Knoppix von CD) und probiere nochmal. fchk
fchk schrieb: > Wer sagt denn, dass es am Linux liegt und nicht an der schraddligen > RasPi-Hardware? Der Pi ist vor allen eines: billig. Mehr nicht. > > Boote mal Deinen PC mit einem Linux (notfalls ein Knoppix von CD) und > probiere nochmal. Unter Ubuntu 18.04.3 LTS hat das Lesen am gleich PC 2min 30s gedauert. Damit keiner suchen muss: Windows: 1min 20s Raspberry Pi mit Raspbian: 4min Wie sich Ubuntu und Raspbian in dieser Hinsicht unterscheiden kann ich leider nicht sagen, aber es liegt anscheinend an Hard- und Software, da es mit Ubuntu fast doppelt so lang dauert, wie mit Windows und das am selben PC.
R. M. schrieb: > Ich schlage folgende Testreihe vor: > > Du steckst eines Deiner Geräte an den Multi-TT-Hub und lässt "dd > if=/dev/sdX of=/dev/null" durchlaufen. Dann ziehst Du den Hub vom RasPi > ab (damit vom ersten Durchlauf nichts mehr im Cache ist), steckst ein > zweites Gerät dran, stöpselst den Hub wieder an und wiederholst den Test > mit zwei parallel laufenden dd-Prozessen. Das Ganze wiederholst Du dann > nochmal mit einem dritten Gerät. > Ich hab das jetzt probiert und ich glaube du hast den Wurm gefunden. Ich hab jeden Test nur 3min laufen lassen, ich denke das reicht, um eine grobe Einschätzung der Datenrate zu bekommen. 1 Gerät: 41275392 bytes (41 MB, 39 MiB) copied, 182,135 s, 227 kB/s 2 Geräte in 2 Terminals: 42192896 bytes (42 MB, 40 MiB) copied, 186,836 s, 226 kB/s 42192896 bytes (42 MB, 40 MiB) copied, 186,795 s, 226 kB/s 3 Geräte in 3 Terminals: 41406464 bytes (41 MB, 39 MiB) copied, 182,732 s, 227 kB/s 41406464 bytes (41 MB, 39 MiB) copied, 182,776 s, 227 kB/s 41406464 bytes (41 MB, 39 MiB) copied, 182,789 s, 227 kB/s Sieht danach aus, als könnte ich so parallel kopieren. Jetzt stellt sich die Frage, wie man Samba das beibringen kann... Edit: Mit Filezilla und einer FTP Verbindung sieht man grafisch ganz schön, dass alle Dateien sequentiell abgearbeitet werden. Edit2: Ich korrigiere mich, mit FTP sind zwei gleichzeitig kopiert worden und die dritte Datei danach...
:
Bearbeitet durch User
Man kann mehrere FTP Verbindungen zulassen in den Filezilla Einstellungen.
Florian M. schrieb: > Windows: 1min 20s > Raspberry Pi mit Raspbian: 4min Florian M. schrieb: > Sieht danach aus, als könnte ich so parallel kopieren. Jetzt stellt sich > die Frage, wie man Samba das beibringen kann... Der Windows Explorer startet beim Kopieren mehrerer Dateien mehre Kopier-Threads gleichzeitig. Samba must du das nicht beibringen der kann das. Der Rechner der das Kopieren auslöst muss die Kopiertasks parallel starten.
Lukas schrieb: > Der Windows Explorer startet beim Kopieren mehrerer Dateien mehre > Kopier-Threads gleichzeitig. was denn die Geschwindigkeit mächtig einbrechen lässt wenn ein Leselaufwerk dann ständig steppen muss von Track zu Track, meist keine gute Idee.
Deswegen kann man z.B. mit robocopy genau das beeinflussen, mit dem Parameter /MT https://www.windows-faq.de/2013/10/21/robocopy-mit-parameter-mt-beschleunigen/
Im Notfall könntest du vielleicht auf deinem Raspi erstmal alle Dateien lesen, in ein zip-File packen und das dann weiter schicken. Florian M. schrieb: > Edit: Mit Filezilla und einer FTP Verbindung sieht man grafisch ganz > schön, dass alle Dateien sequentiell abgearbeitet werden. > > Edit2: Ich korrigiere mich, mit FTP sind zwei gleichzeitig kopiert > worden und die dritte Datei danach... Vielleicht begrenzt dein Filezilla die Zahl der offenen FTP-Verbindungen einfach auf 2. Das kann man wohl konfigurieren. Bei Samba könnt ich mir auch vorstellen, dass die Dateien nacheinander übertragen werden.
Iltis schrieb: > Man kann mehrere FTP Verbindungen zulassen in den Filezilla > Einstellungen. Ja, das stimmt! Aber leider nur bis maximal 10.
Lukas schrieb: > Florian M. schrieb: >> Windows: 1min 20s >> Raspberry Pi mit Raspbian: 4min > > Florian M. schrieb: >> Sieht danach aus, als könnte ich so parallel kopieren. Jetzt stellt sich >> die Frage, wie man Samba das beibringen kann... > > Der Windows Explorer startet beim Kopieren mehrerer Dateien mehre > Kopier-Threads gleichzeitig. > > Samba must du das nicht beibringen der kann das. > > Der Rechner der das Kopieren auslöst muss die Kopiertasks parallel > starten. Danke für die Info, das hat mich um Welten weitergebracht! > Deswegen kann man z.B. mit robocopy genau das beeinflussen, mit dem > Parameter /MT > https://www.windows-faq.de/2013/10/21/robocopy-mit-parameter-mt-beschleunigen/ Genau so hab ich es unter Windows gemacht und das funktioniert perfekt! Ich komm jetzt mit einem 7er Hub auf ein Siebtel der Zeit!!!
Rolf M. schrieb: > Im Notfall könntest du vielleicht auf deinem Raspi erstmal alle Dateien > lesen, in ein zip-File packen und das dann weiter schicken. Ja, das hab ich in der Tat auch so gemacht, allerdings soll ich zu jeder Zeit von ausgewählten Geräten kopieren können und zippen schränkt mich da leider ein bisschen ein. Bzw. brauch ich dann eine Art User-Interface und das ist so nicht geplant. > Florian M. schrieb: >> Edit: Mit Filezilla und einer FTP Verbindung sieht man grafisch ganz >> schön, dass alle Dateien sequentiell abgearbeitet werden. >> >> Edit2: Ich korrigiere mich, mit FTP sind zwei gleichzeitig kopiert >> worden und die dritte Datei danach... > > Vielleicht begrenzt dein Filezilla die Zahl der offenen FTP-Verbindungen > einfach auf 2. Das kann man wohl konfigurieren. > Bei Samba könnt ich mir auch vorstellen, dass die Dateien nacheinander > übertragen werden. Ja, genau so ist es. Die Einstellung war standardmäßig auf 2!
So, ich habe meine Lösung gefunden und möchte mit euch teilen, auf was ich genau gekommen bin! Resultat: Gesamte Zeit, um von 28 USB Full-Speed Geräten je 100MB Daten zu kopieren von rund 4h auf ungefähr 10min reduziert. Anfangsproblem: Mit Windows wurden die Daten von jedem einzelnen Gerät sequentiell vom Samba-Server geholt. Ein einzelnes Gerät kann ungefähr 200kB/s. 100MB/(0,2MB/s)=500s pro Gerät. 28*500s = ~4h. Auslöser: Das Problem liegt gar nicht hauptsächlich, wie von vielen hier geglaubt (mich eingeschlossen), an der Hardware und an Single-TT/Multi-TT. Das Problem war, dass Windows die Daten sequentiell anfordert, wenn man im File-Explorer einfach alle Ordner kopiert. So wird USB Stick, nach USB Stick, nach USB Stick, usw., gelesen. Lösung: Mehrere Threads... Das ist mit Robocopy unter Windows ganz einfach möglich, wie von Lukas beschrieben(Ist sogar vorinstalliert). Ich verwende folgenden Befehl, der mir alle Daten von allen USB Sticks in einen Ordner "D:/tester" kopiert:
1 | robocopy \\192.168.0.1\obu\ D:/tester *.* /E /MT:28 |
MT:28 bedeutet, dass 28 Threads gestartet werden, um die Daten zu kopieren. So kann ich wirklich von 28 Geräten fast gleichzeitig lesen. Das habe ich so mehrfach getestet und mit 7 Geräten komme ich auf eine Gesamtzeit von 526s. Ohne Multi-Threading würde ich auf ungefähr 3500s kommen. Es war also wirklich ein eigentlich einfaches Softwareproblem. Ich habe das Ganze außerdem mit einem Multi-TT und einem Single-TT Hub versucht. Diese sind jeweils so unter Raspbian angezeigt worden. Also tatsächlich Multi-TT und Single-TT Hubs. Ich habe jeweils 7 Geräte angeschlossen und die Hubs einzeln getestet. Gesamtzeiten: Multi-TT: 526s Single-TT: 561s Man kann erkennen, dass es zwar einen Unterschied gibt, aber er nur minimal ist. Ich werde trotzdem Multi-TT Hubs verwenden, da sie doch schneller sind und ich froh über jede Sekunde bin, die ich einsparen kann. Finaler Aufbau: Ich habe weiters auch festgestellt, dass der interne 4er Hub vom Raspbi 3B auch ein Multi-TT Hub ist, somit verwende ich jetzt vier 7 Port USB Hubs, die Multi-TT-fähig sind. Jeweils ein Hub pro Anschluss.
1 | USB 2.0-Hub LOGILINK UA0148 |
Der Hub ist zwar schlecht bewertet, da das Gehäuse und der mechanische Aufbau schlecht sind, aber er erfüllt rein elektronisch alle Anforderungen. Ich möchte mich nochmal bei allen bedanken, die mir so tatkräftig weitergeholfen haben! Ich hoffe ich konnte das verständlich vermitteln.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.