Piqûre de rappel....disques dur de vitesse différente sur même nappe

je réponds à Marco Rubin

Euhh, est tu sur qu'il ne s'agirait pas plutôt de "matos 94".... ;-)

Au départ c'était du windows 3.1 sur la machine...... :-)
ça marche encore.. mais bon........
@+

--
phil

Non, il y a un seul disque qui "cause" à la fois et s'il y a un ATA-6,
il cause à 100MB/s et si l'autre est un ATA-4, il cause à 33MB/s
lorsque c'est son tour, mais chacun utilise sa vitesse propre (il ne
sait pas faire autrement sauf settings a ATA-4 d'un ATA-6 par
exemple).

Ma foi, je retiens les propos d'un débat sur le sujet ayant eu lieu
sur f.c.m.o en juin 2002, je crois, au cours duquel Annie D. s'était
livré à quelques expériences intéressantes chez elle, et dont voici en
substance les conclusions - je la cite, c'est un peu long mais je pense
que ça vaut le coup d'être lu jusqu'au bout :

<quote>

[...] j'ai un très vieux disque 1Go sur lequel il y a un linux. Pour
tester j'ai monté ça :

CPU Intel Celeron 450MHz
256Mo SDRAM PC100
carte mère Abit BH6 (Intel 440BX) avec contrôleur Ultra-ATA33
disque dur Seagate 1Go PIO4/DMA2 (16Mo/s) en primary master (hda)
disque dur Quantum 3Go Ultra-ATA33 (33Mo/s) en primary slave (hdb)
lecteur CD-ROM 32x PIO4/DMA2 en secondary master (hdc)
noyau linux 2.2.19

Avec hdparm j'ai activé les options 32-bit (-c1), DMA (-d1) et
multisect=8 (-m8) pour retrouver les performances que j'avais
mesurées sous Windows avec HDTach.

Voici les résultats de débits en lecture avec hdparm -t :

1) L'un après l'autre :

- hda : 4Mo/s
- hdb : 12Mo/s
- hdc : 2Mo/s (soit environ 14x, que mesure CDSpeed sous Windows
en lisant le début du CD - à partir du centre, partie la moins
rapide)

Donc le contrôleur Ultra-ATA33 est loin d'être saturé, et le CPU non
plus.

2) hda et hdb en même temps (lancés depuis deux consoles) :

- hda : 4Mo/s
- hdb : 4Mo/s !!

3) hda ou hdb en même temps que hdc :

- mêmes résultats qu'en 1)

Bon, je place maintenant le disque rapide Ultra-ATA en secondary slave
(hdd) sur la nappe du lecteur CD.

1) L'un après l'autre : pareil que ci-dessus, nominal

2) hda en même temps que hdc ou hdd : pareil aussi, nominal

3) hdc et hdd en même temps:

- hdc : 2Mo/s
- hdd : 2Mo/s !!

Il est flagrant que _dans_ces_conditions_ le vieux disque lent ou le
lecteur CD écroule complètement les performances du disque rapide qui
est sur la même nappe IDE quand les deux débitent ensemble.
Curieusement, dans les deux cas il semble à ce moment que le disque
"rapide" s'aligne carrément sur le débit du lent. Un lien avec une
certaine légende urbaine que toi et moi dénoncions tantôt ?
Alors que si un périphérique débite en même temps qu'un autre qui est
sur l'autre nappe, les perfomances ne sont pas dégradées (à condition
que le DMA soit activé sur les deux, sinon il y a une légère chute). Ce
test permet de d'affirmer que ce n'est pas le CPU, la mémoire ou le bus
PCI qui sont la cause de la baisse de performance en utilisation
simultanée.

Voilà ma modeste contribution au schmilblic, elle vaut ce qu'elle vaut.
Je ne suis pas du tout experte en linux, donc je sais pas si le système
était réglé de façon optimale. Conseils bienvenus.

Prochainement : test de deux disques durs Ultra-ATA33 de performances
similaires (là il est un peu tard).

