OVH Cloud OVH Cloud

UDMA 133 ou 33 ?

32 réponses
Avatar
Kerker
Bonjour,
proc : Athlon XP 2500+
CM : Gigabyte GA-7N400PRO2

j'ai acheté sur cette configuration un DD Maxtor
UDMA 133 de 40 Go.
Or le logiciel AIDA me dit pour celui-ci :
mode de transfert UDMA maximum : ATA-133
mode de transfert UDMA actif: ATA-33
Est-ce à dire que ce DD ne fonctionne qu'à 33 Mo/s ?
Comment s'assurer autrement qu'il est bien utilisé comme
un UDMA 133 ? Je n'ai rien vu dans ce sens dans le bios
Award.
Le fait qu'il soit associé sur IDE 1 à un autre DD UDMA 33
peut-il jouer ??
Merci pour tout tuyau,
Kerim

10 réponses

1 2 3 4
Avatar
Annie D.
MAC GYVER wrote:

"Alex" a écrit:
"MAC GYVER" wrote:

A force de lire tout et son contraire, je crois avoir compris:
1 qu'un périf lent ne ralenti pas un autre plus rapide sur la même
nappe


Voila.



A condition qu'on ne s'en serve pas en même temps. Sinon son activité
peut ralentir l'autre. Ceci est uniquement dû à l'inévitable partage
temporel de l'accès au canal.

2 Que le contrôleur IDE n'est pas un chipset sur le carte mère mais
sur le disque dur.


Ah non. Le chipset il est bien sur la carte mere - bien qu'une partie de
la logique soit quand meme sur le disque dur



En fait il y a confusion d'origine historique. A l'origine, le
contrôleur du disque était sur une carte séparée. Avec l'IDE (futur
ATA), le contrôleur a été intégré au disque, et l'interface de
raccordement du système hôte réduite à sa plus simple expression :
l'interface IDE du PC était à peu de choses près un sous-ensemble des
signaux du bus ISA bufferisés en ajoutant un peu de logique
combinatoire. Mais avec l'arrivée des bus système rapides (VLB, PCI),
des contrôleurs hôtes plus évolués ont fait leur apparition, intégrant
en particulier un mécanisme de busmaster ("DMA"), méritant pleinement
l'appellation de "contrôleur". Donc il y a bien deux contrôleurs
distincts dans l'interface ATA actuelle : le contrôleur hôte intégré au
système et le contrôleur embarqué du disque.

Ok, parceque j'avais compris sur un site que le DD en master était
prioritaire sur le slave, avec système de requète comme les IRQ.


Non. Il n'y a pas de notion de priorité entre périphériques ATA, et seul
le périphérique actif à un moment donné est autorisé à émettre une IRQ.
L'autre est inactif sur le bus, il n'a aucune raison de vouloir émettre
une IRQ.

Donc cela devait être peut être pour l'ATA 2..... ?


Au contraire, c'est comme ça au moins depuis l'ATA-2. N'ayant pas lu de
spécification antérieure, je ne peux rien affirmer concernant la manière
dont ça se passait avant.



Avatar
Kna
"MAC GYVER" écrivait
news:bvb7va$r61$:

A force de lire tout et son contraire, je crois avoir compris:
3 Que le positionement master et slave ne servent plus à rien.


Si j'ai bien moi aussi compris ce qu'a expliqué Annie, ça sert à quelque
chose : à expliquer à chacun des deux périphs "hé mec, t'es pas tout seul",
mais sans qu'il y en ait un mieux considéré que l'autre ?

Bizarre tout de même que cette dénomination master / slave n'ait pas été
mise à jour, genre DS (Drive Single, qu'on trouvait sur certains disques
anciens pourtant, surtout Conner si je me souviens bien) et DD (Dual Drive)
par exemple.
Peut-être pour ne pas bouleverser les habitudes établies ?

Kna.
--
Erreur fatale : votre disque maître tente de ligoter le disque esclave
avec la nappe IDE !

Avatar
Annie D.
Kna wrote:

Si j'ai bien moi aussi compris ce qu'a expliqué Annie, ça sert à quelque
chose : à expliquer à chacun des deux périphs "hé mec, t'es pas tout seul",


Pas tout à fait. Si on met de côté la séquence de démarrage des
péripériques qui est légèrement asymétrique, la différence entre master
et slave se traduit simplement et uniquement en terme d'adressage :
- master = adresse 0
- slave = adresse 1

Quand le contrôleur hôte veut envoyer une commande à un des deux
périphériques d'un canal, il écrit un mot de commande contenant
l'adresse 0 ou 1 du périphérique en question sur le bus de données du
canal. Les deux périphérique lisent ce mot, et seul celui dont l'adresse
correspond réagit pour exécuter la commande. L'autre reste inactif.

Bizarre tout de même que cette dénomination master / slave n'ait pas été
mise à jour


