Extreme lenteur des transferts usb sur clés

Support Debian
#1

Bonjour tout le monde,

Je finis par poster mon soucis car je ne sais vraiment pas comment y remedier malgré des lectures et des lectures de topic différents.
Je suis sous noyau 3.2.0-0.bpo.3-amd64 et depuis une lointaine mise à jour (je ne me rappelle plus du tout quand) je rencontre un énorme soucis de lenteur de transfert de données via les prises usb. Pour copier 1.8 Go il m’a fallut pres de 2 heures ! :013

Que j’utilise la commande cp en ligne de commande ou l’interface graphique, même résultat. Rsync pareil.

La premiere chose que je me suis dite c’est que mes clés doivent être detectée en usb 1 au lieu du 2. Je précise que mes clés fonctionnent parfaitement sous d’autres postes en Windows ou Mac, je n’ai pas encore d’autre poste en Linux.

Je fais donc un lsusb

Bus 004 Device 004: ID 04f2:b021 Chicony Electronics Co., Ltd ViewSonic 1.3M, USB2.0 Webcam Bus 004 Device 003: ID 050d:0815 Belkin Components Nostromo n52 HID SpeedPad Mouse Wheel Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 007: [color=#800000]ID 1b1c:0a10 [/color] Bus 003 Device 006: ID 046d:c531 Logitech, Inc. Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 046d:c30e Logitech, Inc. UltraX Keyboard (Y-BL49) Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

puis un lsusb -vd 1b1c:0a10

Bus 003 Device 007: ID 1b1c:0a10 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1b1c idProduct 0x0a10 bcdDevice 11.00 iManufacturer 1 Corsair iProduct 2 UFD iSerial 3 A600000000000004 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus 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 (Zip) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 255 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 255 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered)

Je suis donc bien en usb 2.00 si je ne m’abuse non ??
Alors pourquoi est ce que mes transferts sont si longs ?? Dois je faire une commande spécifique lors de mon cp ?

Merci beaucoup de m’aider, je vous souhaite une tres bonne journée :slightly_smiling:

#2

Salut,

En faisant la mmême manœuvre que toi j’obtiens :

Ne serais tu pas branché sur une prise usb1 ?

#3

Bonjour,

Un sujet, un peu vieux, mais qui peut t’intéresser : https://www.debian-fr.org/detection-usb-2-t22457.html

#4

alors effectivement le post est interressant mais le soucis c’est qu’il n’y a pas de solution à la fin :cry:
je fais quand même les manips proposées et donc :

le /bin/dmseg | grep usb donne :

[ 2.845663] usb 4-1.5: Product: ViewSonic 1.3M, USB2.0 Webcam [ 2.845665] usb 4-1.5: Manufacturer: Chicony Electronics Co., Ltd. [ 2.845667] usb 4-1.5: SerialNumber: SN0001 [ 5.307214] input: ViewSonic 1.3M, USB2.0 Webcam as /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.0/input/input10 [ 5.307275] usbcore: registered new interface driver uvcvideo [ 969.296628] usb 4-1.6: new high-speed USB device number 5 using ehci_hcd [ 969.393958] usb 4-1.6: New USB device found, idVendor=1b1c, idProduct=0a10 [ 969.393963] usb 4-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 969.393965] usb 4-1.6: Product: UFD [ 969.393967] usb 4-1.6: Manufacturer: Corsair [ 969.393970] usb 4-1.6: SerialNumber: A600000000000004 [ 969.435858] usbcore: registered new interface driver uas [ 969.448879] scsi6 : usb-storage 4-1.6:1.0 [ 969.448973] usbcore: registered new interface driver usb-storage

j’ai branché ma clé usb Corsair sur un port usb natif de la carte mère à l’arrière, donc en usb 2.0 de base.

Les transferts se font d’un disque dur sata interne à une clé usb Corsair 4GB

J’ai tenté un rsync d’un fichier de 480 Mo, voici ce que cela donne :

[code]root@room:/home/smokaz# rsync -v /home/smokaz/Téléchargements/2013-02-09-wheezy-raspbian.zip /media/usb0
2013-02-09-wheezy-raspbian.zip

sent 493648173 bytes received 31 bytes 338927.71 bytes/sec
total size is 493587826 speedup is 1.00
root@room:/home/smokaz#
[/code]

la commande cp est aussi lente… :013 :013

Je précise que comme pour speap, cette machine a un dual boot et que les soucis de transferts usb sont inexistants sous W7, tous le matériel usb est en 2.0.

De toutes façons je n’ai pas l’impression que ce soit un soucis de detection usb 2.0 car le lsusb est bien clair à ce sujet.

J’avoue ne rien y comprendre :119

#5

Avant de parler de solution, il faudrait poser un diagnostic. Et pour ce faire, le post sus-cité propose un certain nombre de tests.

#6

