Bonjour,
J'ai des ralentissements importants qui occasionnent des saccades lorsque
j'ai des accès disques importants comme la copie d'un gros (plusieurs
dizaines de Mo) fichier ou sa lecture.
Ces ralentissements créés des saccades dans tous les autres programmes. Pour
le son et la vidéo il y a des coupures et pour les autres, la souris est
bloquée et le rafraîchisement des fenêtres n'est plus effectués. Ces
coupures durents quelques fractions de secondes, mais elles sont
nombreuses. Et cela tant que les accès disques durent.
Je suis sous Mandrake 10 Officiel et utilise KDE 3.2. Pour le matériel j'ai
un Athlon 1200 avec 380 Mo de RAM.
Si quelqu'un avait une idée pour régler ce problème, car c'est vraiment
embêtant, car à part cela, tout fonctionne très bien.
/dev/hda: multcount = 0 (off) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) /dev/hdb: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) IO_support est la capacité du contrôleur (mais pas des disques
eux-mêmes) à communiquer avec le bus sur lequel il est connecté. Ca me paraît donc bizarre que IO_support soit à 0 pour hda et à 1 pour hdb.
multcount permet d'indiquer combien de secteurs peuvent être lus par interruption. Quand le noyau demande des secteurs au disque, il n'attend pas que le disque les lui retourne immédiatement, le disque étant TRES lent par rapport au processeur, ce serait du temps gaspillé. Quand le disque est prêt à fournir le(s) secteur(s), il émet une interruption. multcount permet au disque de ne générer qu'une interruption pour plusieurs secteurs. Quand cette option est désactivée, 1 secteur=1 interruption, ce qui peut être pénalisant dans un environnement multitâche où de grosses quantités de données sont lus sur le disque car à chaque interruption le noyau doit sauver l'état en cours, s'occuper du disque et restaurer l'état sauvegardé (donc gaspillage de temps).
unmaskirq permet à une autre interruption (souris, clavier, réseau) d'être traitée alors que le noyau est déjà en train de traiter une interruption disque. Dès l'instant où cette option est activée pour un disque, il n'y a pas de raison qu'elle ne le soit pas pour les autres. Cette option est à tester avant de l'utiliser en environnement de production car certains chipsets ne permettraient pas de l'utiliser de manière stable.
Je pense que tu peux essayer d'activer ces options pour /dev/hda aux mêmes valeurs que pour les autres disques (avec /sbin/hdparm). Exécute d'abord une commande sync à tout hasard avant de commencer. Sur ces options, au pire, tu bloqueras ta machine (je dis ça plus par expérience personnelle).
Pour savoir si elles apportent un plus, ne te limite pas aux chiffres de /sbin/hdparm -tT mais regarde également l'utilisation processeur quand tu fais des copies. Même si le taux de transfert n'augmente pas, un allègement de l'occupation processeur est toujours appréciable.
@+
Frédéric BISSON
/dev/hda:
multcount = 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
/dev/hdb:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
IO_support est la capacité du contrôleur (mais pas des disques
eux-mêmes) à communiquer avec le bus sur lequel il est connecté.
Ca me paraît donc bizarre que IO_support soit à 0 pour hda et à 1 pour
hdb.
multcount permet d'indiquer combien de secteurs peuvent être lus par
interruption. Quand le noyau demande des secteurs au disque, il n'attend
pas que le disque les lui retourne immédiatement, le disque étant TRES
lent par rapport au processeur, ce serait du temps gaspillé. Quand le
disque est prêt à fournir le(s) secteur(s), il émet une interruption.
multcount permet au disque de ne générer qu'une interruption pour
plusieurs secteurs. Quand cette option est désactivée, 1 secteur=1
interruption, ce qui peut être pénalisant dans un environnement
multitâche où de grosses quantités de données sont lus sur le disque
car à chaque interruption le noyau doit sauver l'état en cours,
s'occuper du disque et restaurer l'état sauvegardé (donc gaspillage de
temps).
unmaskirq permet à une autre interruption (souris, clavier, réseau)
d'être traitée alors que le noyau est déjà en train de traiter une
interruption disque. Dès l'instant où cette option est activée pour un
disque, il n'y a pas de raison qu'elle ne le soit pas pour les autres.
Cette option est à tester avant de l'utiliser en environnement de
production car certains chipsets ne permettraient pas de l'utiliser de
manière stable.
Je pense que tu peux essayer d'activer ces options pour /dev/hda aux
mêmes valeurs que pour les autres disques (avec /sbin/hdparm). Exécute
d'abord une commande sync à tout hasard avant de commencer. Sur ces
options, au pire, tu bloqueras ta machine (je dis ça plus par expérience
personnelle).
Pour savoir si elles apportent un plus, ne te limite pas aux chiffres de
/sbin/hdparm -tT mais regarde également l'utilisation processeur quand tu
fais des copies. Même si le taux de transfert n'augmente pas, un
allègement de l'occupation processeur est toujours appréciable.
/dev/hda: multcount = 0 (off) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) /dev/hdb: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) IO_support est la capacité du contrôleur (mais pas des disques
eux-mêmes) à communiquer avec le bus sur lequel il est connecté. Ca me paraît donc bizarre que IO_support soit à 0 pour hda et à 1 pour hdb.
multcount permet d'indiquer combien de secteurs peuvent être lus par interruption. Quand le noyau demande des secteurs au disque, il n'attend pas que le disque les lui retourne immédiatement, le disque étant TRES lent par rapport au processeur, ce serait du temps gaspillé. Quand le disque est prêt à fournir le(s) secteur(s), il émet une interruption. multcount permet au disque de ne générer qu'une interruption pour plusieurs secteurs. Quand cette option est désactivée, 1 secteur=1 interruption, ce qui peut être pénalisant dans un environnement multitâche où de grosses quantités de données sont lus sur le disque car à chaque interruption le noyau doit sauver l'état en cours, s'occuper du disque et restaurer l'état sauvegardé (donc gaspillage de temps).
unmaskirq permet à une autre interruption (souris, clavier, réseau) d'être traitée alors que le noyau est déjà en train de traiter une interruption disque. Dès l'instant où cette option est activée pour un disque, il n'y a pas de raison qu'elle ne le soit pas pour les autres. Cette option est à tester avant de l'utiliser en environnement de production car certains chipsets ne permettraient pas de l'utiliser de manière stable.
Je pense que tu peux essayer d'activer ces options pour /dev/hda aux mêmes valeurs que pour les autres disques (avec /sbin/hdparm). Exécute d'abord une commande sync à tout hasard avant de commencer. Sur ces options, au pire, tu bloqueras ta machine (je dis ça plus par expérience personnelle).
Pour savoir si elles apportent un plus, ne te limite pas aux chiffres de /sbin/hdparm -tT mais regarde également l'utilisation processeur quand tu fais des copies. Même si le taux de transfert n'augmente pas, un allègement de l'occupation processeur est toujours appréciable.
@+
Frédéric BISSON
toto
Frédéric BISSON wrote:
/dev/hda: multcount = 0 (off) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) /dev/hdb: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) IO_support est la capacité du contrôleur (mais pas des disques
eux-mêmes) à communiquer avec le bus sur lequel il est connecté. Ca me paraît donc bizarre que IO_support soit à 0 pour hda et à 1 pour hdb.
multcount permet d'indiquer combien de secteurs peuvent être lus par interruption. Quand le noyau demande des secteurs au disque, il n'attend pas que le disque les lui retourne immédiatement, le disque étant TRES lent par rapport au processeur, ce serait du temps gaspillé. Quand le disque est prêt à fournir le(s) secteur(s), il émet une interruption. multcount permet au disque de ne générer qu'une interruption pour plusieurs secteurs. Quand cette option est désactivée, 1 secteur=1 interruption, ce qui peut être pénalisant dans un environnement multitâche où de grosses quantités de données sont lus sur le disque car à chaque interruption le noyau doit sauver l'état en cours, s'occuper du disque et restaurer l'état sauvegardé (donc gaspillage de temps).
unmaskirq permet à une autre interruption (souris, clavier, réseau) d'être traitée alors que le noyau est déjà en train de traiter une interruption disque. Dès l'instant où cette option est activée pour un disque, il n'y a pas de raison qu'elle ne le soit pas pour les autres. Cette option est à tester avant de l'utiliser en environnement de production car certains chipsets ne permettraient pas de l'utiliser de manière stable.
Je pense que tu peux essayer d'activer ces options pour /dev/hda aux mêmes valeurs que pour les autres disques (avec /sbin/hdparm). Exécute d'abord une commande sync à tout hasard avant de commencer. Sur ces options, au pire, tu bloqueras ta machine (je dis ça plus par expérience personnelle).
Pour savoir si elles apportent un plus, ne te limite pas aux chiffres de /sbin/hdparm -tT mais regarde également l'utilisation processeur quand tu fais des copies. Même si le taux de transfert n'augmente pas, un allègement de l'occupation processeur est toujours appréciable.
J'ai modifié toutes les options pour qu'elles soient toutes identiques aux autres disques. Et je n'ai pas eu de problème.
Pour les performances je ne vois pas de différence.
Si je redémarre la machine, est-ce que les options seront toujours les mêmes? Car pour l'instant je n'ai pas redémarré et ça m'embête de devoir le faire pour vérifier si elles seront sauvegardées.
Encore merci.
Frédéric BISSON wrote:
/dev/hda:
multcount = 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
/dev/hdb:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
IO_support est la capacité du contrôleur (mais pas des disques
eux-mêmes) à communiquer avec le bus sur lequel il est connecté.
Ca me paraît donc bizarre que IO_support soit à 0 pour hda et à 1 pour
hdb.
multcount permet d'indiquer combien de secteurs peuvent être lus par
interruption. Quand le noyau demande des secteurs au disque, il n'attend
pas que le disque les lui retourne immédiatement, le disque étant TRES
lent par rapport au processeur, ce serait du temps gaspillé. Quand le
disque est prêt à fournir le(s) secteur(s), il émet une interruption.
multcount permet au disque de ne générer qu'une interruption pour
plusieurs secteurs. Quand cette option est désactivée, 1 secteur=1
interruption, ce qui peut être pénalisant dans un environnement
multitâche où de grosses quantités de données sont lus sur le disque
car à chaque interruption le noyau doit sauver l'état en cours,
s'occuper du disque et restaurer l'état sauvegardé (donc gaspillage de
temps).
unmaskirq permet à une autre interruption (souris, clavier, réseau)
d'être traitée alors que le noyau est déjà en train de traiter une
interruption disque. Dès l'instant où cette option est activée pour un
disque, il n'y a pas de raison qu'elle ne le soit pas pour les autres.
Cette option est à tester avant de l'utiliser en environnement de
production car certains chipsets ne permettraient pas de l'utiliser de
manière stable.
Je pense que tu peux essayer d'activer ces options pour /dev/hda aux
mêmes valeurs que pour les autres disques (avec /sbin/hdparm). Exécute
d'abord une commande sync à tout hasard avant de commencer. Sur ces
options, au pire, tu bloqueras ta machine (je dis ça plus par expérience
personnelle).
Pour savoir si elles apportent un plus, ne te limite pas aux chiffres de
/sbin/hdparm -tT mais regarde également l'utilisation processeur quand tu
fais des copies. Même si le taux de transfert n'augmente pas, un
allègement de l'occupation processeur est toujours appréciable.
J'ai modifié toutes les options pour qu'elles soient toutes identiques aux
autres disques. Et je n'ai pas eu de problème.
Pour les performances je ne vois pas de différence.
Si je redémarre la machine, est-ce que les options seront toujours les
mêmes? Car pour l'instant je n'ai pas redémarré et ça m'embête de devoir le
faire pour vérifier si elles seront sauvegardées.
/dev/hda: multcount = 0 (off) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) /dev/hdb: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) IO_support est la capacité du contrôleur (mais pas des disques
eux-mêmes) à communiquer avec le bus sur lequel il est connecté. Ca me paraît donc bizarre que IO_support soit à 0 pour hda et à 1 pour hdb.
multcount permet d'indiquer combien de secteurs peuvent être lus par interruption. Quand le noyau demande des secteurs au disque, il n'attend pas que le disque les lui retourne immédiatement, le disque étant TRES lent par rapport au processeur, ce serait du temps gaspillé. Quand le disque est prêt à fournir le(s) secteur(s), il émet une interruption. multcount permet au disque de ne générer qu'une interruption pour plusieurs secteurs. Quand cette option est désactivée, 1 secteur=1 interruption, ce qui peut être pénalisant dans un environnement multitâche où de grosses quantités de données sont lus sur le disque car à chaque interruption le noyau doit sauver l'état en cours, s'occuper du disque et restaurer l'état sauvegardé (donc gaspillage de temps).
unmaskirq permet à une autre interruption (souris, clavier, réseau) d'être traitée alors que le noyau est déjà en train de traiter une interruption disque. Dès l'instant où cette option est activée pour un disque, il n'y a pas de raison qu'elle ne le soit pas pour les autres. Cette option est à tester avant de l'utiliser en environnement de production car certains chipsets ne permettraient pas de l'utiliser de manière stable.
Je pense que tu peux essayer d'activer ces options pour /dev/hda aux mêmes valeurs que pour les autres disques (avec /sbin/hdparm). Exécute d'abord une commande sync à tout hasard avant de commencer. Sur ces options, au pire, tu bloqueras ta machine (je dis ça plus par expérience personnelle).
Pour savoir si elles apportent un plus, ne te limite pas aux chiffres de /sbin/hdparm -tT mais regarde également l'utilisation processeur quand tu fais des copies. Même si le taux de transfert n'augmente pas, un allègement de l'occupation processeur est toujours appréciable.
J'ai modifié toutes les options pour qu'elles soient toutes identiques aux autres disques. Et je n'ai pas eu de problème.
Pour les performances je ne vois pas de différence.
Si je redémarre la machine, est-ce que les options seront toujours les mêmes? Car pour l'instant je n'ai pas redémarré et ça m'embête de devoir le faire pour vérifier si elles seront sauvegardées.
Encore merci.
toto
est-ce que tu pourrais me mailer le fichier de config de ton kernel (config-2.6.xx dans /boot/ ; mon adresse est ), j'aimerais voir quelque chose, et comparer certaines options avec mon kernel actuel. C'est fait. Je te l'ai envoyé.
est-ce que tu pourrais me mailer le fichier de config de ton kernel
(config-2.6.xx dans /boot/ ; mon adresse est bricem13@yahoo.com),
j'aimerais voir quelque chose, et comparer certaines options avec mon
kernel actuel.
C'est fait. Je te l'ai envoyé.
est-ce que tu pourrais me mailer le fichier de config de ton kernel (config-2.6.xx dans /boot/ ; mon adresse est ), j'aimerais voir quelque chose, et comparer certaines options avec mon kernel actuel. C'est fait. Je te l'ai envoyé.
Frédéric BISSON
Si je redémarre la machine, est-ce que les options seront toujours les mêmes? Car pour l'instant je n'ai pas redémarré et ça m'embête de devoir le faire pour vérifier si elles seront sauvegardées. Normalement non.
Sous Red Hat, il suffit de modifier /etc/sysconfig/harddisks pour sélectionner les valeurs par défaut des disques. Tu peux également rajouter les commandes idoines dans /etc/rc.local
@+
Frédéric BISSON
Si je redémarre la machine, est-ce que les options seront toujours les
mêmes? Car pour l'instant je n'ai pas redémarré et ça m'embête de devoir le
faire pour vérifier si elles seront sauvegardées.
Normalement non.
Sous Red Hat, il suffit de modifier /etc/sysconfig/harddisks pour
sélectionner les valeurs par défaut des disques.
Tu peux également rajouter les commandes idoines dans /etc/rc.local
Si je redémarre la machine, est-ce que les options seront toujours les mêmes? Car pour l'instant je n'ai pas redémarré et ça m'embête de devoir le faire pour vérifier si elles seront sauvegardées. Normalement non.
Sous Red Hat, il suffit de modifier /etc/sysconfig/harddisks pour sélectionner les valeurs par défaut des disques. Tu peux également rajouter les commandes idoines dans /etc/rc.local
IO_support est la capacité du contrôleur (mais pas des disques eux-mêmes) à communiquer avec le bus sur lequel il est connecté. Ca me paraît donc bizarre que IO_support soit à 0 pour hda et à 1 pour hdb.
Si j'ai bien compris, ce paramètre ne sert qu'en mode PIO, donc pas utile si le mode (Ultra)DMA est activé.
IO_support est la capacité du contrôleur (mais pas des disques
eux-mêmes) à communiquer avec le bus sur lequel il est connecté.
Ca me paraît donc bizarre que IO_support soit à 0 pour hda et à 1 pour
hdb.
Si j'ai bien compris, ce paramètre ne sert qu'en mode PIO, donc pas
utile si le mode (Ultra)DMA est activé.
IO_support est la capacité du contrôleur (mais pas des disques eux-mêmes) à communiquer avec le bus sur lequel il est connecté. Ca me paraît donc bizarre que IO_support soit à 0 pour hda et à 1 pour hdb.
Si j'ai bien compris, ce paramètre ne sert qu'en mode PIO, donc pas utile si le mode (Ultra)DMA est activé.
Annie D.
Alain Labarthe wrote:
Le 28-08-2004, Frédéric BISSON écrivait:
D'ailleurs j'en profite pour demander s'il est normal que je sois passé de 7,80 MB/sec à 58,13 MB/sec ... sur un DD que je viens d'acheter ? ça me semble un peu beaucoup mais j'ai vérifié 3 fois!
Si tu es passé de 7,80 MB/sec sans DMA à 58,13 MB/sec avec DMA, c'est normal.
Par contre, si tu as vu le changement s'opérer sans toucher à quoi que ce soit, c'est un peu plus bizarre...
J'ai bien sûr activé le dma, mais je n'avais jamais vu un tel gain.
C'est peut-être parce que vous n'aviez pas encore eu de disque aussi rapide. Le mode PIO 4 permet théoriquement un débit de l'ordre de 16 Mo/s, mais la gestion des accès PIO par le bus PCI est désastreuse.
Alain Labarthe wrote:
Le 28-08-2004, Frédéric BISSON écrivait:
D'ailleurs j'en profite pour demander s'il est normal que je sois
passé de 7,80 MB/sec à 58,13 MB/sec ... sur un DD que je viens
d'acheter ? ça me semble un peu beaucoup mais j'ai vérifié 3 fois!
Si tu es passé de 7,80 MB/sec sans DMA à 58,13 MB/sec avec DMA, c'est
normal.
Par contre, si tu as vu le changement s'opérer sans toucher à quoi que
ce soit, c'est un peu plus bizarre...
J'ai bien sûr activé le dma, mais je n'avais jamais vu un tel gain.
C'est peut-être parce que vous n'aviez pas encore eu de disque aussi
rapide. Le mode PIO 4 permet théoriquement un débit de l'ordre de 16
Mo/s, mais la gestion des accès PIO par le bus PCI est désastreuse.
D'ailleurs j'en profite pour demander s'il est normal que je sois passé de 7,80 MB/sec à 58,13 MB/sec ... sur un DD que je viens d'acheter ? ça me semble un peu beaucoup mais j'ai vérifié 3 fois!
Si tu es passé de 7,80 MB/sec sans DMA à 58,13 MB/sec avec DMA, c'est normal.
Par contre, si tu as vu le changement s'opérer sans toucher à quoi que ce soit, c'est un peu plus bizarre...
J'ai bien sûr activé le dma, mais je n'avais jamais vu un tel gain.
C'est peut-être parce que vous n'aviez pas encore eu de disque aussi rapide. Le mode PIO 4 permet théoriquement un débit de l'ordre de 16 Mo/s, mais la gestion des accès PIO par le bus PCI est désastreuse.
Frédéric BISSON
IO_support est la capacité du contrôleur (mais pas des disques eux-mêmes) à communiquer avec le bus sur lequel il est connecté. Ca me paraît donc bizarre que IO_support soit à 0 pour hda et à 1 pour hdb. Si j'ai bien compris, ce paramètre ne sert qu'en mode PIO, donc pas
utile si le mode (Ultra)DMA est activé. Je ne le savais pas.
Je me suis borné à faire un man et il n'en parle pas. Peux-tu me donner ta source, ça m'intéresse ! :-)
@+
Frédéric BISSON
IO_support est la capacité du contrôleur (mais pas des disques
eux-mêmes) à communiquer avec le bus sur lequel il est connecté.
Ca me paraît donc bizarre que IO_support soit à 0 pour hda et à 1 pour
hdb.
Si j'ai bien compris, ce paramètre ne sert qu'en mode PIO, donc pas
utile si le mode (Ultra)DMA est activé.
Je ne le savais pas.
Je me suis borné à faire un man et il n'en parle pas.
Peux-tu me donner ta source, ça m'intéresse ! :-)
IO_support est la capacité du contrôleur (mais pas des disques eux-mêmes) à communiquer avec le bus sur lequel il est connecté. Ca me paraît donc bizarre que IO_support soit à 0 pour hda et à 1 pour hdb. Si j'ai bien compris, ce paramètre ne sert qu'en mode PIO, donc pas
utile si le mode (Ultra)DMA est activé. Je ne le savais pas.
Je me suis borné à faire un man et il n'en parle pas. Peux-tu me donner ta source, ça m'intéresse ! :-)
@+
Frédéric BISSON
no_spam
On Sun, 29 Aug 2004 15:47:29 +0200, Annie D. wrote:
IO_support est la capacité du contrôleur (mais pas des disques eux-mêmes) à communiquer avec le bus sur lequel il est connecté. Ca me paraît donc bizarre que IO_support soit à 0 pour hda et à 1 pour hdb.
Si j'ai bien compris, ce paramètre ne sert qu'en mode PIO, donc pas utile si le mode (Ultra)DMA est activé.
Dans l'absolu, rien n'empêche d'utiliser la DMA en mode 8 bits. Ce sera deux fois moins rapide qu'en mode 16 bits... Mais comme c'est assez crétin, puisque tous les disques supportant la DMA supportent le mode 16 bits, je ne pense pas que Linux le fasse. Ca ne coute rien de le mettre à 1, mais je crois comme toi que ça ne changera rien.
On Sun, 29 Aug 2004 15:47:29 +0200, Annie D. wrote:
IO_support est la capacité du contrôleur (mais pas des disques
eux-mêmes) à communiquer avec le bus sur lequel il est connecté.
Ca me paraît donc bizarre que IO_support soit à 0 pour hda et à 1 pour
hdb.
Si j'ai bien compris, ce paramètre ne sert qu'en mode PIO, donc pas
utile si le mode (Ultra)DMA est activé.
Dans l'absolu, rien n'empêche d'utiliser la DMA en mode 8 bits. Ce sera
deux fois moins rapide qu'en mode 16 bits... Mais comme c'est assez
crétin, puisque tous les disques supportant la DMA supportent le mode 16
bits, je ne pense pas que Linux le fasse.
Ca ne coute rien de le mettre à 1, mais je crois comme toi que ça ne
changera rien.
IO_support est la capacité du contrôleur (mais pas des disques eux-mêmes) à communiquer avec le bus sur lequel il est connecté. Ca me paraît donc bizarre que IO_support soit à 0 pour hda et à 1 pour hdb.
Si j'ai bien compris, ce paramètre ne sert qu'en mode PIO, donc pas utile si le mode (Ultra)DMA est activé.
Dans l'absolu, rien n'empêche d'utiliser la DMA en mode 8 bits. Ce sera deux fois moins rapide qu'en mode 16 bits... Mais comme c'est assez crétin, puisque tous les disques supportant la DMA supportent le mode 16 bits, je ne pense pas que Linux le fasse. Ca ne coute rien de le mettre à 1, mais je crois comme toi que ça ne changera rien.
Annie D.
no_spam wrote:
Dans l'absolu, rien n'empêche d'utiliser la DMA en mode 8 bits.
Si, une raison toute simple l'empêche : les transferts DMA sur le bus ATA/IDE se font exclusivement par mots de 16 bits.
je ne pense pas que Linux le fasse.
Pas vu de mode 8 bits dans hdparm. Vous devez confondre avec autre chose.
Ca ne coute rien de le mettre à 1, mais je crois comme toi que ça ne changera rien.
J'ai testé avec un disque DMA2/PIO4 sur chipset Intel Triton VX :
débit PIO + 16-bit < PIO + 32-bit < DMA + 16 bits = DMA + 32-bit
Le problème, c'est que l'interaction entre le mode PIO et le bus PCI est une catastrophe à cause des caractéristiques de ce dernier qui limite le débit possible à une valeur bien inférieure à ce qu'ils permettent pris séparément. Sans compter l'énorme occupation CPU.
no_spam wrote:
Dans l'absolu, rien n'empêche d'utiliser la DMA en mode 8 bits.
Si, une raison toute simple l'empêche : les transferts DMA sur le bus
ATA/IDE se font exclusivement par mots de 16 bits.
je ne pense pas que Linux le fasse.
Pas vu de mode 8 bits dans hdparm. Vous devez confondre avec autre
chose.
Ca ne coute rien de le mettre à 1, mais je crois comme toi que ça ne
changera rien.
J'ai testé avec un disque DMA2/PIO4 sur chipset Intel Triton VX :
débit PIO + 16-bit < PIO + 32-bit < DMA + 16 bits = DMA + 32-bit
Le problème, c'est que l'interaction entre le mode PIO et le bus PCI est
une catastrophe à cause des caractéristiques de ce dernier qui limite le
débit possible à une valeur bien inférieure à ce qu'ils permettent pris
séparément. Sans compter l'énorme occupation CPU.
Dans l'absolu, rien n'empêche d'utiliser la DMA en mode 8 bits.
Si, une raison toute simple l'empêche : les transferts DMA sur le bus ATA/IDE se font exclusivement par mots de 16 bits.
je ne pense pas que Linux le fasse.
Pas vu de mode 8 bits dans hdparm. Vous devez confondre avec autre chose.
Ca ne coute rien de le mettre à 1, mais je crois comme toi que ça ne changera rien.
J'ai testé avec un disque DMA2/PIO4 sur chipset Intel Triton VX :
débit PIO + 16-bit < PIO + 32-bit < DMA + 16 bits = DMA + 32-bit
Le problème, c'est que l'interaction entre le mode PIO et le bus PCI est une catastrophe à cause des caractéristiques de ce dernier qui limite le débit possible à une valeur bien inférieure à ce qu'ils permettent pris séparément. Sans compter l'énorme occupation CPU.
no_spam
On Sun, 29 Aug 2004 23:02:06 +0200, Annie D. wrote:
no_spam wrote:
Dans l'absolu, rien n'empêche d'utiliser la DMA en mode 8 bits.
Si, une raison toute simple l'empêche : les transferts DMA sur le bus ATA/IDE se font exclusivement par mots de 16 bits.
Oui, je suis à la mase, c'est 16 ou 32 bits...
[...]
Ca ne coute rien de le mettre à 1, mais je crois comme toi que ça ne changera rien.
J'ai testé avec un disque DMA2/PIO4 sur chipset Intel Triton VX :
débit PIO + 16-bit < PIO + 32-bit < DMA + 16 bits = DMA + 32-bit
Le problème, c'est que l'interaction entre le mode PIO et le bus PCI est une catastrophe à cause des caractéristiques de ce dernier qui limite le débit possible à une valeur bien inférieure à ce qu'ils permettent pris séparément. Sans compter l'énorme occupation CPU.
En quoi les accès I/O du bus PCI sont ils plus lents que sans bus PCI ? Je pense que le problème majeur est l'occupation CPU. De plus, les accès DMA sont les mêmes que les accès sans DMA, la seule différence étant qu'ils se font en "background" et que le CPU peut faire autre chose en attendant la fin du transfert... Donc, le bus PCI n'explique pas, à mon avis, la lenteur du mode PIO.
On Sun, 29 Aug 2004 23:02:06 +0200, Annie D. wrote:
no_spam wrote:
Dans l'absolu, rien n'empêche d'utiliser la DMA en mode 8 bits.
Si, une raison toute simple l'empêche : les transferts DMA sur le bus
ATA/IDE se font exclusivement par mots de 16 bits.
Oui, je suis à la mase, c'est 16 ou 32 bits...
[...]
Ca ne coute rien de le mettre à 1, mais je crois comme toi que ça ne
changera rien.
J'ai testé avec un disque DMA2/PIO4 sur chipset Intel Triton VX :
débit PIO + 16-bit < PIO + 32-bit < DMA + 16 bits = DMA + 32-bit
Le problème, c'est que l'interaction entre le mode PIO et le bus PCI est
une catastrophe à cause des caractéristiques de ce dernier qui limite le
débit possible à une valeur bien inférieure à ce qu'ils permettent pris
séparément. Sans compter l'énorme occupation CPU.
En quoi les accès I/O du bus PCI sont ils plus lents que sans bus PCI ?
Je pense que le problème majeur est l'occupation CPU.
De plus, les accès DMA sont les mêmes que les accès sans DMA, la seule
différence étant qu'ils se font en "background" et que le CPU peut faire
autre chose en attendant la fin du transfert...
Donc, le bus PCI n'explique pas, à mon avis, la lenteur du mode PIO.
On Sun, 29 Aug 2004 23:02:06 +0200, Annie D. wrote:
no_spam wrote:
Dans l'absolu, rien n'empêche d'utiliser la DMA en mode 8 bits.
Si, une raison toute simple l'empêche : les transferts DMA sur le bus ATA/IDE se font exclusivement par mots de 16 bits.
Oui, je suis à la mase, c'est 16 ou 32 bits...
[...]
Ca ne coute rien de le mettre à 1, mais je crois comme toi que ça ne changera rien.
J'ai testé avec un disque DMA2/PIO4 sur chipset Intel Triton VX :
débit PIO + 16-bit < PIO + 32-bit < DMA + 16 bits = DMA + 32-bit
Le problème, c'est que l'interaction entre le mode PIO et le bus PCI est une catastrophe à cause des caractéristiques de ce dernier qui limite le débit possible à une valeur bien inférieure à ce qu'ils permettent pris séparément. Sans compter l'énorme occupation CPU.
En quoi les accès I/O du bus PCI sont ils plus lents que sans bus PCI ? Je pense que le problème majeur est l'occupation CPU. De plus, les accès DMA sont les mêmes que les accès sans DMA, la seule différence étant qu'ils se font en "background" et que le CPU peut faire autre chose en attendant la fin du transfert... Donc, le bus PCI n'explique pas, à mon avis, la lenteur du mode PIO.
