Mageia Forum

Ich habe an meinem PC 6 USB-Anschlüsse und stelle immer wieder fest, dass die Übertragungsgeschwindigkeiten von Port zu Port differieren, schob das aber bisher immer auf unterschiedliche USB-Sticks. Aber es könnte ja durchaus sein, dass einer oder mehrere der Anschlüsse nur USB1 sind (leider habe ich das Handbuch des MoBo nicht mehr). Wie kann ich feststellen, welcher Anschluss welche Norm erfüllt?

wobo hat geschrieben:(leider habe ich das Handbuch des MoBo nicht mehr). Wie kann ich feststellen, welcher Anschluss welche Norm erfüllt?

Du lädst dir, nach Herausfinden der exakten Typenbezeichnung des Mobo, das Handbuch von der Internet-Seite des Herstellers herunter.

Davon abgesehen hängen immer mehrere USB-Ports an einem Bus. Ist an nur einem davon ein USB1-Gerät (Scanner, Maus, Tastatur) angeschlossen, werden AFAIR alle Ports an dem Bus im USB1-Modus betrieben. Erst USB3 ist da wohl cleverer.

Du kannst natürlich auch die /var/log/messages nach dem Booten auswerten, ob USB-Ports nur mit dem ohci-Treiber benutzt werden. Aber wie du dann Bus-Nummer des Treibers und Porthardware zusammen bekommst, scheint mir offen.

Einen ersten Hinweis gibt lspci:

Code: Alles auswählen

00:12.0 USB Controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:12.2 USB Controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:13.0 USB Controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.2 USB Controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI Controller


Mein Nobo hat 3 externe (und im Zweifel einen internen für das UMTS-Modem) USB-Ports an 2 Bussen. Beide unterstützen USB2 (EHCI) und USB1 (OHCI)

man-draker hat geschrieben:Du lädst dir, nach Herausfinden der exakten Typenbezeichnung des Mobo, das Handbuch von der Internet-Seite des Herstellers herunter.

Tja, dazu müsste ich die Kiste aufmachen, was leider irgendwo dermaßen hakt, dass ich schon an eine Rettungsschwere der Feuerwehr dachte.

Davon abgesehen hängen immer mehrere USB-Ports an einem Bus. Ist an nur einem davon ein USB1-Gerät (Scanner, Maus, Tastatur) angeschlossen, werden AFAIR alle Ports an dem Bus im USB1-Modus betrieben.

Ah, ja, daran hatte ich nicht gedacht. Muss ich mir mal dmesg genauer ansehen...

Ah, lspci scheint da was Gutes zu wissen:

Code: Alles auswählen

# lspci|grep USB
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05)
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05)

Das müsste dann bedeuten, dass beide Busse USB2 sind. Wenn ich mal annehme, dass am einen Bus die vorderen Anschlüsse und am anderen die hinteren Anschlüsse hängen, dann habe ich schlechte Karten: die Tastatur ist hinten angeschlossen, die Maus vorne. Werde mal die Maus auch hinten anschließen...

wobo hat geschrieben:

man-draker hat geschrieben:Du lädst dir, nach Herausfinden der exakten Typenbezeichnung des Mobo, das Handbuch von der Internet-Seite des Herstellers herunter.

Tja, dazu müsste ich die Kiste aufmachen, was leider irgendwo dermaßen hakt, dass ich schon an eine Rettungsschwere der Feuerwehr dachte.

Dann lass doch mal dmidecode auf deinen PC los:

Code: Alles auswählen

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
        Manufacturer: ASUSTeK Computer INC.
        Product Name: M4A87TD/USB3
        Version: Rev 1.xx
        Serial Number: 109926560003105
        Asset Tag: To Be Filled By O.E.M.
        Features:
                Board is a hosting board
                Board is replaceable
        Location In Chassis: To Be Filled By O.E.M.
        Chassis Handle: 0x0003
        Type: Motherboard
        Contained Object Handles: 0


Sorry, ist mir jetzt erst eingefallen.

Hallo!
Was mir allerdings noch nicht untergekommen ist USB2-Mäuse und -Tastaturen.
Wäre ja sinnvoll, wenn soetwas das ganze systemherunterzieht.
Gruß
J.

gar so aufwändig ist es nicht die nötigen Informationen zusammen zubringen, dafür sollten lsusb und lspci völlig ausreichen.

