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
Je ne sais pas pourquoi mais çà marche ! j'ai juste essayer de jouer un peu avec supermount et maintenant plus de pb très étonnant !
à+ Eric -- Le bonheur est la poésie des femmes. Honoré de Balzac
sanao
Je ne sais pas pourquoi mais çà marche ! j'ai juste essayer de jouer un peu avec supermount et maintenant plus de pb très étonnant ! Salut,
Tu peux me dire ce que tu as fait avec supermount? Car j'ai le même problème que toi. Pourtant j'ai bien chargé le module ehci-hcd et UsbView me dit que c'est bien de l'USB 2. Mais le débit reste malgré tout en USB 1 (1,5Mo/s).
Si tu pouvais poster tes fichiers fstab, modules et modules.conf. Ce serait sympa.
Merci d'avance.
Je ne sais pas pourquoi mais çà marche !
j'ai juste essayer de jouer un peu avec supermount et maintenant plus de
pb très étonnant !
Salut,
Tu peux me dire ce que tu as fait avec supermount?
Car j'ai le même problème que toi. Pourtant j'ai bien chargé le module
ehci-hcd et UsbView me dit que c'est bien de l'USB 2. Mais le débit reste
malgré tout en USB 1 (1,5Mo/s).
Si tu pouvais poster tes fichiers fstab, modules et modules.conf. Ce serait
sympa.
Je ne sais pas pourquoi mais çà marche ! j'ai juste essayer de jouer un peu avec supermount et maintenant plus de pb très étonnant ! Salut,
Tu peux me dire ce que tu as fait avec supermount? Car j'ai le même problème que toi. Pourtant j'ai bien chargé le module ehci-hcd et UsbView me dit que c'est bien de l'USB 2. Mais le débit reste malgré tout en USB 1 (1,5Mo/s).
Si tu pouvais poster tes fichiers fstab, modules et modules.conf. Ce serait sympa.
Merci d'avance.
Ericus
Tu peux me dire ce que tu as fait avec supermount? Car j'ai le même problème que toi. Pourtant j'ai bien chargé le module ehci-hcd et UsbView me dit que c'est bien de l'USB 2. Mais le débit reste malgré tout en USB 1 (1,5Mo/s).
Si tu pouvais poster tes fichiers fstab, modules et modules.conf. Ce serait sympa.
Merci d'avance.
salut
en fin de compte j'ai désactivé (supermount -i disable), mais j'ai pas essayer de le remettre pour voir et je me suis aperçu après coup que dès que je copie/déplace/lis/écrit un fichier, çà prend beaucoup de CPU.... comprend pas pourquoi le débit atteint les 13/14 Mo/s. voilà le fstab :
je n'arrive pas à virer la dernière ligne, elle revient toute seule ! çà peut être gonflant, des fois, la mandrake ...
Voilà modules.conf :
probeall scsi_hostadapter dc395x_trm probeall usb-interface usb-uhci ehci-hcd alias sound-slot-0 snd-ens1371 alias eth0 ne2k-pci above snd-ens1371 snd-pcm-oss
et modules :
# /etc/modules: kernel modules to load at boot time. # # This file should contain the names of kernel modules that are # to be loaded at boot time, one per line. Comments begin with # a `#', and everything on the line after them are ignored.
scsi_hostadapter
-- Helas ! on voit que de tout temps Les petits ont pati des sottises des grands.
-- Jean de La Fontaine, Les Deux Taureaux et une Grenouille
Tu peux me dire ce que tu as fait avec supermount?
Car j'ai le même problème que toi. Pourtant j'ai bien chargé le module
ehci-hcd et UsbView me dit que c'est bien de l'USB 2. Mais le débit reste
malgré tout en USB 1 (1,5Mo/s).
Si tu pouvais poster tes fichiers fstab, modules et modules.conf. Ce
serait sympa.
Merci d'avance.
salut
en fin de compte j'ai désactivé (supermount -i disable), mais j'ai pas
essayer de le remettre pour voir
et je me suis aperçu après coup que dès que je copie/déplace/lis/écrit un
fichier, çà prend beaucoup de CPU....
comprend pas pourquoi
le débit atteint les 13/14 Mo/s.
voilà le fstab :
je n'arrive pas à virer la dernière ligne, elle revient toute seule !
çà peut être gonflant, des fois, la mandrake ...
Voilà modules.conf :
probeall scsi_hostadapter dc395x_trm
probeall usb-interface usb-uhci ehci-hcd
alias sound-slot-0 snd-ens1371
alias eth0 ne2k-pci
above snd-ens1371 snd-pcm-oss
et modules :
# /etc/modules: kernel modules to load at boot time.
#
# This file should contain the names of kernel modules that are
# to be loaded at boot time, one per line. Comments begin with
# a `#', and everything on the line after them are ignored.
scsi_hostadapter
--
Helas ! on voit que de tout temps
Les petits ont pati des sottises des grands.
-- Jean de La Fontaine, Les Deux Taureaux et une Grenouille
Tu peux me dire ce que tu as fait avec supermount? Car j'ai le même problème que toi. Pourtant j'ai bien chargé le module ehci-hcd et UsbView me dit que c'est bien de l'USB 2. Mais le débit reste malgré tout en USB 1 (1,5Mo/s).
Si tu pouvais poster tes fichiers fstab, modules et modules.conf. Ce serait sympa.
Merci d'avance.
salut
en fin de compte j'ai désactivé (supermount -i disable), mais j'ai pas essayer de le remettre pour voir et je me suis aperçu après coup que dès que je copie/déplace/lis/écrit un fichier, çà prend beaucoup de CPU.... comprend pas pourquoi le débit atteint les 13/14 Mo/s. voilà le fstab :
je n'arrive pas à virer la dernière ligne, elle revient toute seule ! çà peut être gonflant, des fois, la mandrake ...
Voilà modules.conf :
probeall scsi_hostadapter dc395x_trm probeall usb-interface usb-uhci ehci-hcd alias sound-slot-0 snd-ens1371 alias eth0 ne2k-pci above snd-ens1371 snd-pcm-oss
et modules :
# /etc/modules: kernel modules to load at boot time. # # This file should contain the names of kernel modules that are # to be loaded at boot time, one per line. Comments begin with # a `#', and everything on the line after them are ignored.
scsi_hostadapter
-- Helas ! on voit que de tout temps Les petits ont pati des sottises des grands.
-- Jean de La Fontaine, Les Deux Taureaux et une Grenouille
no_spam
On Mon, 03 May 2004 15:49:35 +0200, Ericus wrote:
Tu peux me dire ce que tu as fait avec supermount? Car j'ai le même problème que toi. Pourtant j'ai bien chargé le module ehci-hcd et UsbView me dit que c'est bien de l'USB 2. Mais le débit reste malgré tout en USB 1 (1,5Mo/s).
Si tu pouvais poster tes fichiers fstab, modules et modules.conf. Ce serait sympa.
Merci d'avance.
salut
en fin de compte j'ai désactivé (supermount -i disable), mais j'ai pas essayer de le remettre pour voir et je me suis aperçu après coup que dès que je copie/déplace/lis/écrit un fichier, çà prend beaucoup de CPU.... comprend pas pourquoi
Parce que l'USB est extrèmement inefficace. C'est un bouffeur de CPU par excellence...
le débit atteint les 13/14 Mo/s.
Ce qui, en supposant qu'il n'utilise que des frames de la taille maximum (1024 octets) fait 13000 interruptions par secondes. Tu commence à voir ou part ton temps CPU ? Et je ne compte pas tous les overheads (de 10 à plus de 100% suivant les situations)... La conception de l'USB est, disons défficiente, pour ne pas être méchant, et complètement inadaptée aux transferts rapides. Les overheads et les contraintes sont monstrueux...
Regardes l'évolution de cat /proc/interrupts durant les transferts, tu auras les chiffres réels...
On Mon, 03 May 2004 15:49:35 +0200, Ericus wrote:
Tu peux me dire ce que tu as fait avec supermount?
Car j'ai le même problème que toi. Pourtant j'ai bien chargé le module
ehci-hcd et UsbView me dit que c'est bien de l'USB 2. Mais le débit reste
malgré tout en USB 1 (1,5Mo/s).
Si tu pouvais poster tes fichiers fstab, modules et modules.conf. Ce
serait sympa.
Merci d'avance.
salut
en fin de compte j'ai désactivé (supermount -i disable), mais j'ai pas
essayer de le remettre pour voir
et je me suis aperçu après coup que dès que je copie/déplace/lis/écrit un
fichier, çà prend beaucoup de CPU....
comprend pas pourquoi
Parce que l'USB est extrèmement inefficace.
C'est un bouffeur de CPU par excellence...
le débit atteint les 13/14 Mo/s.
Ce qui, en supposant qu'il n'utilise que des frames de la taille
maximum (1024 octets) fait 13000 interruptions par secondes.
Tu commence à voir ou part ton temps CPU ?
Et je ne compte pas tous les overheads (de 10 à plus de 100% suivant
les situations)...
La conception de l'USB est, disons défficiente, pour ne pas être
méchant, et complètement inadaptée aux transferts rapides. Les
overheads et les contraintes sont monstrueux...
Regardes l'évolution de cat /proc/interrupts durant les transferts,
tu auras les chiffres réels...
Tu peux me dire ce que tu as fait avec supermount? Car j'ai le même problème que toi. Pourtant j'ai bien chargé le module ehci-hcd et UsbView me dit que c'est bien de l'USB 2. Mais le débit reste malgré tout en USB 1 (1,5Mo/s).
Si tu pouvais poster tes fichiers fstab, modules et modules.conf. Ce serait sympa.
Merci d'avance.
salut
en fin de compte j'ai désactivé (supermount -i disable), mais j'ai pas essayer de le remettre pour voir et je me suis aperçu après coup que dès que je copie/déplace/lis/écrit un fichier, çà prend beaucoup de CPU.... comprend pas pourquoi
Parce que l'USB est extrèmement inefficace. C'est un bouffeur de CPU par excellence...
le débit atteint les 13/14 Mo/s.
Ce qui, en supposant qu'il n'utilise que des frames de la taille maximum (1024 octets) fait 13000 interruptions par secondes. Tu commence à voir ou part ton temps CPU ? Et je ne compte pas tous les overheads (de 10 à plus de 100% suivant les situations)... La conception de l'USB est, disons défficiente, pour ne pas être méchant, et complètement inadaptée aux transferts rapides. Les overheads et les contraintes sont monstrueux...
Regardes l'évolution de cat /proc/interrupts durant les transferts, tu auras les chiffres réels...
g.patel
On Tue, 04 May 2004 00:23:25 +0200, no_spam wrote:
le débit atteint les 13/14 Mo/s.
Ce qui, en supposant qu'il n'utilise que des frames de la taille maximum (1024 octets) fait 13000 interruptions par secondes.
euh, il me semble que les controleurs USB ont des fonctionnalités de blocages de transaction.
Gérard Patel
On Tue, 04 May 2004 00:23:25 +0200, no_spam
<l_indien_no_more_spams@magic.fr> wrote:
le débit atteint les 13/14 Mo/s.
Ce qui, en supposant qu'il n'utilise que des frames de la taille
maximum (1024 octets) fait 13000 interruptions par secondes.
euh, il me semble que les controleurs USB ont des
fonctionnalités de blocages de transaction.
On Tue, 04 May 2004 00:23:25 +0200, no_spam wrote:
le débit atteint les 13/14 Mo/s.
Ce qui, en supposant qu'il n'utilise que des frames de la taille maximum (1024 octets) fait 13000 interruptions par secondes.
euh, il me semble que les controleurs USB ont des fonctionnalités de blocages de transaction.
Gérard Patel
no_spam
On Mon, 03 May 2004 22:55:39 +0000, gerard patel wrote:
On Tue, 04 May 2004 00:23:25 +0200, no_spam wrote:
le débit atteint les 13/14 Mo/s.
Ce qui, en supposant qu'il n'utilise que des frames de la taille maximum (1024 octets) fait 13000 interruptions par secondes.
euh, il me semble que les controleurs USB ont des fonctionnalités de blocages de transaction.
Que veux-tu dire par là ? Les controleurs UHCI et OHCI gèrent des queues de requètes, donc ils peuvent traiter des requêtes en continu, même si l'OS ne fait rien. Mais ils doivent signaler la fin de chaque requête, pour que l'OS puisse aller parcourir la queue et récupérer le (les) status. Et l'OS doit absolument attendre ces interruptions pour rajouter (ou enlever) des requêtes des queues, donc elles sont vitales, sous peine d'avoir des gros trous entre le traitement des paquets de requêtes... Déjà, par rapport aux controleurs plus "primitifs", l'OS n'a pas besoin de gérer les retry à la main, mais c'est à peu près tout ce que ça fait en plus (en fait, l'OHCI en fait bcp plus en hard, mais comme il tend à disparaitre...). Mais, au final, ça fait beaucoup d'interruptions, et bcp de travail CPU pendant le traitement des IRQ (parcours de toutes les queues...)
Pour s'en convaincre, un petit coup d'oeil au driver UHCI de Linux, particulièrement au handler d'interruption (et aux routines appelées) vaut le détour...
On Mon, 03 May 2004 22:55:39 +0000, gerard patel wrote:
On Tue, 04 May 2004 00:23:25 +0200, no_spam
<l_indien_no_more_spams@magic.fr> wrote:
le débit atteint les 13/14 Mo/s.
Ce qui, en supposant qu'il n'utilise que des frames de la taille
maximum (1024 octets) fait 13000 interruptions par secondes.
euh, il me semble que les controleurs USB ont des
fonctionnalités de blocages de transaction.
Que veux-tu dire par là ?
Les controleurs UHCI et OHCI gèrent des queues de requètes,
donc ils peuvent traiter des requêtes en continu, même si l'OS
ne fait rien. Mais ils doivent signaler la fin de chaque requête,
pour que l'OS puisse aller parcourir la queue et récupérer le
(les) status. Et l'OS doit absolument attendre ces interruptions
pour rajouter (ou enlever) des requêtes des queues, donc elles sont
vitales, sous peine d'avoir des gros trous entre le traitement des
paquets de requêtes...
Déjà, par rapport aux controleurs plus "primitifs", l'OS
n'a pas besoin de gérer les retry à la main, mais c'est à peu près
tout ce que ça fait en plus (en fait, l'OHCI en fait bcp plus en hard,
mais comme il tend à disparaitre...).
Mais, au final, ça fait beaucoup d'interruptions, et bcp de travail
CPU pendant le traitement des IRQ (parcours de toutes les queues...)
Pour s'en convaincre, un petit coup d'oeil au driver UHCI de Linux,
particulièrement au handler d'interruption (et aux routines appelées)
vaut le détour...
On Mon, 03 May 2004 22:55:39 +0000, gerard patel wrote:
On Tue, 04 May 2004 00:23:25 +0200, no_spam wrote:
le débit atteint les 13/14 Mo/s.
Ce qui, en supposant qu'il n'utilise que des frames de la taille maximum (1024 octets) fait 13000 interruptions par secondes.
euh, il me semble que les controleurs USB ont des fonctionnalités de blocages de transaction.
Que veux-tu dire par là ? Les controleurs UHCI et OHCI gèrent des queues de requètes, donc ils peuvent traiter des requêtes en continu, même si l'OS ne fait rien. Mais ils doivent signaler la fin de chaque requête, pour que l'OS puisse aller parcourir la queue et récupérer le (les) status. Et l'OS doit absolument attendre ces interruptions pour rajouter (ou enlever) des requêtes des queues, donc elles sont vitales, sous peine d'avoir des gros trous entre le traitement des paquets de requêtes... Déjà, par rapport aux controleurs plus "primitifs", l'OS n'a pas besoin de gérer les retry à la main, mais c'est à peu près tout ce que ça fait en plus (en fait, l'OHCI en fait bcp plus en hard, mais comme il tend à disparaitre...). Mais, au final, ça fait beaucoup d'interruptions, et bcp de travail CPU pendant le traitement des IRQ (parcours de toutes les queues...)
Pour s'en convaincre, un petit coup d'oeil au driver UHCI de Linux, particulièrement au handler d'interruption (et aux routines appelées) vaut le détour...
Ericus
et je me suis aperçu après coup que dès que je copie/déplace/lis/écrit un fichier, çà prend beaucoup de CPU.... comprend pas pourquoi
Parce que l'USB est extrèmement inefficace. C'est un bouffeur de CPU par excellence...
le débit atteint les 13/14 Mo/s.
Ce qui, en supposant qu'il n'utilise que des frames de la taille maximum (1024 octets) fait 13000 interruptions par secondes. Tu commence à voir ou part ton temps CPU ? Et je ne compte pas tous les overheads (de 10 à plus de 100% suivant les situations)... La conception de l'USB est, disons défficiente, pour ne pas être méchant, et complètement inadaptée aux transferts rapides. Les overheads et les contraintes sont monstrueux...
Regardes l'évolution de cat /proc/interrupts durant les transferts, tu auras les chiffres réels...
et pour les transferts ide ? j'ai le même phénomène avec les DD ide, 100% du cpu utilisé pendant copie/déplace/lis/écrit. j'utilise le mirroring logiciel, c'est peut-être une explication...
Cependant,de mémoire, je n'avais pas ces phénomènes avec la mdk 9.2 et noyau 2.4
à+ Eric
-- <shaddai> quand kelkun me ping ippl le voit pas <shaddai> c normal ? <FaKeR> ping par irc ou icmp? <shaddai> par irc <shaddai> mais g un firewall c pour ca surement
- #linuxfr
et je me suis aperçu après coup que dès que je copie/déplace/lis/écrit un
fichier, çà prend beaucoup de CPU....
comprend pas pourquoi
Parce que l'USB est extrèmement inefficace.
C'est un bouffeur de CPU par excellence...
le débit atteint les 13/14 Mo/s.
Ce qui, en supposant qu'il n'utilise que des frames de la taille
maximum (1024 octets) fait 13000 interruptions par secondes.
Tu commence à voir ou part ton temps CPU ?
Et je ne compte pas tous les overheads (de 10 à plus de 100% suivant
les situations)...
La conception de l'USB est, disons défficiente, pour ne pas être
méchant, et complètement inadaptée aux transferts rapides. Les
overheads et les contraintes sont monstrueux...
Regardes l'évolution de cat /proc/interrupts durant les transferts,
tu auras les chiffres réels...
et pour les transferts ide ?
j'ai le même phénomène avec les DD ide,
100% du cpu utilisé pendant copie/déplace/lis/écrit.
j'utilise le mirroring logiciel, c'est peut-être une explication...
Cependant,de mémoire, je n'avais pas ces phénomènes avec la mdk 9.2 et noyau
2.4
à+
Eric
--
<shaddai> quand kelkun me ping ippl le voit pas
<shaddai> c normal ?
<FaKeR> ping par irc ou icmp?
<shaddai> par irc
<shaddai> mais g un firewall c pour ca surement
et je me suis aperçu après coup que dès que je copie/déplace/lis/écrit un fichier, çà prend beaucoup de CPU.... comprend pas pourquoi
Parce que l'USB est extrèmement inefficace. C'est un bouffeur de CPU par excellence...
le débit atteint les 13/14 Mo/s.
Ce qui, en supposant qu'il n'utilise que des frames de la taille maximum (1024 octets) fait 13000 interruptions par secondes. Tu commence à voir ou part ton temps CPU ? Et je ne compte pas tous les overheads (de 10 à plus de 100% suivant les situations)... La conception de l'USB est, disons défficiente, pour ne pas être méchant, et complètement inadaptée aux transferts rapides. Les overheads et les contraintes sont monstrueux...
Regardes l'évolution de cat /proc/interrupts durant les transferts, tu auras les chiffres réels...
et pour les transferts ide ? j'ai le même phénomène avec les DD ide, 100% du cpu utilisé pendant copie/déplace/lis/écrit. j'utilise le mirroring logiciel, c'est peut-être une explication...
Cependant,de mémoire, je n'avais pas ces phénomènes avec la mdk 9.2 et noyau 2.4
à+ Eric
-- <shaddai> quand kelkun me ping ippl le voit pas <shaddai> c normal ? <FaKeR> ping par irc ou icmp? <shaddai> par irc <shaddai> mais g un firewall c pour ca surement
- #linuxfr
g.patel
On Tue, 04 May 2004 03:43:34 +0200, no_spam wrote:
(...l'Usb c'est fatiguant pour le CPU...)
Pour s'en convaincre, un petit coup d'oeil au driver UHCI de Linux, particulièrement au handler d'interruption (et aux routines appelées) vaut le détour...
euh... le pilote UHCI ça marche pour les hautes vitesses ? Il me semblait que l'UHCI c'était pour le 12 Mbits/secondes maximum. Je ne pense pas qu'il s'agisse de Fast Usb avec un taux de transfert de 14 M/octets par secondes comme indiqué dans le post originel. Pour du 12Mbits/secondes, ça fait de l'ordre de 1000 interruptions par seconde, ça ne devrait pas charger excessivement un processeur à disons 500 Mhz.
J'ai jeté un oeil au pilote de l'EHCI du noyau 2.6, juste à parcourir les commentaires, je suis trop f... pour plus; il y a quelques références à un ratio d'interruptions/trames, mais aussi quelques indications que l'optimisation pourrait etre encore un travail en cours (pas mal de 'Fixme' et de 'for now')
Gérard Patel
On Tue, 04 May 2004 03:43:34 +0200, no_spam
<l_indien_no_more_spams@magic.fr> wrote:
(...l'Usb c'est fatiguant pour le CPU...)
Pour s'en convaincre, un petit coup d'oeil au driver UHCI de Linux,
particulièrement au handler d'interruption (et aux routines appelées)
vaut le détour...
euh... le pilote UHCI ça marche pour les hautes vitesses ? Il
me semblait que l'UHCI c'était pour le 12 Mbits/secondes maximum.
Je ne pense pas qu'il s'agisse de Fast Usb avec un taux de
transfert de 14 M/octets par secondes comme indiqué dans le
post originel. Pour du 12Mbits/secondes, ça fait de l'ordre de
1000 interruptions par seconde, ça ne devrait pas charger
excessivement un processeur à disons 500 Mhz.
J'ai jeté un oeil au pilote de l'EHCI du noyau 2.6, juste à parcourir
les commentaires, je suis trop f... pour plus; il y a quelques
références à un ratio d'interruptions/trames, mais aussi quelques
indications que l'optimisation pourrait etre encore un travail en
cours (pas mal de 'Fixme' et de 'for now')
On Tue, 04 May 2004 03:43:34 +0200, no_spam wrote:
(...l'Usb c'est fatiguant pour le CPU...)
Pour s'en convaincre, un petit coup d'oeil au driver UHCI de Linux, particulièrement au handler d'interruption (et aux routines appelées) vaut le détour...
euh... le pilote UHCI ça marche pour les hautes vitesses ? Il me semblait que l'UHCI c'était pour le 12 Mbits/secondes maximum. Je ne pense pas qu'il s'agisse de Fast Usb avec un taux de transfert de 14 M/octets par secondes comme indiqué dans le post originel. Pour du 12Mbits/secondes, ça fait de l'ordre de 1000 interruptions par seconde, ça ne devrait pas charger excessivement un processeur à disons 500 Mhz.
J'ai jeté un oeil au pilote de l'EHCI du noyau 2.6, juste à parcourir les commentaires, je suis trop f... pour plus; il y a quelques références à un ratio d'interruptions/trames, mais aussi quelques indications que l'optimisation pourrait etre encore un travail en cours (pas mal de 'Fixme' et de 'for now')
Gérard Patel
no_spam
On Tue, 04 May 2004 21:09:09 +0000, gerard patel wrote:
On Tue, 04 May 2004 03:43:34 +0200, no_spam wrote:
(...l'Usb c'est fatiguant pour le CPU...)
Pour s'en convaincre, un petit coup d'oeil au driver UHCI de Linux, particulièrement au handler d'interruption (et aux routines appelées) vaut le détour...
euh... le pilote UHCI ça marche pour les hautes vitesses ? Il me semblait que l'UHCI c'était pour le 12 Mbits/secondes maximum. Je ne pense pas qu'il s'agisse de Fast Usb avec un taux de transfert de 14 M/octets par secondes comme indiqué dans le post originel. Pour du 12Mbits/secondes, ça fait de l'ordre de 1000 interruptions par seconde, ça ne devrait pas charger excessivement un processeur à disons 500 Mhz.
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é). 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...
J'ai jeté un oeil au pilote de l'EHCI du noyau 2.6, juste à parcourir les commentaires, je suis trop f... pour plus; il y a quelques références à un ratio d'interruptions/trames, mais aussi quelques indications que l'optimisation pourrait etre encore un travail en cours (pas mal de 'Fixme' et de 'for now')
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)...
On Tue, 04 May 2004 21:09:09 +0000, gerard patel wrote:
On Tue, 04 May 2004 03:43:34 +0200, no_spam
<l_indien_no_more_spams@magic.fr> wrote:
(...l'Usb c'est fatiguant pour le CPU...)
Pour s'en convaincre, un petit coup d'oeil au driver UHCI de Linux,
particulièrement au handler d'interruption (et aux routines appelées)
vaut le détour...
euh... le pilote UHCI ça marche pour les hautes vitesses ? Il
me semblait que l'UHCI c'était pour le 12 Mbits/secondes maximum.
Je ne pense pas qu'il s'agisse de Fast Usb avec un taux de
transfert de 14 M/octets par secondes comme indiqué dans le
post originel. Pour du 12Mbits/secondes, ça fait de l'ordre de
1000 interruptions par seconde, ça ne devrait pas charger
excessivement un processeur à disons 500 Mhz.
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é). 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...
J'ai jeté un oeil au pilote de l'EHCI du noyau 2.6, juste à parcourir
les commentaires, je suis trop f... pour plus; il y a quelques
références à un ratio d'interruptions/trames, mais aussi quelques
indications que l'optimisation pourrait etre encore un travail en
cours (pas mal de 'Fixme' et de 'for now')
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)...
On Tue, 04 May 2004 21:09:09 +0000, gerard patel wrote:
On Tue, 04 May 2004 03:43:34 +0200, no_spam wrote:
(...l'Usb c'est fatiguant pour le CPU...)
Pour s'en convaincre, un petit coup d'oeil au driver UHCI de Linux, particulièrement au handler d'interruption (et aux routines appelées) vaut le détour...
euh... le pilote UHCI ça marche pour les hautes vitesses ? Il me semblait que l'UHCI c'était pour le 12 Mbits/secondes maximum. Je ne pense pas qu'il s'agisse de Fast Usb avec un taux de transfert de 14 M/octets par secondes comme indiqué dans le post originel. Pour du 12Mbits/secondes, ça fait de l'ordre de 1000 interruptions par seconde, ça ne devrait pas charger excessivement un processeur à disons 500 Mhz.
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é). 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...
J'ai jeté un oeil au pilote de l'EHCI du noyau 2.6, juste à parcourir les commentaires, je suis trop f... pour plus; il y a quelques références à un ratio d'interruptions/trames, mais aussi quelques indications que l'optimisation pourrait etre encore un travail en cours (pas mal de 'Fixme' et de 'for now')
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)...
g.patel
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).
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.
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. 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é.
Une petite recherche Internet me donne ce lien : http://www.xbitlabs.com/articles/storage/display/vt6212_4.html
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%.
Gérard Patel
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).
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.
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. 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é.
Une petite recherche Internet me donne ce lien :
http://www.xbitlabs.com/articles/storage/display/vt6212_4.html
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%.
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).
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.
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. 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é.
Une petite recherche Internet me donne ce lien : http://www.xbitlabs.com/articles/storage/display/vt6212_4.html
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%.