Voilà, c'est fait. La configuration est identique à part que j'ai
remplacé le lecteur CD par un disque WD 8G Ultra-ATA33:

disque WD 8Go secondary master (hdc)
disque Quantum 3Go secondary slave (hdd)

Maintenant les deux disques fonctionnent en Ultra-ATA mode 2.

1) Test de lecture 64Mo l'un après l'autre :

- hdc : 13,0Mo/s, conforme au bench HDTach sous Windows
- hdd : 12,3Mo/s, comme d'hab

J'ai rajouté une décimale pour une meilleure précision, car les valeurs
sont très proches. La somme des deux reste un poil en dessous de la
limite de l'interface l'Ultra-ATA33, qui d'après le test de lecture du
buffer de HDTach, est environ 27Mo/s. On ne devrait donc pas être gêné
par une saturation du débit de l'interface pour le test suivant en
utilisation simultanée.

2) Test de lecture 64Mo en même temps :

- hdc : 12,3Mo/s
- hdd : 12,3Mo/s

Encore une fois, le débit des deux périphériques est fixé par le plus
lent. Ici, ce n'est pas gênant car les deux disques ont des performances
proches.

J'ai un peu réfléchi pour trouver une hypothèse qui explique le
comportement que j'ai observé. Voici mes suppositions de départ:

1) Un périphérique occupe le bus IDE du début de la commande de lecture
à la fin du transfert des données.
2) Dans le disque, les données sont transférées du support physique vers
un tampon puis du tampon vers le contrôleur IDE. Les transferts sur le
bus se font à un débit supérieur au débit du support physique.
3) Le périphérique effectue une pré-lecture du support vers le buffer
(antémémoire) des secteurs qui suivent le secteur demandé.
3) Si le secteur demandé est déjà dans l'antémémoire, le buffer est
transféré sans lecture du support (normal)
4) Si le secteur n'est pas en antémémoire, le disque doit attendre
qu'elles y soient transférées depuis le support. Pendant ce temps, le
bus est indisponible pour l'autre disque.
5) Gestion de l'OS (ici linux) : il accorde la même priorité aux deux
périphériques. Quand il y a des demandes de lecture pour les deux, il
effectue une lecture sur l'un puis sur l'autre alternativement. Les
tailles de données lues en une requête sont les mêmes pour tous les
disques (le paramètre -a de hdparm, spécifiant le nombre de secteurs lus
par accès au filesystem, est global). C'est à mon avis une hypothèse
déterminante.

Avec tout ça, je trace des séquences de transferts simultanés sous forme
de chronogrammes, que je suis incapable de reproduire ici. Le résultat
de cette "simulation" est bien cohérent avec l'expérience : les
transferts depuis les deux périphériques se font à la vitesse du plus
lent. Cela ne prouve toutefois absolument pas que mes hypothèses sont
bonnes, mais qu'elle peuvent ne pas être mauvaises.

Poussant la réflexion, je me demande : que se passe-t-il si je donne une
priorité au périphérique le plus rapide ? Par exemple en lui faisant
transférer en une fois plus de données que le plus lent, dans le rapport
de leurs débits respectifs (par exemple, si l'un est trois fois plus
rapide que l'autre, je lui fais transférer trois fois plus de données à
chaque fois) ? Résultat de la simulation : les deux périphériques
débitent maintenant au maximum de leurs capacités respectives sans se
gêner l'un l'autre. De là à penser que la gestion de l'IDE par l'OS
pourrait avoir sa part de responsabilité dans les mauvaises performances
en accès simultané, il n'y a qu'un pas...

</quote>

Courageux le Biggs hein..!Ca fait au moins 20 fois que tu répètes la
même chose en 3 ans(peut-être 4)...Les légendes ont la vie dure..La
semaine prochaine ,il y aura surement une question sur la gestion de
la mémoire par Windows...:-))Un petit site pour la route..
http://www.echo-off.net