Elle l'a été. Depuis la spécification ATA-2, master est devenu "device
0" (périphérique 0) et "slave" est devenu "device 1" (périphérique 1).
Pour mémoire, on en est déjà à ATA-6, la version suivante ATA-7 étant en
développement par le comité T13 (http://www.t13.org).

Peut-être pour ne pas bouleverser les habitudes établies ?


Je pense.

Avatar
Annie D.
joel wrote:

http://www.pcguide.com/ref/hdd/if/ide/conf.htm


Je suis allée voir et j'ai été agréablement impressionnée par la qualité
des explications de ce site. [Il y a même une page consacrée à un de mes
dadas (certains auront peut-être remarqué), la question des préfixes à
valeur binaire en usage en informatique :

http://www.pcguide.com/intro/fun/bindec.htm

Une petite confusion s'est néamoins glissée au sujet du débit en rafale
du bus PCI : contrairement à ce qui est soutenu, ici le "M" dans
Moctets/s veut bien dire 1000000 (méga) comme dans toutes les mesures de
débit, et non pas 1048576 (mébi). La valeur de 132 Moctets/s (et non pas
133,3 car la fréquence nominale de l'horloge du bus est 33 MHz, pas
33,3) est par conséquent correcte.]

Pour en revenir à l'IDE/ATA, j'ai tout de même relevé une affirmation
inexacte dans le cas général, qui a dû être tirée de l'observation de
cas particuliers.

A la fin de la page sur l'indépendance des timings master/slave :

http://www.pcguide.com/ref/hdd/if/ide/confTiming-c.html

il est écrit qu'il est impossible de faire cohabiter les modes PIO et
DMA (ou Ultra DMA) sur un même canal. Cette affirmation pour laquelle je
n'ai trouvé aucun fondement technique dans la spécification ATA est
battue en brèche par l'expérience. Il suffit de prendre n'importe quel
Windows ou Linux assez récent, et de vérifier qu'on peut configurer
chaque périphérique d'un canal en PIO ou DMA indépendamment et que tout
fonctionne.

D'autre part, dans la page sur les configurations :

http://www.pcguide.com/ref/hdd/if/ide/confTiming-c.html

les arguments autres que la différence de débit invoqués contre
l'association d'un disque dur ATA et d'un périphériqe ATAPI (différence
de protocole, voire incompatibilité avec les modes DMA) me semblent
fallacieux. En effet les commandes sont différentes, mais les protocoles
de transferts de données (PIO, DMA, Ultra DMA) sont identiques en ATA et
ATAPI.

Avatar
MAC GYVER
"Annie D." a écrit dans le message news:

MAC GYVER wrote:

"Alex" a écrit:
"MAC GYVER" wrote:

A force de lire tout et son contraire, je crois avoir compris:
1 qu'un périf lent ne ralenti pas un autre plus rapide sur la même
nappe


Voila.



A condition qu'on ne s'en serve pas en même temps. Sinon son activité
peut ralentir l'autre. Ceci est uniquement dû à l'inévitable partage
temporel de l'accès au canal.

2 Que le contrôleur IDE n'est pas un chipset sur le carte mère mais
sur le disque dur.


Ah non. Le chipset il est bien sur la carte mere - bien qu'une partie
de



la logique soit quand meme sur le disque dur



En fait il y a confusion d'origine historique. A l'origine, le
contrôleur du disque était sur une carte séparée. Avec l'IDE (futur
ATA), le contrôleur a été intégré au disque, et l'interface de
raccordement du système hôte réduite à sa plus simple expression :
l'interface IDE du PC était à peu de choses près un sous-ensemble des
signaux du bus ISA bufferisés en ajoutant un peu de logique
combinatoire. Mais avec l'arrivée des bus système rapides (VLB, PCI),
des contrôleurs hôtes plus évolués ont fait leur apparition, intégrant
en particulier un mécanisme de busmaster ("DMA"), méritant pleinement
l'appellation de "contrôleur". Donc il y a bien deux contrôleurs
distincts dans l'interface ATA actuelle : le contrôleur hôte intégré au
système et le contrôleur embarqué du disque.

Ok, parceque j'avais compris sur un site que le DD en master était
prioritaire sur le slave, avec système de requète comme les IRQ.


Non. Il n'y a pas de notion de priorité entre périphériques ATA, et seul
le périphérique actif à un moment donné est autorisé à émettre une IRQ.
L'autre est inactif sur le bus, il n'a aucune raison de vouloir émettre
une IRQ.

Donc cela devait être peut être pour l'ATA 2..... ?


Au contraire, c'est comme ça au moins depuis l'ATA-2. N'ayant pas lu de
spécification antérieure, je ne peux rien affirmer concernant la manière
dont ça se passait avant.


Ok, merci pour ces explications.




Avatar
MAC GYVER
"Kna" a écrit dans le message news:
bvbsep$l1$
"MAC GYVER" écrivait
news:bvb7va$r61$:

A force de lire tout et son contraire, je crois avoir compris:
3 Que le positionement master et slave ne servent plus à rien.


Si j'ai bien moi aussi compris ce qu'a expliqué Annie, ça sert à quelque
chose : à expliquer à chacun des deux périphs "hé mec, t'es pas tout
seul",

