Détection USB 2

[speap]

Bonjour,

Alors voilà, je suis l’heureux possesseur d’un Acer Aspire Revo R3600-1FYZ, livré avec Vista que je me suis empressé de dégager pour laisser place à Debian. Ce petit PC dispose de plusieurs sorties USB 2, et j’ai également un disque dur externe (dont le boitier gère l’USB 2) branché en USB.

Seulement voilà, lorsque j’utilise rsync, le débit de transfert de mes fichiers atteint une moyenne de 1,94MB/s, ce qui est, si je ne m’abuse, le débit de l’USB 1.1

Y a-t-il quelque chose à activer dans un fichier de configuration, ou bien des drivers spécifiques à installer afin que le taux de transfert atteigne un débit d’USB 2?

Je ne connais pas trop les commandes à taper dans ce genre de cas, mais voici tout de même le résultat d’un lsusb:

Bus 002 Device 003: ID 152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp.
Bus 002 Device 002: ID 04b4:6830 Cypress Semiconductor Corp. CY7C68300A EZ-USB AT2 USB 2.0 to ATA/ATAPI
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Puis le retour d’un /bin/dmesg | grep usb

[    2.672724] usbcore: registered new interface driver usbfs
[    2.672864] usbcore: registered new interface driver hub
[    2.673019] usbcore: registered new device driver usb
[    2.735215] usb usb1: configuration #1 chosen from 1 choice
[    2.837866] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[    2.837954] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.838945] usb usb1: Product: OHCI Host Controller
[    2.839020] usb usb1: Manufacturer: Linux 2.6.26-2-686 ohci_hcd
[    2.839097] usb usb1: SerialNumber: 0000:00:04.0
[    2.850282] usb usb2: configuration #1 chosen from 1 choice
[    2.958479] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[    2.958479] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.958479] usb usb2: Product: EHCI Host Controller
[    2.958479] usb usb2: Manufacturer: Linux 2.6.26-2-686 ehci_hcd
[    2.958479] usb usb2: SerialNumber: 0000:00:04.1
[  394.722867] usb 2-4: new high speed USB device using ehci_hcd and address 2
[  394.856244] usb 2-4: configuration #1 chosen from 1 choice
[  394.858848] usb 2-4: New USB device found, idVendor=04b4, idProduct=6830
[  394.858848] usb 2-4: New USB device strings: Mfr=56, Product=78, SerialNumber=100
[  394.858848] usb 2-4: Product: USB2.0 Storage Device
[  394.858848] usb 2-4: Manufacturer: Cypress Semiconductor
[  394.858848] usb 2-4: SerialNumber: DEF107679C83
[  395.227056] usb-storage: device found at 2
[  395.227066] usb-storage: waiting for device to settle before scanning
[  395.229903] usbcore: registered new interface driver usb-storage
[  400.228337] usb-storage: device scan complete
[  408.714137] usb 2-2: new high speed USB device using ehci_hcd and address 3
[  408.864115] usb 2-2: configuration #1 chosen from 1 choice
[  408.866115] usb-storage: device found at 3
[  408.866115] usb-storage: waiting for device to settle before scanning
[  408.866604] usb 2-2: New USB device found, idVendor=152d, idProduct=2329
[  408.867652] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[  408.867733] usb 2-2: Product: USB to ATA/ATAPI Bridge
[  408.867816] usb 2-2: Manufacturer: JMicron
[  408.867892] usb 2-2: SerialNumber: 1390314907FF
[  414.016048] usb-storage: device scan complete

Merci

PS: Je débute en Linux, alors soyez sympa, ne m’en voulez pas si je suis un peu à côté de la plaque

[PascalHambourg]

Seulement voilà, lorsque j’utilise rsync, le débit de transfert de mes fichiers atteint une moyenne de 1,94MB/s, ce qui est, si je ne m’abuse, le débit de l’USB 1.1