Malheureusement la réponse à la question de JCL ne figure pas sur mon
modeste site web :-( J'ai autrefois proposé à Annie D. de me donner un
coup de main pour rédiger un topo sur le thème du branchement des
périphériques de débits différents, mais elle n'a jamais répondu à mes
sollicitations ... C'est dommage, car comme tu le fais remarquer avec
une pertinente ironie, c'est une question qui réapparaît souvent sur les
news et il aurait été avantageux d'avoir une URL à fournir, proposant
une réponse claire et nette sur le sujet.

--
Biggs

[Suivi positionné vers fr.comp.sys.pc, les éventuelles réponses ne
seront normalement publiées que dans ce seul forum]

Marco Rubin wrote:

"fifi" wrote:

pas de DMA ni de UDMA pour cette vielle carte mère et vieux DDS.

C'est quoi, "DDS" ?

Alors je te prie de m'excuser d'avoir été un peu brusque.....car ca "roule"
en PIO 3 ou 4, et là effectivement c'est le "p'tit" qui dirige la vitesse.

Non, vous aviez raison. Dans la cas de "fifi", la limitation ne vient
pas du disque le plus lent mais du contrôleur hôte lui-même. Et
l'utilisation de modes PIO ou DMA ne change rien à l'affaire.

C'est quoi, "DDS" ?

HDD (Hard Disk)

--
Michel HOURDEAUX
http://www.hourdeaux.fr.st
http://www.uspo.fr.st

Inlèv' tin capiau, v'la un Chti qui passe

[Il est évident que je ne pouvais laisser passer ce fil sans intervenir,
je suis trop faible pour résister.]

Bd wrote:

Le Sun, 7 Mar 2004 02:10:07 +0100, "Biggs" écrivait:

Seulement dans le cas où les deux disques durs fonctionnent
simultanément ;

Comment sur un même Bus (les nappes de fils paralleles) pourrait-il y
avoir deux infos "simultanées"

Ce n'est bien sûr pas possible car les bus parallèles (PCI, ISA, ATA,
SCSI...) utilisent un multiplexage temporel (chaque source transmet tour
à tour). C'est aussi le cas de liaisons série à accès partagé (USB,
ethernet...) car cela évite d'avoir recours à la modulation/démodulation
de porteuses du multiplexage fréquentiel (ADSL, modem RTC).

Non, il y a un seul disque qui "cause" à la fois et s'il y a un ATA-6,
il cause à 100MB/s et si l'autre est un ATA-4, il cause à 33MB/s

C'est un abus de langage. Un débit est lié à un mode de transfert, pas
avec la version de l'ATA qui a introduit ce dernier. N'oublions pas que
celle-ci décrit également tous les débits inférieurs. La formulation
correcte est : le débit sur le bus est 100 Mo/s en mode Ultra DMA 5, et
33 Mo/s en mode Ultra DMA 2.

lorsque c'est son tour, mais chacun utilise sa vitesse propre (il ne
sait pas faire autrement sauf settings a ATA-4 d'un ATA-6 par
exemple).
Jamais de simultanéité de transfert (impossible par essence même d'une
transmission en //),

On s'en fiche pas mal que ce soit une transmission en parallèle. Ce qui
compte, c'est que ce soit une transmission en bande de base avec
multiplexage temporel.

même si d'un point de vue "humain", les disques
apparaissent comme travaillant quasi en même temps!

Et c'est réellement le cas. Un disque ne travaille pas seulement quand
il transfère des données sur le canal. Entre deux transferts extérieurs,
il est aussi occupé à transférer des données entre son cache et les
plateaux.

Biggs et vous avez tous les deux raison, mais vous vous placez chacun
d'un point de vue différent. Biggs, et les programmes de test de débit
moyen, se placent à une échelle "macroscopique" ou "système", celle du
transfert d'un nombre important de blocs qui nécessite l'exécution de
plusieurs commandes ATA. Vous vous placez à l'échelle "microscopique" ou
"bus" des transferts élémentaires sur le canal.

Si on demande simultanément à un système multitâche de lire/écrire deux
fichiers de taille respectable, il ne va pas lancer la lecture/écriture
d'un fichier, attendre sa fin puis lancer la lecture/écriture du second.
Il y a donc un intervalle de temps où les deux transferts sont en cours
simultanément du point de vue du système. Le débit moyen "visible" de
chacun des deux transferts sera, comme d'habitude, sa taille divisée par
sa durée.

La séquence pour transférer n blocs avec les deux périphériques
"simultanément" pourrait avoir l'allure suivante :

Périphérique 0 Périphérique 1
T1 bloc 1
T2 bloc 1
T3 bloc 2
T4 bloc 2
...
T2n-1 bloc n
T2n bloc n

Un seul transfert élémentaire à un moment donné, mais deux transferts
macroscopiques donnant lieu à une séquence de transferts élémentaires
alternativement pour l'un et pour l'autre.

Il se trouve que dans ce cas particulier, si les blocs sont de taille
identique, la théorie donne le résultat suivant, dans l'hypothèse où il
n'y a pas de saturation du canal (somme des taux d'occupation du canal <
1) : le débit effectif moyen des deux transferts est identique et égal
au débit soutenu (lié au débit média) du périphérique le plus lent. Dans
ce cas donc, la théorie rejoint l'expérience... et la légende.