Das sagt mir lspci bezgl. USB

Code: Alles auswählen

[root@kre007 alfred]# lspci -v | grep USB
00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) (prog-if 10 [OHCI])
00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) (prog-if 20 [EHCI])


und aus lsusb erhalte ich folgenden informationen(Auszug, Darstellung verkürzt)

Code: Alles auswählen

Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0        64
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0001 1.1 root hub
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.39.4-5.1-desktop ohci_hcd
  iProduct                2 OHCI Host Controller
  iSerial                 1 0000:00:0b.0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval             255
Hub Descriptor:
  bLength              11
  bDescriptorType      41
  nNbrPorts             8
  wHubCharacteristic 0x0012
    No power switching (usb 1.0)
    No overcurrent protection
  bPwrOn2PwrGood        1 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0x00 0x00
  PortPwrCtrlMask    0xff 0xff
 Hub Port Status:
   Port 1: 0000.0303 lowspeed power enable connect
   Port 2: 0000.0100 power
   Port 3: 0000.0100 power
   Port 4: 0000.0103 power enable connect
   Port 5: 0000.0100 power
   Port 6: 0000.0100 power
   Port 7: 0000.0100 power
   Port 8: 0000.0100 power
Device Status:     0x0003
  Self Powered
  Remote Wakeup Enabled

Bus 001 Device 004: ID 046d:c06c Logitech, Inc.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x046d Logitech, Inc.
  idProduct          0xc06c
  bcdDevice           63.00
  iManufacturer           1 Logitech
  iProduct                2 USB Optical Mouse
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      52
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              10
Device Status:     0x0000
  (Bus Powered)


man beachte im letzten codeblock die erste Zeile und die Zeilen iProduct und iSerial. Und nach den USB-Informationen zu Hub folgen ja die Devices, die daran hängen.

Ja, die Outputs sind ja schön, nur sagen die mir nichts in der Art "die 4 USB-Anschlüsse vorne hängen am ersten Controller, die 2 hinteren und die internen Anschlüsse am zweiten" oder sowas praktisch Verwertbares.
Über lspci (siehe früher im Thread) habe ich ja schon herausgefunden, dass beide Controller USB2 sind. Allerdings sagt mir dmesg auch, dass Maus und Keyboard beide "lowspeed" sind und an unterschiedlichen Controllern hängen - wobei beide an der USB-Reihe hinten angeschlossen sind.
Mit anderen Worten: die Anschlüsse sind nicht so geordnet, dass z.B. alle internen und hinteren Anschlüsse an Controller 1 und alle vorderen Anshclüsse an Controller 2 angeschlossen wären.

Mit dmidecode habe ich den MoBo-Typ herausgefunden (eine "Eigenmarke" von Acer), leider habe ich bei Acer noch keinen Link auf der Website gefunden, wo man sowas herunterladen kann, im Downloadbereich gibt es nur Windows-Treiber für meinen PC. Da werde ich wohl mal den Service anschreiben müssen. Das Handbuch zum gesamten PC habe ich gefunden, da steht aber nur, wieviele Anschlüsse es gibt und wo die liegen - die technischen Details werden da ausgelassen, vermutlich um den neuen Besitzer des PCs nicht zu verwirren.

Aber es gibt ja auch noch das Acer-Userforum...

wobo hat geschrieben:Mit anderen Worten: die Anschlüsse sind nicht so geordnet, dass z.B. alle internen und hinteren Anschlüsse an Controller 1 und alle vorderen Anshclüsse an Controller 2 angeschlossen wären.

Das ist im Prinzip auch ganz pfiffig. Der Hersteller muss ja damit rechnen, dass die Anwender externe 2,5" Festplatten anschließen, die beim Anlaufen mehr, als die vorgesehenen 500mA, aus dem Anschluss saugen. Gegen die daraus resultierende Durchbrenngefahr des Controllers helfen die meist mitgelieferten Doppelstecker nur, wenn sie auch an zwei getrennten Stromlieferanten hängen.

