On Mon, 23 Aug 2004 19:39:48 +0200, Remy Moulin wrote:
L'histoire, c'est plutôt qu'au début, avec les OS monotaches (style DOS), on en avait rien a faire si un accès au disque "prenait" 100% du temps CPU, de toutes façon, tout programme se devait d'attendre que les opérations disque se terminent avant de passer à autre chose (d'où le mono-tâche). Donc c'est le CPU qui, à chaque interruption, copiait les données du contrôlleur (sur ses adresses d'Entrée/Sortie (I/O) ) vers/depuis la RAM. En plus, le CPU étant l'élément le plus rapide, c'etait ce qui permettait de s'acquitter de la tâche le plus rapidement. Lecture IO par programmation, "Programmed Input/Output" = PIO.
Non, dans les deux cas, que ce soit en PIO ou en DMA, c'est le "host" qui est censé gerer la copie. Dans le cas d'un transfert en mode PIO, un signal est envoyé au début du transfert (et le "host" récupère les données au fur et à mesure de leur arrivée) alors qu'en mode DMA, c'est à la fin de l'execution de la commande que le signal est envoyé.
Maintenant, sur les PC modernes, il y a un controlleur evolué qui est là comme intermediaire entre les disques et le processeur. Ces controlleurs vont jusqu'à faire du bus-mastering pour que les données soient directement transférées en mémoire sans que le CPU ait quoique ce soit à faire. Pour les PC plus vieux (pseudo controlleur branché sur le bus AT), c'est le CPU qui était le "host" et l'utilisation du mode DMA (où le CPU n'était pas bloqué pendant le transert de données) permetait d'éviter de gacher du temps CPU.
François
On Mon, 23 Aug 2004 19:39:48 +0200, Remy Moulin wrote:
L'histoire, c'est plutôt qu'au début, avec les OS monotaches (style DOS), on
en avait rien a faire si un accès au disque "prenait" 100% du temps CPU, de
toutes façon, tout programme se devait d'attendre que les opérations disque
se terminent avant de passer à autre chose (d'où le mono-tâche). Donc c'est
le CPU qui, à chaque interruption, copiait les données du contrôlleur (sur
ses adresses d'Entrée/Sortie (I/O) ) vers/depuis la RAM. En plus, le CPU
étant l'élément le plus rapide, c'etait ce qui permettait de s'acquitter de
la tâche le plus rapidement. Lecture IO par programmation, "Programmed
Input/Output" = PIO.
Non, dans les deux cas, que ce soit en PIO ou en DMA, c'est le "host"
qui est censé gerer la copie. Dans le cas d'un transfert en mode PIO, un
signal est envoyé au début du transfert (et le "host" récupère les
données au fur et à mesure de leur arrivée) alors qu'en mode DMA, c'est
à la fin de l'execution de la commande que le signal est envoyé.
Maintenant, sur les PC modernes, il y a un controlleur evolué qui est là
comme intermediaire entre les disques et le processeur. Ces controlleurs
vont jusqu'à faire du bus-mastering pour que les données soient
directement transférées en mémoire sans que le CPU ait quoique ce soit
à faire. Pour les PC plus vieux (pseudo controlleur branché sur le bus
AT), c'est le CPU qui était le "host" et l'utilisation du mode DMA (où
le CPU n'était pas bloqué pendant le transert de données) permetait
d'éviter de gacher du temps CPU.
On Mon, 23 Aug 2004 19:39:48 +0200, Remy Moulin wrote:
L'histoire, c'est plutôt qu'au début, avec les OS monotaches (style DOS), on en avait rien a faire si un accès au disque "prenait" 100% du temps CPU, de toutes façon, tout programme se devait d'attendre que les opérations disque se terminent avant de passer à autre chose (d'où le mono-tâche). Donc c'est le CPU qui, à chaque interruption, copiait les données du contrôlleur (sur ses adresses d'Entrée/Sortie (I/O) ) vers/depuis la RAM. En plus, le CPU étant l'élément le plus rapide, c'etait ce qui permettait de s'acquitter de la tâche le plus rapidement. Lecture IO par programmation, "Programmed Input/Output" = PIO.
Non, dans les deux cas, que ce soit en PIO ou en DMA, c'est le "host" qui est censé gerer la copie. Dans le cas d'un transfert en mode PIO, un signal est envoyé au début du transfert (et le "host" récupère les données au fur et à mesure de leur arrivée) alors qu'en mode DMA, c'est à la fin de l'execution de la commande que le signal est envoyé.
Maintenant, sur les PC modernes, il y a un controlleur evolué qui est là comme intermediaire entre les disques et le processeur. Ces controlleurs vont jusqu'à faire du bus-mastering pour que les données soient directement transférées en mémoire sans que le CPU ait quoique ce soit à faire. Pour les PC plus vieux (pseudo controlleur branché sur le bus AT), c'est le CPU qui était le "host" et l'utilisation du mode DMA (où le CPU n'était pas bloqué pendant le transert de données) permetait d'éviter de gacher du temps CPU.
François
Remy Moulin
Francois Petillon wrote:
Non, dans les deux cas, que ce soit en PIO ou en DMA, c'est le "host" qui est censé gerer la copie. Dans le cas d'un transfert en mode PIO, un signal est envoyé au début du transfert (et le "host" récupère les données au fur et à mesure de leur arrivée) alors qu'en mode DMA, c'est à la fin de l'execution de la commande que le signal est envoyé.
Bonjour,
Pardon pour les manquements, mais c'est vrai que j'ai "sauté" une étape en passant directement d'un 486 "PIO" à un K6-III avec contrôlleur UDMA Bus Master...
Y a t'il un site qui explique les détails des transferts DMA en Bus Master et sans Bus Master ? C'est pour culture personnelle :-)
Maintenant, sur les PC modernes, il y a un controlleur evolué qui est là comme intermediaire entre les disques et le processeur. Ces controlleurs vont jusqu'à faire du bus-mastering pour que les données soient directement transférées en mémoire sans que le CPU ait quoique ce soit à faire.
C'est dans ce sens que je pensait que tout contrôlleur DMA (intégré à la carte mère ou présent dans un contrôlleur disque) devait fonctionner... Visiblement, j'ai tout faux...
Pour les PC plus vieux (pseudo controlleur branché sur le bus AT), c'est le CPU qui était le "host" et l'utilisation du mode DMA (où le CPU n'était pas bloqué pendant le transert de données) permetait d'éviter de gacher du temps CPU.
Il me semblait que la RAM ne pouvait servir qu'un "maître" à la fois... Que lors d'un transfert DMA, le CPU était gelé les quelques petits cycles nécessaires à la lecture/écriture RAM...
Bah, on a jamais fini de découvrir comment fonctionnent ces bêtes-là !
-- Herm
Francois Petillon wrote:
Non, dans les deux cas, que ce soit en PIO ou en DMA, c'est le "host"
qui est censé gerer la copie. Dans le cas d'un transfert en mode PIO,
un signal est envoyé au début du transfert (et le "host" récupère les
données au fur et à mesure de leur arrivée) alors qu'en mode DMA,
c'est à la fin de l'execution de la commande que le signal est envoyé.
Bonjour,
Pardon pour les manquements, mais c'est vrai que j'ai "sauté" une étape en
passant directement d'un 486 "PIO" à un K6-III avec contrôlleur UDMA Bus
Master...
Y a t'il un site qui explique les détails des transferts DMA en Bus Master
et sans Bus Master ? C'est pour culture personnelle :-)
Maintenant, sur les PC modernes, il y a un controlleur evolué qui est
là comme intermediaire entre les disques et le processeur. Ces
controlleurs vont jusqu'à faire du bus-mastering pour que les données
soient directement transférées en mémoire sans que le CPU ait quoique
ce soit à faire.
C'est dans ce sens que je pensait que tout contrôlleur DMA (intégré à la
carte mère ou présent dans un contrôlleur disque) devait fonctionner...
Visiblement, j'ai tout faux...
Pour les PC plus vieux (pseudo controlleur branché
sur le bus AT), c'est le CPU qui était le "host" et l'utilisation du
mode DMA (où le CPU n'était pas bloqué pendant le transert de
données) permetait d'éviter de gacher du temps CPU.
Il me semblait que la RAM ne pouvait servir qu'un "maître" à la fois... Que
lors d'un transfert DMA, le CPU était gelé les quelques petits cycles
nécessaires à la lecture/écriture RAM...
Bah, on a jamais fini de découvrir comment fonctionnent ces bêtes-là !
Non, dans les deux cas, que ce soit en PIO ou en DMA, c'est le "host" qui est censé gerer la copie. Dans le cas d'un transfert en mode PIO, un signal est envoyé au début du transfert (et le "host" récupère les données au fur et à mesure de leur arrivée) alors qu'en mode DMA, c'est à la fin de l'execution de la commande que le signal est envoyé.
Bonjour,
Pardon pour les manquements, mais c'est vrai que j'ai "sauté" une étape en passant directement d'un 486 "PIO" à un K6-III avec contrôlleur UDMA Bus Master...
Y a t'il un site qui explique les détails des transferts DMA en Bus Master et sans Bus Master ? C'est pour culture personnelle :-)
Maintenant, sur les PC modernes, il y a un controlleur evolué qui est là comme intermediaire entre les disques et le processeur. Ces controlleurs vont jusqu'à faire du bus-mastering pour que les données soient directement transférées en mémoire sans que le CPU ait quoique ce soit à faire.
C'est dans ce sens que je pensait que tout contrôlleur DMA (intégré à la carte mère ou présent dans un contrôlleur disque) devait fonctionner... Visiblement, j'ai tout faux...
Pour les PC plus vieux (pseudo controlleur branché sur le bus AT), c'est le CPU qui était le "host" et l'utilisation du mode DMA (où le CPU n'était pas bloqué pendant le transert de données) permetait d'éviter de gacher du temps CPU.
Il me semblait que la RAM ne pouvait servir qu'un "maître" à la fois... Que lors d'un transfert DMA, le CPU était gelé les quelques petits cycles nécessaires à la lecture/écriture RAM...
Bah, on a jamais fini de découvrir comment fonctionnent ces bêtes-là !
-- Herm
Francois Petillon
On Tue, 24 Aug 2004 19:22:30 +0200, Remy Moulin wrote:
Pardon pour les manquements, mais c'est vrai que j'ai "sauté" une étape en passant directement d'un 486 "PIO" à un K6-III avec contrôlleur UDMA Bus Master... Y a t'il un site qui explique les détails des transferts DMA en Bus Master et sans Bus Master ? C'est pour culture personnelle :-)
Le site http://www.t13.org/ fourni les docs sur les specs ATA.
C'est dans ce sens que je pensait que tout contrôlleur DMA (intégré à la carte mère ou présent dans un contrôlleur disque) devait fonctionner...
Dans le cas des disques [U]DMA avec un controlleur minimaliste, on se repose sur le DMA "historique" de l'architecture PC pour gerer la recopie des données en mémoire. Pour ce qui est des controlleurs plus évolués, on pourrait utiliser n'importe quel mode d'accès aux disques sans que cela n'impacte les performances (puisque le "host" est le controlleur lui même et plus le CPU).
Il me semblait que la RAM ne pouvait servir qu'un "maître" à la fois... Que lors d'un transfert DMA, le CPU était gelé les quelques petits cycles nécessaires à la lecture/écriture RAM...
Oui, sauf que dans un cas, le CPU est bloqué le temps de la recopie des données du disque à la RAM alors qu'en DMA, on est bloqué que le temps de la copie d'un mot du bus AT à la RAM.
François
On Tue, 24 Aug 2004 19:22:30 +0200, Remy Moulin wrote:
Pardon pour les manquements, mais c'est vrai que j'ai "sauté" une étape en
passant directement d'un 486 "PIO" à un K6-III avec contrôlleur UDMA Bus
Master...
Y a t'il un site qui explique les détails des transferts DMA en Bus Master
et sans Bus Master ? C'est pour culture personnelle :-)
Le site http://www.t13.org/ fourni les docs sur les specs ATA.
C'est dans ce sens que je pensait que tout contrôlleur DMA (intégré à la
carte mère ou présent dans un contrôlleur disque) devait fonctionner...
Dans le cas des disques [U]DMA avec un controlleur minimaliste, on se
repose sur le DMA "historique" de l'architecture PC pour gerer la recopie
des données en mémoire. Pour ce qui est des controlleurs plus évolués,
on pourrait utiliser n'importe quel mode d'accès aux disques sans que
cela n'impacte les performances (puisque le "host" est le controlleur lui
même et plus le CPU).
Il me semblait que la RAM ne pouvait servir qu'un "maître" à la fois... Que
lors d'un transfert DMA, le CPU était gelé les quelques petits cycles
nécessaires à la lecture/écriture RAM...
Oui, sauf que dans un cas, le CPU est bloqué le temps de la recopie des
données du disque à la RAM alors qu'en DMA, on est bloqué que le temps
de la copie d'un mot du bus AT à la RAM.
On Tue, 24 Aug 2004 19:22:30 +0200, Remy Moulin wrote:
Pardon pour les manquements, mais c'est vrai que j'ai "sauté" une étape en passant directement d'un 486 "PIO" à un K6-III avec contrôlleur UDMA Bus Master... Y a t'il un site qui explique les détails des transferts DMA en Bus Master et sans Bus Master ? C'est pour culture personnelle :-)
Le site http://www.t13.org/ fourni les docs sur les specs ATA.
C'est dans ce sens que je pensait que tout contrôlleur DMA (intégré à la carte mère ou présent dans un contrôlleur disque) devait fonctionner...
Dans le cas des disques [U]DMA avec un controlleur minimaliste, on se repose sur le DMA "historique" de l'architecture PC pour gerer la recopie des données en mémoire. Pour ce qui est des controlleurs plus évolués, on pourrait utiliser n'importe quel mode d'accès aux disques sans que cela n'impacte les performances (puisque le "host" est le controlleur lui même et plus le CPU).
Il me semblait que la RAM ne pouvait servir qu'un "maître" à la fois... Que lors d'un transfert DMA, le CPU était gelé les quelques petits cycles nécessaires à la lecture/écriture RAM...
Oui, sauf que dans un cas, le CPU est bloqué le temps de la recopie des données du disque à la RAM alors qu'en DMA, on est bloqué que le temps de la copie d'un mot du bus AT à la RAM.
François
Remy Moulin
Francois Petillon wrote:
Le site http://www.t13.org/ fourni les docs sur les specs ATA.
Merci beaucoup ! Une mine d'or, ce site !!!
C'est dans ce sens que je pensait que tout contrôlleur DMA (intégré à la carte mère ou présent dans un contrôlleur disque) devait fonctionner...
Dans le cas des disques [U]DMA avec un controlleur minimaliste, on se repose sur le DMA "historique" de l'architecture PC pour gerer la recopie des données en mémoire.
Après des heures de recherches, je n'ai trouvé aucun contrôlleur ATA ayant utilisé le DMA "historique" des PC pour les transferts disque. On trouve par dixaine des pages expliquant que ce contrôlleur DMA est beaucoup trop lent. Il n'est, au final, utilisé que pour le lecteur de disquettes, le port imprimante en mode ECP, ou éventuellement les anciennes cartes sons format ISA...
Pour ce qui est des controlleurs plus évolués, on pourrait utiliser n'importe quel mode d'accès aux disques sans que cela n'impacte les performances (puisque le "host" est le controlleur lui même et plus le CPU).
En effet, excepté que ce genre de contrôlleur n'était pas franchement courant, aux débuts de l'ATA. Ce qui fait que lors d'un accès disque, le "contrôlleur" (faut-il réelement l'appeler ainsi ?) se contentait de transmettre illico les ordres et les données vers les véritables contrôlleurs, embarqués dans les périphériques (une des significations possibles de "IDE" : Integrated Device Electronics).
Du temps du VESA Local Bus, je n'ai retrouvé qu'un seul contrôlleur ayant un tantinet d'autonomie : le chip PDC20630, utilisé par exemple dans les cartes EIDE2300Plus de la firme Promise.
Et encore : ce contrôlleur était capable de faire des transferts "MultiWord DMA mode 2" avec les disques durs, mais... En VLB, il était apparemment impossible de faire des transferts direct en RAM systeme ! Pas de Bus Master (Au contraire du PCI)... Le CPU était sollicité pour transférer les données du PDC20630 vers la RAM, annulant, du coup, une bonne partie des avantages de ce mode.
Je n'ai pas trouvé d'autres exemples, ni en VLB, ni encore moins, en ISA de base...
En PCI, par contre, aucun problème : un contrôlleur sur bus PCI peut être Bus Master et utiliser du DMA directement vers la RAM système (le "DMA type F" du contrôlleur IDE interne aux premiers chips Intel (http://www.der-ingo.de/bin/milanhelp/i82371FB.pdf)).
-- Herm
Francois Petillon wrote:
Le site http://www.t13.org/ fourni les docs sur les specs ATA.
Merci beaucoup ! Une mine d'or, ce site !!!
C'est dans ce sens que je pensait que tout contrôlleur DMA (intégré
à la carte mère ou présent dans un contrôlleur disque) devait
fonctionner...
Dans le cas des disques [U]DMA avec un controlleur minimaliste, on se
repose sur le DMA "historique" de l'architecture PC pour gerer la
recopie des données en mémoire.
Après des heures de recherches, je n'ai trouvé aucun contrôlleur ATA ayant
utilisé le DMA "historique" des PC pour les transferts disque. On trouve par
dixaine des pages expliquant que ce contrôlleur DMA est beaucoup trop lent.
Il n'est, au final, utilisé que pour le lecteur de disquettes, le port
imprimante en mode ECP, ou éventuellement les anciennes cartes sons format
ISA...
Pour ce qui est des controlleurs plus
évolués, on pourrait utiliser n'importe quel mode d'accès aux disques
sans que cela n'impacte les performances (puisque le "host" est le
controlleur lui même et plus le CPU).
En effet, excepté que ce genre de contrôlleur n'était pas franchement
courant, aux débuts de l'ATA. Ce qui fait que lors d'un accès disque, le
"contrôlleur" (faut-il réelement l'appeler ainsi ?) se contentait de
transmettre illico les ordres et les données vers les véritables
contrôlleurs, embarqués dans les périphériques (une des significations
possibles de "IDE" : Integrated Device Electronics).
Du temps du VESA Local Bus, je n'ai retrouvé qu'un seul contrôlleur ayant un
tantinet d'autonomie : le chip PDC20630, utilisé par exemple dans les cartes
EIDE2300Plus de la firme Promise.
Et encore : ce contrôlleur était capable de faire des transferts "MultiWord
DMA mode 2" avec les disques durs, mais... En VLB, il était apparemment
impossible de faire des transferts direct en RAM systeme ! Pas de Bus Master
(Au contraire du PCI)... Le CPU était sollicité pour transférer les données
du PDC20630 vers la RAM, annulant, du coup, une bonne partie des avantages
de ce mode.
Je n'ai pas trouvé d'autres exemples, ni en VLB, ni encore moins, en ISA de
base...
En PCI, par contre, aucun problème : un contrôlleur sur bus PCI peut être
Bus Master et utiliser du DMA directement vers la RAM système (le "DMA type
F" du contrôlleur IDE interne aux premiers chips Intel
(http://www.der-ingo.de/bin/milanhelp/i82371FB.pdf)).
Le site http://www.t13.org/ fourni les docs sur les specs ATA.
Merci beaucoup ! Une mine d'or, ce site !!!
C'est dans ce sens que je pensait que tout contrôlleur DMA (intégré à la carte mère ou présent dans un contrôlleur disque) devait fonctionner...
Dans le cas des disques [U]DMA avec un controlleur minimaliste, on se repose sur le DMA "historique" de l'architecture PC pour gerer la recopie des données en mémoire.
Après des heures de recherches, je n'ai trouvé aucun contrôlleur ATA ayant utilisé le DMA "historique" des PC pour les transferts disque. On trouve par dixaine des pages expliquant que ce contrôlleur DMA est beaucoup trop lent. Il n'est, au final, utilisé que pour le lecteur de disquettes, le port imprimante en mode ECP, ou éventuellement les anciennes cartes sons format ISA...
Pour ce qui est des controlleurs plus évolués, on pourrait utiliser n'importe quel mode d'accès aux disques sans que cela n'impacte les performances (puisque le "host" est le controlleur lui même et plus le CPU).
En effet, excepté que ce genre de contrôlleur n'était pas franchement courant, aux débuts de l'ATA. Ce qui fait que lors d'un accès disque, le "contrôlleur" (faut-il réelement l'appeler ainsi ?) se contentait de transmettre illico les ordres et les données vers les véritables contrôlleurs, embarqués dans les périphériques (une des significations possibles de "IDE" : Integrated Device Electronics).
Du temps du VESA Local Bus, je n'ai retrouvé qu'un seul contrôlleur ayant un tantinet d'autonomie : le chip PDC20630, utilisé par exemple dans les cartes EIDE2300Plus de la firme Promise.
Et encore : ce contrôlleur était capable de faire des transferts "MultiWord DMA mode 2" avec les disques durs, mais... En VLB, il était apparemment impossible de faire des transferts direct en RAM systeme ! Pas de Bus Master (Au contraire du PCI)... Le CPU était sollicité pour transférer les données du PDC20630 vers la RAM, annulant, du coup, une bonne partie des avantages de ce mode.
Je n'ai pas trouvé d'autres exemples, ni en VLB, ni encore moins, en ISA de base...
En PCI, par contre, aucun problème : un contrôlleur sur bus PCI peut être Bus Master et utiliser du DMA directement vers la RAM système (le "DMA type F" du contrôlleur IDE interne aux premiers chips Intel (http://www.der-ingo.de/bin/milanhelp/i82371FB.pdf)).