Une excellente page sur le sujet, avec références aux normes:

Personnellement, je préfère les documents originaux du comité T13.

Merci pour toutes ces précisions, Annie. Tu es sûre que tu ne veux pas
qu'on publie tout ça sur un site web (le mien ou un autre de ton choix,
ça m'est égal), de manière à ce que ces informations - et celles que tu
as fournies par le passé, tout aussi intéressantes - soient facilement
accessibles à tous ?

[Suivi positionné vers fr.comp.sys.pc, les éventuelles réponses ne
seront normalement publiées que dans ce seul forum]

Marco Rubin wrote:

C'est vraiment incroyable avec quelle ténacité se maintiennent les fables,
comme celle que le DD le plus lent dirige la vitesse de tous les composants
sur une même nappe.

La raison est toute simple : il y a un fond de vérité là-dessous (voir
mon autre réponse), mais il faut bien gratter pour l'atteindre.

(Rien à voir avec le fameux maillon faible qui détermine la force d'une
chaîne)

Celui-ci a aussi sont importance, mais dans le cas qui nous occupe les
deux périphériques ATA d'un même canal ne font jamais partie de la même
chaîne de transfert de données. Du moins, pas directement dans le cas
d'une copie de l'un vers l'autre.

Ceci était valable pour les très anciens DD qui tournaient en mode "PIO".

Avez-vous des éléments pour étayer cette affirmation ?

En DMA tu peux brancher 2 périfs sur la même nappe, le DD lent restera lent,
et le DD rapide restera rapide. (Idem pour CD-Rom, graveur etc.)

Mes mesures indiquent la même chose en PIO.

La spécification DMA inclus que si un périf est en lecture/écriture, l'autre
est en attente, c'est la seule restriction, qui n'a rien du tout à voir avec
la vitesse nominale de chaque composant.

La gestion de l'état actif/inactif est spécifiée au niveau des commandes
ATA. Ça n'a rien à voir avec la spécification des modes ATA DMA qui sont
des protocoles de transfert des données. Le transfert des données n'est
qu'une partie de l'exécution d'une commande ATA.

Donc si tu copie un fichier d'un disque à l'autre et que DD1 met 10 secondes
pour lire le fichier et DD2 met 12 secondes pour l'écrire le temps total ne
sera pas de 12 sec (S'il faisaient leur boulot en simultané), mais plutôt
grossomodo 22 sec puisque il ne peuvent pas bosser en même temps.

Vous prenez un cas particulier car les transferts sur les deux
périphériques sont liés : on doit lire des données sur le premier avant
de pouvoir les écrire sur le second. dans le cas de transferts
indépendants, ce n'est plus nécessairement vrai.

-Il est toutefois recommandé d'activer dans les propriétés du DD l'option
DMA

Oui, car d'une part l'utilisation des modes PIO en accès I/O sur un bus
PCI est désastreuse, et d'autre part le débit du mode PIO le plus rapide
est de 16,6 Mo/s, ce qui est insuffisant pour les disques récents.

Biggs <utilisez_repondre_a@nosp.am> wrote:

Merci pour toutes ces précisions, Annie. Tu es sûre que tu ne veux pas
qu'on publie tout ça sur un site web (le mien ou un autre de ton choix,
ça m'est égal), de manière à ce que ces informations - et celles que tu
as fournies par le passé, tout aussi intéressantes - soient facilement
accessibles à tous ?

Je seconde la proposition :=))