D’abord, ne pas confondre la version de spécification USB (1.1, 2.0) et la vitesse de transfert (low speed, full speed, high speed). Le full speed (vitesse de signalisation 12 Mbit/s) existe aussi en USB 2.0, d’où l’appellation “USB 2.0 full speed” qu’on trouve parfois.

Avec le débit de signalisation (qui est la “fréquence” des bits sur le câble et non le débit utile effectif, faut-il le rappeler) full speed il est impossible d’atteindre un débit utile de 1,94 Mo/s (12 Mbit/s -> 1,5 Mo/s sans compter la charge protocolaire).

Dans les logs on voit bien des occurences d’USB 2.0 et d’EHCI, le pilote pour les contrôleurs hôtes USB 2.0, et les deux périphériques de stockage de masse JMicron et Cypress sont bien en high speed (vitesse de signalisation 480 Mbit/s).

[speap]

D’abord, ne pas confondre la version de spécification USB (1.1, 2.0) et la vitesse de transfert (low speed, full speed, high speed). Le full speed (vitesse de signalisation 12 Mbit/s) existe aussi en USB 2.0, d’où l’appellation “USB 2.0 full speed” qu’on trouve parfois.

Merci pour cette information.

Avec le débit de signalisation (qui est la “fréquence” des bits sur le câble et non le débit utile effectif, faut-il le rappeler) full speed il est impossible d’atteindre un débit utile de 1,94 Mo/s (12 Mbit/s -> 1,5 Mo/s sans compter la charge protocolaire).

Je ne comprends pas tout, toujours est-il que je ne parlais pas de 1,94Mo/s mais bien 1,94MB/s, je pense qu’il y a eu confusion. En tout cas je n’invente rien, voici un copier-coller lors d’une exécution de rsync:

video_vacances_2009.avi
   100863558 100%    1.96MB/s    0:00:51 (xfer#229, to-check=29/265)

Dans les logs on voit bien des occurences d’USB 2.0 et d’EHCI, le pilote pour les contrôleurs hôtes USB 2.0, et les deux périphériques de stockage de masse JMicron et Cypress sont bien en high speed (vitesse de signalisation 480 Mbit/s).

D’accord, donc les ports sont bien reconnus en tant que USB 2 high speed. Pourtant le transfert est beaucoup plus lent que lorsque je boot sur Windows sur la même machine, avec les mêmes disques durs branchés sur les mêmes ports USB…

Quelqu’un d’autre aurait-il une idée?

[P_tit_g]

Je ne comprends pas tout, toujours est-il que je ne parlais pas de 1,94Mo/s mais bien 1,94MB/s, je pense qu’il y a eu confusion.

Attention, en anglais :
B = bytes (octets)
b = bits

[speap]

[quote=“P’tit g”]
Attention, en anglais :
B = bytes (octets)
b = bits[/quote]

Ah très bien, merci pour cette précision.
Dans ce cas, rsync me donne 1,96 MB/s (soit 1,96 Mo/s si je comprends bien), alors pourquoi serait-il impossible d’atteindre un débit utile de 1,96 Mo/s? Je veux dire, est-ce qu’il s’agit d’un bug du côté de rsync qui retourne une fausse valeur?

J’ai parfois des pics à 6MB/s comme ici:

Saison 5 - vo/S05E08.avi 367862124 100% 6.24MB/s 0:00:56 (xfer#7, to-check=11/23)

[P_tit_g]

Relis bien ce qui a été dit :

Avec le débit […] full speed il est impossible d’atteindre un débit utile de 1,94 Mo/s (12 Mbit/s -> 1,5 Mo/s […]).

Dans les logs […], et les deux périphériques de stockage de masse JMicron et Cypress sont bien en high speed (vitesse de signalisation 480 Mbit/s).

[PascalHambourg]

Pourtant le transfert est beaucoup plus lent que lorsque je boot sur Windows sur la même machine, avec les mêmes disques durs branchés sur les mêmes ports USB…

Tu utilises aussi rsync sous Windows ?
Tu as essayé sous Debian avec autre chose que rsync (cp, dd…) ?
Au fait, transfert d’où vers où ? disque USB vers disque interne, disque interne vers USB, disque USB vers disque USB ?

[speap]

Autant pour moi, j’ai fais l’amalgame entre full speed et high speed.

Bon, pour reprendre, en full speed il n’est pas possible de dépasser 1,5 Mo/s, mais bon à la limite ça peu importante vu que je suis en high speed.

Si j’ai bien compris comment ça marche, avec le high speed qui a une vitesse de signalisation de 480 Mbit/s, le débit théorique devrait être de 60 Mo/s, non? Alors est-ce que vous auriez une idée du pourquoi j’ai un débit moyen de 2 Mo/s (avec un maximum de 6 Mo/s)?

Je ne me suis pas amusé à chronométrer, mais sous windows le transfert est 3 à 4 fois plus rapide avec le même matériel, une idée du pourquoi??

[speap]

Tu utilises aussi rsync sous Windows ?

Non en effet, j’utilise le transfert simple de fichier par couper/coller classique.

Tu as essayé sous Debian avec autre chose que rsync (cp, dd…) ?

Oui, mais malheureusement je n’arrive pas à avoir de barre de progression sous Debian avec cp ou mv (je suis en mode console), c’est pourquoi j’utilise rsync. Mais d’après le temps que ça met, je dirais que c’est relativement la même chose en temps.

Au fait, transfert d’où vers où ? disque USB vers disque interne, disque interne vers USB, disque USB vers disque USB ?

En effet, il serait bien de préciser: le transfert se fait d’un disque dur USB vers un disque dur interne.

[PascalHambourg]

je n’arrive pas à avoir de barre de progression sous Debian avec cp ou mv (je suis en mode console)

‘time’ est ton ami. Inséré avant une commande, il mesure son temps d’exécution. Il n’y a plus qu’à diviser la taille du fichier par ce temps. Ou alors fais la copie avec dd.

le transfert se fait d’un disque dur USB vers un disque dur interne.

Le disque interne va assez vite ? J’ai vu des disques IDE se traîner lamentablement à quelques Mo/s en mode PIO si le DMA est désactivé, contre plusieurs dizaines en UDMA. A vérifier en root avec

hdparm /dev/hdX hdparm -t /dev/hdX
Tant que tu y es tu peux aussi mesurer le débit en lecture des disques USB avec hdparm -t.
En écriture, tu peux utilise dd pour créer un gros fichier plein de zéros sur un disque USB sans faire intervenir le disque interne :

avec le high speed qui a une vitesse de signalisation de 480 Mbit/s, le débit théorique devrait être de 60 Mo/s, non?

Non. Le débit théorique est inférieur à 60 Mo/s car tous les bits ne transportent pas des données utiles (et en plus il n’y a pas des bits tous le temps).

480 Mbit/s, ça ne veut pas dire qu’en une seconde il passe 480 millions de bits, mais que l’envoi d’un bit prend 1/480 millionnième de seconde. Le même principe est valable pour d’autres bus/protocoles comme PCI, IDE, SATA, SCSI, ethernet…

EDIT : Ce ne serait pas le même problème que dans le fil Pourquoi une telle latence? ?
Je remarque que comme dans ce fil tes deux exemples de copie prennent à peu près le même temps, environ 50 secondes, pour des fichiers de tailles très différente, 100 Mo et 360 Mo.

[speap]

‘time’ est ton ami. Inséré avant une commande, il mesure son temps d’exécution. Il n’y a plus qu’à diviser la taille du fichier par ce temps.

Pour un fichier de 733825024 octets, voici le résultat de time cp disque_externe/fichier disque_interne/ :

real    3m42.945s
user    0m0.160s
sys     0m6.368s

Soit environ 3,2 Mo/s

Résultat de hdparm /dev/sda (disque interne):

/dev/sda: IO_support = 0 (default) readonly = 0 (off) readahead = 256 (on) geometry = 60801/255/63, sectors = 976773168, start = 0

Résultat de hdparm -t /dev/sda (disque interne):

Timing buffered disk reads:  236 MB in  3.02 seconds =  78.02 MB/sec

Résultat de hdparm -t /dev/sdb (disque externe):

Timing buffered disk reads:   54 MB in  3.05 seconds =  17.71 MB/sec

Enfin, le résultat d’un dd directement sur le disque externe:

dd if=/dev/zero of=fic bs=4096 count=25000 25000+0 enregistrements lus 25000+0 enregistrements écrits 102400000 bytes (102 MB) copied, 6,56137 s, 15,6 MB/s

J’ai vu des disques IDE se traîner lamentablement à quelques Mo/s en mode PIO si le DMA est désactivé, contre plusieurs dizaines en UDMA.

Y a-t-il moyen d’activer le DMA si celui-ci est désactivé?

En ce qui concerne le fil “Pourquoi une telle latence??”, je suis en mode asynchrone par défaut lors du montage. Passer en synchrone ne m’intéresse pas parce que mes supports de stockage externes sont débranchés à chaud de la machine, sans démonter le volume avant. Passer en mode synchrone représente trop de risque de pertes de données d’après ce que j’ai cru comprendre.

[Num_s]

[quote=“speap”]Passer en mode synchrone représente trop de risque de pertes de données d’après ce que j’ai cru comprendre.[/quote]Nop justement… c’est l’inverse… synchrone, ça veut dire “je modifie un fichier, il est directement modifié sur le support”… asynchrone, c’est plutôt “ben… j’écrirais ça quand ce sera vraiment utile…”… genre un peu feignasse quoi… …

[PascalHambourg]

1. Tu peux oublier cette histoire de DMA : ça ne concerne que les disques IDE/ATA branchés sur un contrôleur géré par un pilote IDE/ATA “traditionnel” et donc nommé hdX ; or ton disque interne s’appelle sda donc c’est soit un SCSI, soit un SATA, soit un IDE géré par un pilote PATA. Le débit en lecture séquentielle du disque interne mesuré par hdparm est de près de 80 Mo/s, ce qui est très correct. A noter que cette mesure est faite au début du disque, là ou le débit séquentiel est maximum ; lorsqu’on progresse vers l’intérieur du disque, le débit séquentiel baisse progressivement, c’est mécanique (rayon de piste qui diminue) jusqu’à un facteur 1,5 à 2 à la fin du disque.

2. Le débit en lecture séquentielle du disque USB mesuré par hdparm est ~17 Mo/s, et le débit en écriture avec dd ~15 Mo/s (en supposant que l’écriture est immédiate (sync) et non retardée (async) sinon le débit réel en écriture peut être plus faible). Ce sont a priori des valeurs honnêtes pour un disque USB 2.0 en high speed (autour de 20 Mo/s).

3. Au sujet de la dernière remarque de ma précédente réponse concernant l’autre fil, j’avais lu de travers ce que tu avais écrit : j’avais compris transfert du disque interne vers le disque USB (donc écriture sur le disque USB) au lieu du disque USB vers le disque internet (donc lecture du disque USB). Le mode synchrone/asynchrone ne concerne a priori que l’écriture.

4. Maintenant qu’on sait de quel débit le disque USB est capable, tu peux faire des tests supplémentaires pour essayer d’identifier le goulot d’étranglement qui cause un débit minable lors de la copie de fichiers. J’élimine a priori la fragmentation du système de fichiers du disque USB car elle affecterait aussi la copie sous Windows.

• lecture d’un (gros de préférence, dont la copie est lente) fichier du disque USB :

dd bs=4096 if=<fichier> of=/dev/null
time cp <fichier> /dev/null # autre méthode pour lire un fichier

• écriture d’un fichier de 100 Mio de zéros sur le disque interne :

• lecture de tout le disque USB (ATTENTION LONG) car la mesure de débit d’hdparm porte seulement sur les premiers méga-octets du disque :

Note : j’utilise une taille de bloc de 4 Kio avec dd parce que d’après mon expérience une valeur inférieure peut provoquer une baisse de performance. En plus c’est une valeur courante pour la taille de bloc des systèmes de fichiers (et la taille d’une page mémoire dans l’architecture i386).

5. Quels sont les types de systèmes de fichiers des disques interne et USB : FAT, NTFS, ext2/3… ?

[speap]

Salut,

alors voici les résultats des différents tests:

time cp /mnt/media/gros_fichier /dev/null appliqué sur le disque USB

real    4m28.442s
user    0m0.292s
sys     0m4.812s

commande appliquée à un fichier de 2078 Mo soit un débit de 7,75 Mo/s

dd if=/dev/zero of=/home/cedric/fichier bs=4096 count=25000 appliqué sur le disque interne

25000+0 enregistrements lus
25000+0 enregistrements écrits
102400000 bytes (102 MB) copied, 0,997071 s, 103 MB/s

dd bs=4096 if=/dev/sdb of=/dev/null appliqué sur le disque USB

81150682+0 enregistrements lus
81150682+0 enregistrements écrits
332393193472 bytes (332 GB) copied, 17544,1 s, 18,9 MB/s

soit approximativement 5h, en effet, c’est long!

Mon disque dur interne est en ext3 et le disque USB est quant à lui en NTFS.

Je ne sais pas trop comment interpréter ces résultats, à part que la copie USB->disque interne a été plus rapide sur la totalité du disque que appliqué à un seul gros fichier (plus du double en débit)…

[PascalHambourg]

1. Le résultat de l’écriture d’un fichier sur le disque interne est meilleur que le test en lecture de hdparm, je soupçonne que le cache entre en jeu mais on va dire qu’il n’y a pas de goulot d’étranglement à ce niveau. En plus 1 seconde, c’est peu précis, il aurait fallu augmenter la valeur de count.

2. Oups, 5 heures c’est très long, désolé. Je n’avais pas fait le calcul, mais comme la capacité des disques augmente plus vite que leur débit séquentiel (à vitesse de rotation et nombre de plateaux constants, on peut très approximativement considérer que le débit évolue comme la racine carrée de la capacité), c’est de plus en plus long.

En tout cas cela montre que le débit en lecture est à peu près constant sur tout le disque (c’est l’interface USB qui limite), donc pas de souci de ce côté là non plus.

3. Reste un suspect : le système de fichiers NTFS. La différence entre la lecture du disque et la lecture d’un fichier, c’est le système de fichiers. Le pilote NTFS de Linux (ntfs-3g ?) n’est peut-être pas aussi efficace que celui de Windows, ce qui ne serait pas scandaleux. Il y a peut-être aussi des options au montage qui pourraient améliorer les performances.

[speap]

Reste un suspect : le système de fichiers NTFS

Oui, j’utilise ntfs-3g. Malheureusement je suis obliger de garder ce disque dur en NTFS, parce que c’est un disque dur qui voyage entre chez moi (Linux) et le boulot (windows) et qui doit donc être accessible sous les 2 OS.

Donc tant pis, je me contenterai de ces faibles performances…

Merci PascalHambourg pour toutes ces informations! :smt002

[PascalHambourg]

Désolé de ne pas pouvoir t’aider mais l’optimisation de ntfs-3g est au-delà de ma compétence. Au moins on a vérifié que ce n’était pas un problème d’USB. Peut-être faudrait-il refaire un fil avec un nouveau sujet, car il y a peut-être ici des connaisseurs de ntfs-3g que ton titre n’avait pas attirés.