Je suis dans le même cas que smokaz, par contre, moi, c’est depuis 1semaine et demi, date de mon abandon d’ubuntu pour débian.
Je transfère de simple photo, hier j’ai transféré 15photos de 3Mo et cela m’a mis 15minutes.
Je me suis dit, ta clé est morte, je teste sur windows un fichier de 700Mo, 3minutes.
Je me dis, c’est le format de la clé, je reformate en fat32, idem.
Hier soir, je teste avec mon disque dur externe alimenté électriquement, 3 heures pour faire un simple rsync différentiel.

Avant mon passage à débian (quand j’étais donc sur ubuntu), je n’avais pas ce soucis.

Pour répondre à ggoodluck47, j’ai un autre pc qui tourne sous ubuntu, pas de soucis avec cette clé, et quand je la teste, lsusb -vd + réf, me renvoie “bInterfaceProtocol 0 Full speed (or root) hub” donc, le soucis doit être quelque part, mais où!!!

#7

Avant de parler de solution, il faudrait poser un diagnostic. Et pour ce faire, le post sus-cité propose un certain nombre de tests.[/quote]
il est évident que je ne me suis pas précipité sur la fin voir si il y a une solution, la preuve en est les manips que j’ai fait viennent du post en question.

Seulement la plupart des posts parlent de soucis de disque dur et de vitesse de rotation, puisque le soucis de copie était de disque externe a interne, hors moi mon soucis vient d’une clef usb. Du fait les tests de copie de disque dur à disque dur externe (chose que je n’ai pas) ne me concerne point je crois.

En revanche, la vitesse de copie je ne l’avais pas donnée, chose résolue maintenant.

Donc le diagnostic, pour moi, est le suivant : soucis de transfert usb sur clé usb détectée en 2.00, avec ou sans souris sans fils, soucis entierement rencontré sur ma debian squeeze.

J’ai fait le tour de ce que je pouvais faire personnellement pour résoudre ce soucis, c’est pourquoi je me permets de solliciter votre aide.

Merci.

#8

Quelle carte mère as tu leknoppix ?

Pour ma part j’ai une asus P8P67-M PRO avec comme disposition usb :
Built-in Controller :
2 x USB 3.0 port(s) (2 at back panel, blue)
Built-in Controller :
14 x USB 2.0 port(s) (6 at back panel, black+red, 8 at mid-board)

ma clé est branchée sur un port usb 2.0 arrière.

et voici ce que me donne lshsw :

*-usb description: USB Controller physical id: 0 bus info: pci@0000:08:00.0 version: 00 width: 64 bits clock: 33MHz capabilities: msi msix pm pciexpress bus_master cap_list configuration: driver=xhci_hcd latency=0 resources: irq:19 memory:fa100000-fa107fff *-usb:1 description: USB Controller product: Cougar Point USB Enhanced Host Controller #1 vendor: Intel Corporation physical id: 1d bus info: pci@0000:00:1d.0 version: 05 width: 32 bits clock: 33MHz capabilities: pm debug ehci bus_master cap_list configuration: driver=ehci_hcd latency=0 resources: irq:23 memory:fa405000-fa4053ff

#9

J’avais proposé dans la discussion signalée par P’tit g des tests avec hdparm et dd dont je ne vois pas les résultats ici.

#10

[quote=“smokaz”]Quelle carte mère as tu leknoppix ?

Pour ma part j’ai une asus P8P67-M PRO avec comme disposition usb :
Built-in Controller :
2 x USB 3.0 port(s) (2 at back panel, blue)
Built-in Controller :
14 x USB 2.0 port(s) (6 at back panel, black+red, 8 at mid-board)

ma clé est branchée sur un port usb 2.0 arrière.

et voici ce que me donne lshsw :

*-usb description: USB Controller physical id: 0 bus info: pci@0000:08:00.0 version: 00 width: 64 bits clock: 33MHz capabilities: msi msix pm pciexpress bus_master cap_list configuration: driver=xhci_hcd latency=0 resources: irq:19 memory:fa100000-fa107fff *-usb:1 description: USB Controller product: Cougar Point USB Enhanced Host Controller #1 vendor: Intel Corporation physical id: 1d bus info: pci@0000:00:1d.0 version: 05 width: 32 bits clock: 33MHz capabilities: pm debug ehci bus_master cap_list configuration: driver=ehci_hcd latency=0 resources: irq:23 memory:fa405000-fa4053ff; [/quote]
Vu que mon portable date de 2008, je ne m’en souviens plus, mais voici sa fiche caractéristique: ldlc.com/fiche/PB00083712.html

Je vais regarder le lien plus haut pour essayer de faire un diagnostic. Bizarre, avec ubuntu, les usb fonctionnaient très bien.

leknoppix

#11

Solution trouvée !!!

C’était le format de formatage des clé qui ne convenait pas à debian. En effet le format état en fat32, je les ai formatées en ext3, le temps est tout à fait correct ! Certes je ne pourrais pas les lire sous w7, mais je suis exclusivement sous Debian depuis environ deux ans donc ce n’est pas un soucis.

J’ai donc fait un

la clé a été formatée entièrement en ext3, puis j’ai fait mon cp et resync de fichier de plus de 100 Mo, et niquel la copie se fait en temps réel. En revanche la clé met plus de temps à se démonter.