--
Je cherche comme cherche celui qui veut trouver,
et je trouve comme trouve celui qui a cherché. :o)

Bonjour Annie,

Le Sun, 07 Mar 2004 16:01:49 +0100, "Annie D." <annie.demur@free.fr>
écrivait:

[Il est évident que je ne pouvais laisser passer ce fil sans intervenir,
je suis trop faible pour résister.]

Mais non, mais non, le sexe "faible", c'est l'homme, c'est
scientifiquement et génétiquement prouvé! 8-)

Seulement dans le cas où les deux disques durs fonctionnent
simultanément ;

Comment sur un même Bus (les nappes de fils paralleles) pourrait-il y
avoir deux infos "simultanées"

Ce n'est bien sûr pas possible car les bus parallèles (PCI, ISA, ATA,
SCSI...) utilisent un multiplexage temporel (chaque source transmet tour
à tour).

On est bien d'accord.

C'est un abus de langage. Un débit est lié à un mode de transfert, pas
avec la version de l'ATA qui a introduit ce dernier. N'oublions pas que
celle-ci décrit également tous les débits inférieurs.
La formulation correcte est : le débit sur le bus est 100 Mo/s en
mode Ultra DMA 5, et 33 Mo/s en mode Ultra DMA 2.

Oui, d'où la raison de pouvoir utiliser ATA-6 par exemple pour le
100MB/s puisque l'ATA-5 et l'ATA4 ne peuvent prétendre utiliser le
"plus haut" des débits...
De la même manière, quand on dit d'un disque qu'il est ATA-6, cela
veut dire qu'il est aussi ATA-5, 4 et mode PIO mais on quantifie
toujours par le plus, qui pouvant le plus pouvant le moins.

même si d'un point de vue "humain", les disques
apparaissent comme travaillant quasi en même temps!

Et c'est réellement le cas.