Es ist so, dass ein 1.1-Gerät immer an den OHCI-Controller angeschlossen wird, egal welchen Port du nutzt. Ein 2.0-Gerät immer an den EHCI-Controller unabhängig vom Port. Man-drakers Aussage bzgl. der reduzierten Geschwindigkeit kann also eigentlich theoretisch nur auftreten, wenn im PC ausschließlich EHCI-Contoller vorhanden sind. Aber ich denke dass ein 1.1-Gerät nicht ausreicht um auf dem gesamten Bus die Geschwindigkeit herabzusetzen. Zumindest habe ich davon noch nichts gelesen oder gehört.

man-draker hat geschrieben:

wobo hat geschrieben:Mit anderen Worten: die Anschlüsse sind nicht so geordnet, dass z.B. alle internen und hinteren Anschlüsse an Controller 1 und alle vorderen Anshclüsse an Controller 2 angeschlossen wären.

Das ist im Prinzip auch ganz pfiffig. Der Hersteller muss ja damit rechnen, dass die Anwender externe 2,5" Festplatten anschließen, die beim Anlaufen mehr, als die vorgesehenen 500mA, aus dem Anschluss saugen. Gegen die daraus resultierende Durchbrenngefahr des Controllers helfen die meist mitgelieferten Doppelstecker nur, wenn sie auch an zwei getrennten Stromlieferanten hängen.

Ja, ok, das leuchtet ein. Nur hilft es mir nicht weiter

Mir bleibt also nur die Ochsentour:
A. Aufstehen, Frühstücken
1. Maus abziehen
2. Keyboard auf PS/2-Anschluss umstecken
3. USB-Stick an ersten Anschluss - ISO übertragen (Zeit messen mit time) - USB-Stick leer fegen. Diesen Schritt für alle vorderen Anschlüsse wiederholen.
4. Schritt 3 mit angeschlossener Maus und Keyboard wiederholen -
B. Abendessen, Schlafen.

Die Frage ist, ob sich dieser Aufwand lohnt. Was wäre denn eine "normale" Transferrate (bitte keine Max-Werte, die Specs sind mir bekannt) bei ISOs für einen mittelmäßigen Stick (z.B. 4GB Cruiser oder 8GB LaCie)?

Anscheinend gibt es bei der Übertragung von Daten noch andere Kriterien als die Art des Anschlusses und das Modell des USB-Sticks.
Ich habe heute mal einunddieselbe Datei (8GB) zweimal hintereinander auf den gleichen USB-Stick kopiert (dazwischen natürlich den Stick leergefegt und formatiert). Dummerweise habe ich beide Male den gleichen USB-Anschluss benutzt. Beim ersten Mal bekam ich etwas über 4MB/s, beim zweiten Mal nur 1,9MB/s! Bei den Transfers liefen auf dem PC keine ressourcenhungrigen Apps, nur der Desktop.

Da frage ich mich schon, woher bei gleich bleibenden Bedingungen über die gesamte Zeit die Transfergeschwindigkeit auf einmal halbiert werden kann.

wobo hat geschrieben:Dummerweise habe ich beide Male den gleichen USB-Anschluss benutzt. Beim ersten Mal bekam ich etwas über 4MB/s, beim zweiten Mal nur 1,9MB/s!

Das ist lustig.
Ich habe nach meinem letzten Post einen USB-Stick zwei mal mit einer 10GB-Datei betankt und zwischendurch diese nur gelöscht. Ich habe ihn mal vorne am Gehaäuse, mal hinten am Board angeschlossen. In beiden Fällen: 3,2MB/s.

wobo hat geschrieben:Bei den Transfers liefen auf dem PC keine ressourcenhungrigen Apps, nur der Desktop.

Und was ist mit Hintergrundjobs(Cron?), irgendwelche periodische msec-checks?

alf hat geschrieben:

wobo hat geschrieben:Bei den Transfers liefen auf dem PC keine ressourcenhungrigen Apps, nur der Desktop.

Und was ist mit Hintergrundjobs(Cron?), irgendwelche periodische msec-checks?

Habe nur ein 'tail' des syslog in einem konsole-Fenster mitlaufen lassen, um eventuelle Meldungen mitzubekommen. Da waren nur zwei der üblichen kurzen Checks, die aber auch während des "schnellen" Versuchs kamen. .

Zumindest habe ich die Erfahrung gemacht, dass wenn solche Checks laufen, das System spürbar träger reagiert, obwohl diese Jobs weder besonders viel Speicher beanspruchen noch die CPU-Last merklich erhöhen. Wieso auch immer.