Chose bizarre quand je fais fdisk -l je reçois cette information :

Disk /dev/sdd: 4026 MB, 4026531840 bytes
124 heads, 62 sectors/track, 1022 cylinders
Units = cylinders of 7688 * 512 = 3936256 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
[color=#BF0000]
Disk /dev/sdd doesn't contain a valid partition table[/color]

pourquoi ma table de partition de ma clé n’est elle pas valide ? J’ai mal fait mon formatage ? Dans ce cas, pourquoi j’arrive à écrire et supprimer des données sur ma clé ?

Merci de votre aide et c’est en lisant ta remarque sur le ntfs3g et en mangeant à tête reposée, que j’ai pensé au format des clés, PascalHambourg

#12

Oui, tu as formatté la clef au lieu de formatter une partition. Il est normal qu’il gueule sur la non validité de la table de partition, il n’y en a plus… Mais je suis étonné de la différence de vitesse e,tre FAT32 et ext3, je n’ai jamais vu ça.

Réessaye de la formatter en FAT32 et regarde si c’est mieux (c’est ce que je ferais, la clef a peut être un souci…)

#13

Alors test fait fran.b

transfert en vfat

sent 78782900 bytes received 31 bytes 454080.29 bytes/sec total size is 78773166 speedup is 1.00

transfert en ext3

sent 78782900 bytes received 31 bytes 52521954.00 bytes/sec total size is 78773166 speedup is 1.00

Il est clair que le transfert est vraiment plus rapide en ext3 :open_mouth:

#14

11 fois plus rapide.

#15

Bonjour,

Cela fait 2 semaines que je rencontre un problem de copie très lente, PC vers dd usb (55 ko/s). Mais me concernant c’était un hub usb 1.1 externe qui limitait les taux de transfert(solution trouvé y a moins d’1 heure, le dd tourne à fond maintenant). Malgré tout avant de trouver la solution a mon problem je suis passé par ce forum, et j’ai lu ce message. L’année dernière j’ai eu un problem similaire de copie lente mais avec une moyenne de 500 ko/s…A force de chercher j’ai fini par trouver une réponse ci-dessous.
Sources :
http://forums.debian.net/viewtopic.php?f=10&t=80778
http://askubuntu.com/questions/122113/copy-to-usb-memory-stick-really-slow
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/177235

La procédure résumée en anglais:
unmount drive, remove drive, and run sudo modprobe ehci_hcd in the Terminal. Insert drive and agian sudo modprobe ehci_hcd

Je me rends bien compte que le problème ici est différent, puisque la clef une fois formatée en ext3 fonctionne rapidement…Tu devrais essayer sait-on jamais!
@+

#16

Regarde si dans un cas le montage est en synchrone et dans l’autre cas le montage n’est pas synchrone et la copie se fait en cache (d’où une rapidité apparente). En clair, fais la copie et juste après démonte la clef. J’ai vraiment du mal à croire à cette différence de vitesse, je n’ai jamais constaté de différence flagrante entre ext3 et fat32 et je ne vois pas de raisons objectives à son existence.

#17

A mon avis c’est le cache qui fait la différence. Ton problème n’est certainement pas résolu.
Fais un sync après la copie pour voir …

#18

Qui plus est, un débit de 52 Mo/s sur de l’USB 2.0 est complètement irréaliste. S’il s’agit d’une écriture vers disque USB, cela correspond plutôt à la vitesse de lecture depuis le disque interne, les données étant mises en cache et pas réellement écrite sur le disque USB comme le soupçonne François.

#19

fran.b Dans les deux cas lorsque j’ai fait la copie via cp ou rsync, j’ai immédiatement démonté la clé après et comme je l’ai précisé la clé mettait plus de temps à se démonter dans le cas de l’ext3 que dans celui de la fat32. Cependant le temps était tout à fait raisonable, genre 30 secondes au lieu de 5 secondes.
Comment puis je voir si les clés sont montées en synchrone ou en assynchrone ? Je vais aussi me documenter la dessus pour comprendre la nuance.

guyr34 Je ne connais pas la commande sync, je vais donc me documenter dessus pour voir à quoi cela sert.

PascalHambourg Je n’ai jamais parlé de disque dur usb dans ce post, je travaille sur deux clés usb différentes, je format les deux en ext3 et les deux en vfat32 pour faire les tests et j’arrive aux même conclusions dans les deux cas.

Je suis comme vous, j’aimerais comprendre pourquoi cela ne fonctionne pas bien en fat32 et j’apprécie énormément que vous vous penchez sur ce soucis :slightly_smiling:

#20

Bonjour à tous

Après des recherches sur le net et surtout la pauvreté du man sync chez moi j’ai donc effectué cette commande

root@room:/home/smokaz# sync /media/usb0/ sync: ignore tous les arguments

j’ai compris l’esprit de la commande, en gros elle synchronise les données en mémoire tampon du kernel avec le support dans lequel elles sont copiées. Mais je ne vois pas ce que peut m’indiquer le retour de cette commande dans ce cas.

guyr34 peux tu m’éclairer sur le sujet s’il te plait ?

Merci à vous