Au niveau "systeme" d'un transfert de fichier, il y a bien sur
simultanéité, mais à un moment donné, un seul disque transmet de
l'information, ce qui explique bien pourquoi chacun le fait à sa
vitesse (comment saurait il qu'il est "acoquiné" avec un autre type de
dsique et en quoi cela le concernerait il ?

Un disque ne travaille pas seulement quand
il transfère des données sur le canal. Entre deux transferts extérieurs,
il est aussi occupé à transférer des données entre son cache et les
plateaux.

Effcetivement, mais il pourrait faire la lessive en plus que ca n'y
changerait rien, le transfert exterieur (le seul utile) est fait à une
vitesse donnée, vitesse intrinséque au type de disque(on parle
toujours d'utiliser un disque au max de ses possibilités sinon, le
débat n'a plus aucun sens)

Biggs et vous avez tous les deux raison, mais vous vous placez chacun
d'un point de vue différent. Biggs, et les programmes de test de débit
moyen, se placent à une échelle "macroscopique" ou "système", celle du
transfert d'un nombre important de blocs qui nécessite l'exécution de
plusieurs commandes ATA. Vous vous placez à l'échelle "microscopique" ou
"bus" des transferts élémentaires sur le canal.

Justement, l'échelle macro n'est que la somme des actions
microscopiques. Il est évident qu'un disque transférant à 33Mo/s et un
disque à 100Mo/s vont travailler de concert, mais CHACUN à son TOUR.
Donc le temps moyen ne vas pas être plus impacté que la somme des
temps de chaque transfert.

Or, et c'est ce qui m'a fait réagir, le post de Biggs disait en
substance: Si les deux disques sont utilisés simultanément, alors, le
disque le plus rapide va voir sa vitesse de transfert impacté, et là,
je suis désolé, mais pour moi, c'est techniquement faux.

Si on demande simultanément à un système multitâche de lire/écrire deux
fichiers de taille respectable, il ne va pas lancer la lecture/écriture
d'un fichier, attendre sa fin puis lancer la lecture/écriture du second.

Evidemment, mais ca ne change rien au probleme.

Il y a donc un intervalle de temps où les deux transferts sont en cours
simultanément du point de vue du système.

Tout à fait d'accord.

Le débit moyen "visible" de chacun des deux transferts sera,

J'aurai dit de "l'ensemble des deux transferts" puisqu'on est sur la
sémantique...

comme d'habitude, sa taille divisée par sa durée.
La séquence pour transférer n blocs avec les deux périphériques
"simultanément" pourrait avoir l'allure suivante :

Périphérique 0 Périphérique 1
T1 bloc 1
T2 bloc 1
T3 bloc 2
T4 bloc 2
...
T2n-1 bloc n
T2n bloc n

Un seul transfert élémentaire à un moment donné, mais deux transferts
macroscopiques donnant lieu à une séquence de transferts élémentaires
alternativement pour l'un et pour l'autre.

Il se trouve que dans ce cas particulier, si les blocs sont de taille
identique, la théorie donne le résultat suivant, dans l'hypothèse où il
n'y a pas de saturation du canal (somme des taux d'occupation du canal <
1) : le débit effectif moyen des deux transferts est identique et égal
au débit soutenu (lié au débit média) du périphérique le plus lent. Dans
ce cas donc, la théorie rejoint l'expérience... et la légende.

????
Allons jusqu'au bout du raisonnement et prenons un exemple sur n
blocs de taille équivalente, l'un transféré en 33Mo/s, l'autre en
100Mo/spar exemple.

Premier cas: le cas décrit ci-dessus.
Temps de transfert = somme des temps de chaque transfert,d'accord ?
Temps de transfert d'un bloc du periphérique 100Mo/s = 1 unité
Temps de transfert d'un bloc du périphérique 33Mo/s = 3 unités,
Toujours d'accord ?

Somme = 1+3+1+3 ...+1+3= 40 unités.

Second cas: on envoie d'abord le transfert complet depuis le 100Mo/s
puis à la suite, la même chose depuis le 33 Mo/s.

Somme = 10 + 30 = 40 unités.

Pourquoi et comment y aurait il une différence ?

Bine sur, vu de l'utilisateur à la fin des deux transferts, quel que
soit le cas, le débit moyen est toujours de 50Mo/s mais il est évident
que le 33Mo/s n'est pourtant pas devenu plus véloce parce qu'il était
connecté en parallele à un 100Mo/s!

Et sur des transferts longs, on sait tous que les 100 Mo/s théoriques
sont assez éloignés de la pratique pour des tas de raisons, mais le
raisonnement reste le même dans le monde réél.

Personnellement, je préfère les documents originaux du comité T13.

Marrant, ca ne parle que de ATA-x 8-)

Au fait, tu as commencé un "1) : le débit effectif moyen ..." et je ne
vois pas de 2) ?

Cela dit, ca ne m'empêche pas d'utiliser des tas de choses dans la vie
sans savoir comment ils fonctionnent réellement, comme la plupart
8-)), et le but n'est pas "d'époustoufler" l'assistance par la
grandeur de mon savoir (mes lacunes augmentent plus vite, hélas),
Biggs le sait bien et c''est pourquoi je me suis permis cette remarque
mais dans ce cas précis, je ne vois pas comment on peut défendre une
autre réalité...

Cordialement,
--
Bernard
(NB: mon adresse de retour est valide. Ne rien y changer)
(NB: This is a valid Reply-To. Do not remove anything)
--