alf hat geschrieben:Zumindest habe ich die Erfahrung gemacht, dass wenn solche Checks laufen, das System spürbar träger reagiert, obwohl diese Jobs weder besonders viel Speicher beanspruchen noch die CPU-Last merklich erhöhen. Wieso auch immer.

Fuck mal in iotop dann weißt du warum. Der liest die ganze Zeit mit vollast von der HD...

wobo hat geschrieben:Anscheinend gibt es bei der Übertragung von Daten noch andere Kriterien als die Art des Anschlusses und das Modell des USB-Sticks.
Ich habe heute mal einunddieselbe Datei (8GB) zweimal hintereinander auf den gleichen USB-Stick kopiert (dazwischen natürlich den Stick leergefegt und formatiert). Dummerweise habe ich beide Male den gleichen USB-Anschluss benutzt. Beim ersten Mal bekam ich etwas über 4MB/s, beim zweiten Mal nur 1,9MB/s! Bei den Transfers liefen auf dem PC keine ressourcenhungrigen Apps, nur der Desktop.

Jup, ist mir auch schon oft aufgefallen. Je länger der USB-Stik am Gerät hängt desto langsamer wird er. Da hilft es auch nichts ihn wider aus und ein zu stecken. (Ich nehme an das die einfach langsammer werden, wenn sie warm werden.) Allerdings ist es höchst unterschiedlich wie schnell das geht. Ich bin der Meinung es gibt Sticks, die manchmal einfach schlechte Laune haben.

wanne hat geschrieben:

wobo hat geschrieben:Anscheinend gibt es bei der Übertragung von Daten noch andere Kriterien als die Art des Anschlusses und das Modell des USB-Sticks.
Ich habe heute mal einunddieselbe Datei (8GB) zweimal hintereinander auf den gleichen USB-Stick kopiert (dazwischen natürlich den Stick leergefegt und formatiert). Dummerweise habe ich beide Male den gleichen USB-Anschluss benutzt. Beim ersten Mal bekam ich etwas über 4MB/s, beim zweiten Mal nur 1,9MB/s! Bei den Transfers liefen auf dem PC keine ressourcenhungrigen Apps, nur der Desktop.

Jup, ist mir auch schon oft aufgefallen. Je länger der USB-Stik am Gerät hängt desto langsamer wird er. Da hilft es auch nichts ihn wider aus und ein zu stecken. (Ich nehme an das die einfach langsammer werden, wenn sie warm werden.) Allerdings ist es höchst unterschiedlich wie schnell das geht. Ich bin der Meinung es gibt Sticks, die manchmal einfach schlechte Laune haben.

Ich habe das auch gerade mal getestet. Ein 3,6 GB DVD-iso auf einen 8GB-Stick kopiert(SanDisk Cruzer, ca. 4 Jahre alt). Ich habe dieses ISO hintereinander auf allen 4 USB-Ports kopiert und dabei immer einen Durchsatz von 7,3 MB/s erreicht. Der Stick wurde dabei recht warm, aber ein Abfall der Geschwindigkeit resultierte daraus nicht. Bei einer zweiten Testreihe habe ich parallel dazu im Internet gesurft, dabei war ein geringer Abfall der Geschwindigkeit zu beobachten: min. 5,8 MB/s, max. 6,5MB/s. Wie ich bereits schrieb, habe ich allerdings sowohl einen EHCI als auch einen OHCI-Kontroller auf dem Board und die USB 1.1-Geräte(Maus) werde immer an den 1.1-Kontroller gebunden, so dass hier keine Störeinflüsse durch USB 1.1 auftreten können, die möglicherweise für die Reduzierung der Geschwindigkeit verantwortlich sein könnten.

Von den SanDisk 8 habe ich hier auch ein paar herumliegen. Mittlerweile habe ich den Test komplett durchgezogen. Einziges aktives USB1.1-Gerät: Tastatur. Während der Tests hatte ich nicht einmal ein GUI laufen noch liefen andere Checks im Hintergrund (Runlevel 1).
An allen externen Anschlüssen (vorn und hinten) erhalte ich Werte, die während der Übertragung zwischen 1,2 und 5, 6 schwanken und dann im Gesamten eben auch irgendwo dazwischen liegen - was mich nun in keiner Weise schlauer macht oder gar dem gesuchten Ergebnis näher bringt. Außerdem ist das Ergebnis insgesamt doch recht armselig, was die Geschwindigkeit angeht.

