j'ai mis à jour ma distrib (Mandrake), et j'ai donc un noyau 2.6.3 au lieu
du 2.4.2x.
j'ai des problèmes avec un disque dur sur USB 2 :
avant (noyan 2.4.2x) : un peu lent mais çà marchait pas mal
maintenant ( noyau 2.6.3) :
très lent en copie de fichiers ( 1 à 2 Mo/s ) le processeur tourne à 100%
test avec hdparm -t indique par contre un débit de 20 Mo/s, le processeur
tourne à 100%
je n'ai pas rien vu de particulier avec dmesg ou la syslog concernant l'usb
( mais quoi chercher ?)
j'ajoute que la carte USB 2 a une puce VIA :
résultat de usbview :
EHCI Host Controller
Manufacturer: Linux 2.6.3-8mdk ehci_hcd
Serial Number: 0000:00:09.2
Speed: 480Mb/s (high)
Number of Ports: 4
Bandwidth allocated: 0 / 800 (0%)
Total number of interrupt requests: 0
Total number of isochronous requests: 0
USB Version: 2.00
Device Class: 09(hub )
Device Subclass: 00
Device Protocol: 01
Maximum Default Endpoint Size: 8
Number of Configurations: 1
Config Number: 1
Number of Interfaces: 1
Attributes: 40
MaxPower Needed: 0mA
Interface Number: 0
Name: hub
Alternate Number: 0
Class: 09(hub )
Sub Class: 00
Protocol: 00
Number of Endpoints: 1
Endpoint Address: 81
Direction: in
Attribute: 3
Type: Int.
Max Packet Size: 2
Interval: 256ms
et voilà pour le disque :
USB2.0 Storage Device
Manufacturer: Cypress Semiconductor
Serial Number: 0000000????3
Speed: 480Mb/s (high)
USB Version: 2.00
Device Class: 00(>ifc )
Device Subclass: 00
Device Protocol: 00
Maximum Default Endpoint Size: 64
Number of Configurations: 1
Vendor Id: 04b4
Product Id: 6830
Revision Number: 0.01
Config Number: 1
Number of Interfaces: 1
Attributes: c0
MaxPower Needed: 0mA
Interface Number: 0
Name: usb-storage
Alternate Number: 0
Class: 08(stor.)
Sub Class: 06
Protocol: 50
Number of Endpoints: 2
Endpoint Address: 02
Direction: out
Attribute: 2
Type: Bulk
Max Packet Size: 512
Interval: 0ms
Endpoint Address: 88
Direction: in
Attribute: 2
Type: Bulk
Max Packet Size: 512
Interval: 0ms
est - ce un problème connu des noyau 2.6 ?
merci
Eric
--
- A quoi tu penses ?
- Je pense que le jour où on mettra les cons sur orbite,
t'as pas fini de tourner.
Michel Audiard
On Wed, 05 May 2004 06:26:17 GMT, (gerard patel) wrote:
(...)
L'étude citée (sous Windows)
hum, je voulais dire celle-ci : http://www.xbitlabs.com/articles/storage/display/hi-speed-ubs_5.html
Gérard Patel
no_spam
On Wed, 05 May 2004 06:26:17 +0000, gerard patel wrote:
On Wed, 05 May 2004 03:15:17 +0200, no_spam wrote:
L'UHCI ne gère pas l'USB 2.0, mais il me semble que l'EHCI est une extension de l'UHCI (ou un dérivé).
l'EHCI gère l'USB à haute vitesse (également connu comme 2.0).
Oui, je sais bien, je dis juste qu'il me semble qu'il est conçu comme un dérivé de l'UHCI (qui gère le 1.1). Le parti pris de ces hards, c'est que le hard en fasse le moins possible et qu'une grande partie du boulot soit fait en soft, dans le driver.
12 Mbits/s, c'est irréaliste en USB 1.1. 4~5 Mbps sont un grand maximum, et ça consome 40% du temps CPU d'un PPC à 200 Mhz (sur lesquelles les exceptions sont rapides) utilisant de la SDRAM, donc sans doute pas loin de 20% d'un PC à 500 Mhz. Alors 14 Mo/s...
ben oui, 12 Mbits pour l'Usb 1.0, 480 Mbits pour le 2.0. 14 Mo/s => 112 Mbits ça ne parait pas irréaliste pour de l'Usb 2.0, meme avec une dégradation similaire des performances en réalité par rapport à la bande passante théorique.
Je ne le conteste pas: vu les problèmes de conceptions du bus et les overheads, il devrait être possible d'atteindre 150~160 Mbps en USB 2.0, en mode isochrone (pas pour un disque dur, donc). Ce que je voulais dire, c'est que à cette vitesse, le temps CPU consomé sera élevé. En USB, le temps CPU consomé est à peu près proportionnel au débit. Et le nombre d'IRQ générées est énorme (déjà en USB 1.1).
Les optimisations ne changeront pas le nombre d'IRQ, mais sans doute le code parcouru sous IRQ. Je viens de jeter un coup d'oeil, le code est plus lisible que celui de l'UHCI mais le principe de base semble être le même. La grande différence est que les nouvelles requêtes ne sont pas soumises au hard sous IRQ, mais en asynchrone. C'est bien pour limiter le temps consomé avec les IRQ désactivées, mais ça dégrade les performances, à priori: il y a un moment entre le traitement de l'IRQ et l'execution de la routine qui soumet de nouvelles requêtes ou l'USB peut se retrouver à ne plus avoir de requêtes en cours de traitement, alors même que le driver en a des tonnes à soumettre... On peut penser que sous très forte charge (du bus USB), ça ne devrait pas arriver, car le bus sera toujours engorgé... Mais, évidement, ce choix de traitement est un compromis... Il n'y a (malheureusement) pas de solution miracle ! A part avec bus bien designé, mais là, c'est de l'USB (ie Intel + Microsoft)...
la conception du bus et les compétences de Intel et Microsoft sont un peu hors sujet ici, mais bon je me méfie de toutes les opinions définitives qu'on voit sur Internet quand il y a des intérets en jeu (et la compétition Apple/monde Intel est un de ces conflits). Je ne serais pas étonné que des améliorations du code de Linux puissent permettre de se rapprocher plus des spécifications théoriques.
Il suffit de lire la norme pour se rendre compte que l'USB est complètement inefficace. Ce qui m'a de plus effaré quand j'ai du travaillé sur l'USB, c'est que cette spécification est très loin d'être de la qualité d'une norme industrielle, ce qu'elle prétend pourtant être. Quand je dis que la conception est absurde, c'est après avoir pas mal bossé sur le problème... Le genre de situation ou un device peut décider, par exemple, de ne pas répondre à une requête qui ne lui plait pas et laisser le controleur host tomber en timeout, le tout en bloquant l'intégralité du bus (et dans la réalité, ça arrive...), c'est absurde. Ca serait acceptable si le bus n'était pas bloqué pendant ce temps, mais en USB, le host ne peut pas addresser deux devices en même temps. Si un device répond toujours à la limite des timeouts, il ralentira tous les devices sur le bus (sauf si on ne lui parle jamais...). Il y a des dizaines d'exemples de ce genre. Quand je dis que la norme est loin d'une qualité industrielle, c'est que beaucoup de points ne sont pas ou mal spécifiés, ce qui entraine des incompatibilités de fait entre certains hards: il y a des devices qui ne fonctionnent que si on les met derrière un hub, par exemple, quel que soit l'OS, pour des sombres histoires de timings de signaux qui ne sont pas complètement spécifiés dans la norme. Le fait que Microsoft et Intel ai écrit cette norme ne justifie pas, en soi qu'elle soit mal écrite. Mais le fait est que... Si on m'amène demain une norme MS/Intel bien foutue je serais le premier à le reconnaitre... Bon, j'aurais du ajouter un gros smiley à ma remarque...
Après tout, 112/480 c'est beaucoup moins que 4-5/12. Et ce code de gestion de tampons circulaires et de gestions d'interruption, ce n'est pas simple à gérer dans la réalité.
Ca fait des rapports de 1/4 pour 1/3 dans l'autre cas. Pas une grosse différence. Par contre, ces taux max ne sont pas atteint dans
Ce ne sont pas des tampons circulaires, mais des queues de requêtes doublement chainées (il y a deux systèmes de queues "croisées", ce qui ne simplifie pas la gestion). Mais le problème est le même en USB 1.1, donc il n'y a pas de raison que ce soit moins efficace en EHCI qu'en UHCI.
qui indique qu'une bonne implémentation de l'Usb 2.0 devrait plafonner à 25 M/octets par seconde avec les controleurs actuels. Peut-etre que les performances du processeur limitent dans le cas des données citées par le post originel. L'étude citée (sous Windows) indiquent des taux d'occupation du Cpu qui varient beaucoup en raison de l'implémentation et de la taille du bloc; par exemple pour 3 controleurs et une taille de bloc de 4K (au niveau du programme appellant) les valeurs sont de 43%, 5% et 100%.
La taille du bloc au niveau user ne devrait avoir aucune influence sur les performances puisque les tailles des blocs USB sont détermninées par les capacités du device USB et que l'OS (au moins Linux) est censé merger les requêtes en attente et remplir au les requêtes USB au maximum pour limiter les overheads. S'il ne le fait pas, alors effectivement les performances peuvent se dégrader notoirement (jusqu'à être divisées par 100 ! => j'ai déjà vu des problèmes de ce genre en faisant des write(buf, 1); sync(); ) mais ça n'a pas lieu d'être dans une utilisation réelle.
Quand aux 25 Mo/s, ça me parait un peu optimiste. D'après mon expérience, je pense qu'on peut atteindre environ 160 Mbps => 20 Mo/s en mode isochrone. En mode bulk (celui majoritairement utilisé pour les disques), c'est un peu moins efficace, bien que l'overhead soit moindre en USB 2.0 qu'en USB 1.1 (taille des paquets USB pouvant atteindre 1024 octets contre 64 en USB 1.1). Je pense qu'on ne devrait perdre que 1 ou 2 Mo/s en bulk par rapport à l'isochrone, mais c'est une estimation à la louche, je n'ai pas vérifié en réel...
On Wed, 05 May 2004 06:26:17 +0000, gerard patel wrote:
On Wed, 05 May 2004 03:15:17 +0200, no_spam
<l_indien_no_more_spams@magic.fr> wrote:
L'UHCI ne gère pas l'USB 2.0, mais il me semble que l'EHCI est une
extension de l'UHCI (ou un dérivé).
l'EHCI gère l'USB à haute vitesse (également connu comme 2.0).
Oui, je sais bien, je dis juste qu'il me semble qu'il est conçu comme
un dérivé de l'UHCI (qui gère le 1.1).
Le parti pris de ces hards, c'est que le hard en fasse le moins possible
et qu'une grande partie du boulot soit fait en soft, dans le driver.
12 Mbits/s, c'est irréaliste en
USB 1.1. 4~5 Mbps sont un grand maximum, et ça consome 40% du temps
CPU d'un PPC à 200 Mhz (sur lesquelles les exceptions sont rapides)
utilisant de la SDRAM, donc sans doute pas loin de 20% d'un PC à
500 Mhz.
Alors 14 Mo/s...
ben oui, 12 Mbits pour l'Usb 1.0, 480 Mbits pour le 2.0.
14 Mo/s => 112 Mbits ça ne parait pas irréaliste pour de
l'Usb 2.0, meme avec une dégradation similaire des
performances en réalité par rapport à la bande passante
théorique.
Je ne le conteste pas: vu les problèmes de conceptions du bus
et les overheads, il devrait être possible d'atteindre 150~160 Mbps
en USB 2.0, en mode isochrone (pas pour un disque dur, donc).
Ce que je voulais dire, c'est que à cette vitesse, le temps CPU consomé
sera élevé. En USB, le temps CPU consomé est à peu près proportionnel
au débit. Et le nombre d'IRQ générées est énorme (déjà en USB 1.1).
Les optimisations ne changeront pas le nombre d'IRQ, mais sans doute
le code parcouru sous IRQ.
Je viens de jeter un coup d'oeil, le code est plus lisible que celui
de l'UHCI mais le principe de base semble être le même. La grande
différence est que les nouvelles requêtes ne sont pas soumises au hard
sous IRQ, mais en asynchrone. C'est bien pour limiter le temps consomé
avec les IRQ désactivées, mais ça dégrade les performances, à priori:
il y a un moment entre le traitement de l'IRQ et l'execution de la
routine qui soumet de nouvelles requêtes ou l'USB peut se retrouver
à ne plus avoir de requêtes en cours de traitement, alors même que
le driver en a des tonnes à soumettre... On peut penser que sous très
forte charge (du bus USB), ça ne devrait pas arriver, car le bus
sera toujours engorgé...
Mais, évidement, ce choix de traitement est un compromis... Il n'y a
(malheureusement) pas de solution miracle !
A part avec bus bien designé, mais là, c'est de l'USB (ie Intel +
Microsoft)...
la conception du bus et les compétences de Intel et Microsoft sont
un peu hors sujet ici, mais bon je me méfie de toutes les opinions
définitives qu'on voit sur Internet quand il y a des intérets en jeu
(et la compétition Apple/monde Intel est un de ces conflits).
Je ne serais pas étonné que des améliorations du code de Linux
puissent permettre de se rapprocher plus des spécifications
théoriques.
Il suffit de lire la norme pour se rendre compte que l'USB est
complètement inefficace. Ce qui m'a de plus effaré quand j'ai du
travaillé sur l'USB, c'est que cette spécification est très loin
d'être de la qualité d'une norme industrielle, ce qu'elle prétend
pourtant être. Quand je dis que la conception est absurde, c'est
après avoir pas mal bossé sur le problème... Le genre de situation
ou un device peut décider, par exemple, de ne pas répondre à une
requête qui ne lui plait pas et laisser le controleur host tomber
en timeout, le tout en bloquant l'intégralité du bus (et dans la
réalité, ça arrive...), c'est absurde. Ca serait acceptable si le
bus n'était pas bloqué pendant ce temps, mais en USB, le host ne
peut pas addresser deux devices en même temps. Si un device répond
toujours à la limite des timeouts, il ralentira tous les devices
sur le bus (sauf si on ne lui parle jamais...).
Il y a des dizaines d'exemples de ce genre.
Quand je dis que la norme est loin d'une qualité industrielle, c'est
que beaucoup de points ne sont pas ou mal spécifiés, ce qui entraine
des incompatibilités de fait entre certains hards: il y a des devices
qui ne fonctionnent que si on les met derrière un hub, par exemple,
quel que soit l'OS, pour des sombres histoires de timings de signaux
qui ne sont pas complètement spécifiés dans la norme.
Le fait que Microsoft et Intel ai écrit cette norme ne justifie pas, en
soi qu'elle soit mal écrite. Mais le fait est que...
Si on m'amène demain une norme MS/Intel bien foutue je serais le premier
à le reconnaitre...
Bon, j'aurais du ajouter un gros smiley à ma remarque...
Après tout, 112/480 c'est beaucoup moins que 4-5/12.
Et ce code de gestion de tampons circulaires et de gestions
d'interruption, ce n'est pas simple à gérer dans la réalité.
Ca fait des rapports de 1/4 pour 1/3 dans l'autre cas. Pas
une grosse différence. Par contre, ces taux max ne sont pas atteint
dans
Ce ne sont pas des tampons circulaires, mais des queues de requêtes
doublement chainées (il y a deux systèmes de queues "croisées", ce
qui ne simplifie pas la gestion). Mais le problème est le même en
USB 1.1, donc il n'y a pas de raison que ce soit moins efficace
en EHCI qu'en UHCI.
qui indique qu'une bonne implémentation de l'Usb 2.0 devrait
plafonner à 25 M/octets par seconde avec les controleurs
actuels. Peut-etre que les performances du processeur limitent
dans le cas des données citées par le post originel.
L'étude citée (sous Windows) indiquent des taux d'occupation
du Cpu qui varient beaucoup en raison de l'implémentation et
de la taille du bloc; par exemple pour 3 controleurs et une taille
de bloc de 4K (au niveau du programme appellant) les valeurs sont
de 43%, 5% et 100%.
La taille du bloc au niveau user ne devrait avoir aucune influence sur
les performances puisque les tailles des blocs USB sont détermninées
par les capacités du device USB et que l'OS (au moins Linux) est
censé merger les requêtes en attente et remplir au les requêtes USB
au maximum pour limiter les overheads.
S'il ne le fait pas, alors effectivement les performances peuvent se
dégrader notoirement (jusqu'à être divisées par 100 ! => j'ai déjà
vu des problèmes de ce genre en faisant des write(buf, 1); sync(); )
mais ça n'a pas lieu d'être dans une utilisation réelle.
Quand aux 25 Mo/s, ça me parait un peu optimiste. D'après mon
expérience, je pense qu'on peut atteindre environ 160 Mbps => 20 Mo/s
en mode isochrone. En mode bulk (celui majoritairement utilisé pour
les disques), c'est un peu moins efficace, bien que l'overhead soit
moindre en USB 2.0 qu'en USB 1.1 (taille des paquets USB pouvant
atteindre 1024 octets contre 64 en USB 1.1).
Je pense qu'on ne devrait perdre que 1 ou 2 Mo/s en bulk par rapport
à l'isochrone, mais c'est une estimation à la louche, je n'ai pas
vérifié en réel...
On Wed, 05 May 2004 06:26:17 +0000, gerard patel wrote:
On Wed, 05 May 2004 03:15:17 +0200, no_spam wrote:
L'UHCI ne gère pas l'USB 2.0, mais il me semble que l'EHCI est une extension de l'UHCI (ou un dérivé).
l'EHCI gère l'USB à haute vitesse (également connu comme 2.0).
Oui, je sais bien, je dis juste qu'il me semble qu'il est conçu comme un dérivé de l'UHCI (qui gère le 1.1). Le parti pris de ces hards, c'est que le hard en fasse le moins possible et qu'une grande partie du boulot soit fait en soft, dans le driver.
12 Mbits/s, c'est irréaliste en USB 1.1. 4~5 Mbps sont un grand maximum, et ça consome 40% du temps CPU d'un PPC à 200 Mhz (sur lesquelles les exceptions sont rapides) utilisant de la SDRAM, donc sans doute pas loin de 20% d'un PC à 500 Mhz. Alors 14 Mo/s...
ben oui, 12 Mbits pour l'Usb 1.0, 480 Mbits pour le 2.0. 14 Mo/s => 112 Mbits ça ne parait pas irréaliste pour de l'Usb 2.0, meme avec une dégradation similaire des performances en réalité par rapport à la bande passante théorique.
Je ne le conteste pas: vu les problèmes de conceptions du bus et les overheads, il devrait être possible d'atteindre 150~160 Mbps en USB 2.0, en mode isochrone (pas pour un disque dur, donc). Ce que je voulais dire, c'est que à cette vitesse, le temps CPU consomé sera élevé. En USB, le temps CPU consomé est à peu près proportionnel au débit. Et le nombre d'IRQ générées est énorme (déjà en USB 1.1).
Les optimisations ne changeront pas le nombre d'IRQ, mais sans doute le code parcouru sous IRQ. Je viens de jeter un coup d'oeil, le code est plus lisible que celui de l'UHCI mais le principe de base semble être le même. La grande différence est que les nouvelles requêtes ne sont pas soumises au hard sous IRQ, mais en asynchrone. C'est bien pour limiter le temps consomé avec les IRQ désactivées, mais ça dégrade les performances, à priori: il y a un moment entre le traitement de l'IRQ et l'execution de la routine qui soumet de nouvelles requêtes ou l'USB peut se retrouver à ne plus avoir de requêtes en cours de traitement, alors même que le driver en a des tonnes à soumettre... On peut penser que sous très forte charge (du bus USB), ça ne devrait pas arriver, car le bus sera toujours engorgé... Mais, évidement, ce choix de traitement est un compromis... Il n'y a (malheureusement) pas de solution miracle ! A part avec bus bien designé, mais là, c'est de l'USB (ie Intel + Microsoft)...
la conception du bus et les compétences de Intel et Microsoft sont un peu hors sujet ici, mais bon je me méfie de toutes les opinions définitives qu'on voit sur Internet quand il y a des intérets en jeu (et la compétition Apple/monde Intel est un de ces conflits). Je ne serais pas étonné que des améliorations du code de Linux puissent permettre de se rapprocher plus des spécifications théoriques.
Il suffit de lire la norme pour se rendre compte que l'USB est complètement inefficace. Ce qui m'a de plus effaré quand j'ai du travaillé sur l'USB, c'est que cette spécification est très loin d'être de la qualité d'une norme industrielle, ce qu'elle prétend pourtant être. Quand je dis que la conception est absurde, c'est après avoir pas mal bossé sur le problème... Le genre de situation ou un device peut décider, par exemple, de ne pas répondre à une requête qui ne lui plait pas et laisser le controleur host tomber en timeout, le tout en bloquant l'intégralité du bus (et dans la réalité, ça arrive...), c'est absurde. Ca serait acceptable si le bus n'était pas bloqué pendant ce temps, mais en USB, le host ne peut pas addresser deux devices en même temps. Si un device répond toujours à la limite des timeouts, il ralentira tous les devices sur le bus (sauf si on ne lui parle jamais...). Il y a des dizaines d'exemples de ce genre. Quand je dis que la norme est loin d'une qualité industrielle, c'est que beaucoup de points ne sont pas ou mal spécifiés, ce qui entraine des incompatibilités de fait entre certains hards: il y a des devices qui ne fonctionnent que si on les met derrière un hub, par exemple, quel que soit l'OS, pour des sombres histoires de timings de signaux qui ne sont pas complètement spécifiés dans la norme. Le fait que Microsoft et Intel ai écrit cette norme ne justifie pas, en soi qu'elle soit mal écrite. Mais le fait est que... Si on m'amène demain une norme MS/Intel bien foutue je serais le premier à le reconnaitre... Bon, j'aurais du ajouter un gros smiley à ma remarque...
Après tout, 112/480 c'est beaucoup moins que 4-5/12. Et ce code de gestion de tampons circulaires et de gestions d'interruption, ce n'est pas simple à gérer dans la réalité.
Ca fait des rapports de 1/4 pour 1/3 dans l'autre cas. Pas une grosse différence. Par contre, ces taux max ne sont pas atteint dans
Ce ne sont pas des tampons circulaires, mais des queues de requêtes doublement chainées (il y a deux systèmes de queues "croisées", ce qui ne simplifie pas la gestion). Mais le problème est le même en USB 1.1, donc il n'y a pas de raison que ce soit moins efficace en EHCI qu'en UHCI.
qui indique qu'une bonne implémentation de l'Usb 2.0 devrait plafonner à 25 M/octets par seconde avec les controleurs actuels. Peut-etre que les performances du processeur limitent dans le cas des données citées par le post originel. L'étude citée (sous Windows) indiquent des taux d'occupation du Cpu qui varient beaucoup en raison de l'implémentation et de la taille du bloc; par exemple pour 3 controleurs et une taille de bloc de 4K (au niveau du programme appellant) les valeurs sont de 43%, 5% et 100%.
La taille du bloc au niveau user ne devrait avoir aucune influence sur les performances puisque les tailles des blocs USB sont détermninées par les capacités du device USB et que l'OS (au moins Linux) est censé merger les requêtes en attente et remplir au les requêtes USB au maximum pour limiter les overheads. S'il ne le fait pas, alors effectivement les performances peuvent se dégrader notoirement (jusqu'à être divisées par 100 ! => j'ai déjà vu des problèmes de ce genre en faisant des write(buf, 1); sync(); ) mais ça n'a pas lieu d'être dans une utilisation réelle.
Quand aux 25 Mo/s, ça me parait un peu optimiste. D'après mon expérience, je pense qu'on peut atteindre environ 160 Mbps => 20 Mo/s en mode isochrone. En mode bulk (celui majoritairement utilisé pour les disques), c'est un peu moins efficace, bien que l'overhead soit moindre en USB 2.0 qu'en USB 1.1 (taille des paquets USB pouvant atteindre 1024 octets contre 64 en USB 1.1). Je pense qu'on ne devrait perdre que 1 ou 2 Mo/s en bulk par rapport à l'isochrone, mais c'est une estimation à la louche, je n'ai pas vérifié en réel...
