Bonjour,
Un sujet, un peu vieux, mais qui peut t’intéresser : https://www.debian-fr.org/detection-usb-2-t22457.html
alors effectivement le post est interressant mais le soucis c’est qu’il n’y a pas de solution à la fin 
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… 
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 
Avant de parler de solution, il faudrait poser un diagnostic. Et pour ce faire, le post sus-cité propose un certain nombre de tests.
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ù!!!
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.
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
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.
[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
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
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…)
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 
11 fois plus rapide.
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!
@+
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.
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 …
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.
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 
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
sync ne prend aucun argument d’où le message, elle entraine un vide des caches sur les périphériques.
ok et bien le vide se fait dans un laps de temps identique au temps de démontage d’une clé sous ext3/4 sans sync, c’est à dire 10-15 secondes.