mais sans qu'il y en ait un mieux considéré que l'autre ?

Bizarre tout de même que cette dénomination master / slave n'ait pas été
mise à jour, genre DS (Drive Single, qu'on trouvait sur certains disques
anciens pourtant, surtout Conner si je me souviens bien) et DD (Dual
Drive)

par exemple.
Peut-être pour ne pas bouleverser les habitudes établies ?


Ok merci.

Par contre le DD master est vu comme HD0 dans le bios et le dd slave comme
HD1 c'est bien ça ?
a+


Avatar
Kna
"Annie D." écrivait
news::

Quand le contrôleur hôte veut envoyer une commande à un des deux
périphériques d'un canal, il écrit un mot de commande contenant
l'adresse 0 ou 1 du périphérique en question sur le bus de données du
canal. Les deux périphérique lisent ce mot, et seul celui dont
l'adresse correspond réagit pour exécuter la commande. L'autre reste
inactif.


Sans vouloir rentrer dans les détails (il y aurait du boulot, j'en ignore
la plupart), on retrouverait donc une notion d'ID de périphérique, comme en
SCSI ?
Ou avec moins de rapport, le même principe qu'en ethernet (non commuté),
toutes les machines reçoivent le même paquet de données, seule l'intéressée
qui trouve son identifiant dans l'en-tête du paquet y réagit ?

Bizarre tout de même que cette dénomination master / slave n'ait pas
été mise à jour
Elle l'a été. Depuis la spécification ATA-2, master est devenu "device

0" (périphérique 0) et "slave" est devenu "device 1" (périphérique 1).
Peut-être pour ne pas bouleverser les habitudes établies ?
Je pense.



Jusqu'à maintenant, je n'ai toujours vu que les classiques "MA/SL/CS"
concernant les cavaliers de config sur les périphériques IDE, les habitudes
sont donc bien préservées :)

Merci pour ces précisions,
Kna
--
Erreur fatale : impossible de booter sur "GENERIC IDE DISK TYPE 47",
fonction AUTORUN non prise en charge pour ce type de périphérique !


Avatar
Kna
"Annie D." écrivait news::

[Il y a même une page consacrée à un de mes
dadas (certains auront peut-être remarqué), la question des préfixes à
valeur binaire en usage en informatique :
http://www.pcguide.com/intro/fun/bindec.htm


Nom de Zeus, nous voilà biens !
Ca va être simple à expliquer aux clients ça tiens :
- Ha mais non Monsieur, vous parlez de gigas, et moi de gibis..
- De gibis ?? Vous me prenez pour un shadok ?!

Kna ;)
--
Erreur fatale : échec réseau, masque de sous-réseau primaire moisi à
cause de la fuite d'eau dans les toilettes. Gardez votre ordinateur
éteint pendant 9 jours pour éviter tout dommage.

Avatar
Le Moustique
Jusqu'à maintenant, je n'ai toujours vu que les classiques "MA/SL/CS"
concernant les cavaliers de config sur les périphériques IDE, les habitudes
sont donc bien préservées :)


J'ai pu voir sur certains disques IDE une position supplémentaire
"Master with Slave", la position MA étant notée "Master Single"...
ainsi qu'une position "Master with non-ATA slave" sur des vieux disques
Seagate.

--
/)
-:oO== Guillaume
)
Je nettoyais mon clavier, et le coup est parti tout seul.

Avatar
Annie D.
Kna wrote:

on retrouverait donc une notion d'ID de périphérique, comme en SCSI ?
Ou avec moins de rapport, le même principe qu'en ethernet (non commuté),
toutes les machines reçoivent le même paquet de données, seule l'intéressée
qui trouve son identifiant dans l'en-tête du paquet y réagit ?


Même chose avec les bus ISA, PCI, USB... pour ne citer que les plus
connus. C'est la notion générale d'adresse ou d'identificateur de
source/destination qui permet de définir avec qui on communique sur un
bus partagé. Notez qu'il existe des bus partagés qui fonctionnent
différemment, par exemple des bus employés en aéronautique (ARINC) ou en
automobile (CAN) qui sont basés sur la notion d'identificateur de
contenu plutôt que de source ou de destination.

Depuis la spécification ATA-2, master est devenu "device
0" (périphérique 0) et "slave" est devenu "device 1" (périphérique 1).


Jusqu'à maintenant, je n'ai toujours vu que les classiques "MA/SL/CS"
concernant les cavaliers de config sur les périphériques IDE


Attention, il ne faut pas confondre. La spécification n'impose rien
concernant les noms des positions des cavaliers de configuration.
D'ailleurs elle n'impose même pas que ce soient des cavaliers, ni même
qu'il y en ait. Si un périphérique donné comporte 3 configurations
"master", "slave" et "cable select", on peut s'attendre à ce que :
- en configuration "master", il se comporte en Device 0 (tel que défini
par la spéc. ATA)
- en configuration "slave", il se comporte en Device 1
- en configuration "cable select", il se comporte en Device 0 ou 1 selon
sa position sur la nappe.


1 2 3 4