Hab jetzt mal die gleiche ISO wie als und den gleichen USB-Stick genommen, also eine 3.6GB ISO und einen 8er Sandisk Cruizer. Ergebnis: 3,1MB/s. Ich hatte während der ganzen Zeit auf einem zweiten tty htop laufen und konnte feststellen, dass der Prozess während der ganzen Zeit den Status "D" (Disk sleep) - ist das normal?

wobo hat geschrieben:Ich hatte während der ganzen Zeit auf einem zweiten tty htop laufen und konnte feststellen, dass der Prozess während der ganzen Zeit den Status "D" (Disk sleep) - ist das normal?

Das scheint normal zu sein, den Status D hat der Prozess bei mir auch.
Zwischenzeitlich habe ich aber etwas anderes Interessantes herausgefunden. Unter sonst gleichen Bedingungen scheint die Angabe des block size von entscheidender Bedeutung für die Transferrate. bs=2048 --> 7,3 MB/s, bs=1024 --> 2,5 MB/s. Das erklärt aber immer noch nicht die unterschiedlichen Ergebnisse bei dir.

wobo hat geschrieben:konnte feststellen, dass der Prozess während der ganzen Zeit den Status "D" (Disk sleep) - ist das normal?

Ich fürchte ja. Das Laden der Datei-Teile von der Platte geht vergleichsweise schnell. Die Übergabe an den Ausgabetreiber geradezu rasend.
Im Vergleich dazu unendlich dauert das Schreiben der Daten auf den Stick.
Jedenfalls:
- Alten Inhalt des Blocks löschen
- Neuen schreiben

Eventuell:
- Zwei Blöcke lesen
- Löschen
- Neu schreiben

Diese ganze Zeit wartet der Prozess ununterbrechbar auf die Antwort der Hardware.

Die Schreibrate ist ähnlich ärmlich, wie bei meinem Stick.
Der einzige Grund, der mit einfällt, ist ein Abweichen von Blockgröße des Schreibprogramms und des Sticks, so das zum Schreiben eines Blocks Daten, mehrere Blöcke des Sticks neu geschrieben werden müssen.

Verändert sich das Bild, wenn du mit dd, Schreiben direkt auf das Device und Blockgrößen von 512 bis 4096 Byte arbeitest?
(Ich prüfe das gerade mal.)

Mal durchgespielt:

Code: Alles auswählen

[root@localhost Downloads]# dd if=mandriva-linux-free-2010.2-x86_64.iso of=/dev/sdc bs=512
4055891968 Bytes (4,1 GB) kopiert, 1423,06 s, 2,9 MB/s
[root@localhost Downloads]# dd if=mandriva-linux-free-2010.2-x86_64.iso of=/dev/sdc bs=1024
4055891968 Bytes (4,1 GB) kopiert, 814,847 s, 5,0 MB/s
[root@localhost Downloads]# dd if=mandriva-linux-free-2010.2-x86_64.iso of=/dev/sdc bs=2048
4055891968 Bytes (4,1 GB) kopiert, 799,725 s, 5,1 MB/s
[root@localhost Downloads]# dd if=mandriva-linux-free-2010.2-x86_64.iso of=/dev/sdc bs=4096
4055891968 Bytes (4,1 GB) kopiert, 352,088 s, 11,5 MB/s
[root@localhost Downloads]# dd if=mandriva-linux-free-2010.2-x86_64.iso of=/dev/sdc bs=8192
4055891968 Bytes (4,1 GB) kopiert, 360,685 s, 11,2 MB/s

Scheint so, als ob der Stick physisch mit 4K-Blöcken arbeitet.

sehr schön, damit bestätigst du meine Beobachtung. Scheint also eine gesicherte Erkenntnis dass die Blockgrösse für die Transferrate entscheidend ist.

Fast alle Flash-Speicher arbeiten intern mit 4K-Blöcken ...

Zur Blockgröße gibt es bei mandrivauser.de irgendwo auch schon mal etwas.
Versucht es mal mit bs=64k.
Wobei ich mittlerweile dd_rescue benutze, da sieht man wenigstens, dass etwas passiert

Gruß
Magnus