<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>3. Clusters de systèmes Linux</title><link href="style.css" rel="stylesheet" type="text/css"><meta content="DocBook XSL Stylesheets V1.68.1" name="generator"><link rel="start" href="index.html" title="Le traitement en parallèle sous Linux"><link rel="up" href="index.html" title="Le traitement en parallèle sous Linux"><link rel="prev" href="ar01s02.html" title="2. Linux sur SMP"><link rel="next" href="ar01s04.html" title="4. SIMD Within A Register : SWAR (Ex : utilisation de MMX)"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">3. <span class="foreignphrase"><em class="foreignphrase">Clusters</em></span> de systèmes Linux</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ar01s02.html">Précédent</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> <a accesskey="n" href="ar01s04.html">Suivant</a></td></tr></table><hr></div><div class="sect1" lang="fr"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N10704"></a>3. <span class="foreignphrase"><em class="foreignphrase">Clusters</em></span> de systèmes Linux</h2></div></div></div><p>
Cette section tente de donner un aperçu de ce qu'est le traitement
parallèle en <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> sous Linux. Les
<span class="foreignphrase"><em class="foreignphrase">clusters</em></span> sont, actuellement, à la fois
l'approche la plus populaire et la plus variée, en s'étendant du simple
réseau de stations de travail (<span class="foreignphrase"><em class="foreignphrase">Network Of
Workstations</em></span> : <span class="emphasis"><em>NOW</em></span>) aux
machines en parallèle essentiellement construites sur mesure, et dans
lesquelles il arrive que l'on trouve comme éléments des PC sous Linux. Il
existe également un grand nombre de logiciels pouvant prendre en charge
le calcul en parallèle dans des <span class="foreignphrase"><em class="foreignphrase">clusters</em></span>
de machines Linux.
</p><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a name="N1071A"></a>3.1. Pourquoi un <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> ?</h3></div></div></div><p>
Le traitement en parallèle au travers d'un
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> offre plusieurs avantages
majeurs :
</p><div class="itemizedlist"><ul type="disc"><li><p>
Chacune des machines d'un <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> peut
être un système complet, utilisable avec une large gamme d'applications
de calcul. Cela conduit beaucoup de gens à suggérer l'idée que ce type
de <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> pourrait faire usage de tous
les « <span class="quote">cycles machine perdus</span> » sur les ordinateurs tournant à
ne rien faire dans les bureaux. Il n'est pas si facile de récupérer ces
cycles, et cela risque de ralentir l'écran de veille de votre collègue,
mais cela peut être fait.
</p></li><li><p>
L'explosion actuelle des systèmes en réseau signifie que la plupart du
matériel nécessaire à la construction d'un
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> se vend déjà en grande quantité
et aux prix réduits inhérents à la « <span class="quote">grande distribution</span> ».
On peut économiser encore un peu plus en partant du principe qu'une
seule carte vidéo, un seul moniteur et un seul clavier soient
nécessaires pour chaque <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> (bien
qu'il vous faille tout de même les passer d'une machine à une autre pour
faire l'installation initiale de Linux, une fois lancé, un PC sous Linux
typique n'a pas besoin de « <span class="quote">console</span> »). En comparaison, les
systèmes SMP et processeurs auxiliaires représentent des marchés plus
réduits, tendant à proposer des prix plus élevés par performances à
l'unité.
</p></li><li><p>
Les calculateurs en <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> peuvent
<span class="emphasis"><em>évoluer en de très grands systèmes</em></span>. Alors qu'il est
actuellement difficile de trouver un ordinateur SMP à plus de quatre
processeurs qui soit compatible avec Linux, la plupart du matériel
réseau disponible permet de bâtir facilement un
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> incluant jusqu'à 16 machines.
Avec un peu d'huile de coude, on peut mettre en réseau des centaines
voire des milliers de machines. En fait, Internet tout entier pourrait
être assimilé à un seul immense <span class="foreignphrase"><em class="foreignphrase">cluster</em></span>.
</p></li><li><p>
Le fait que remplacer une « <span class="quote">mauvaise machine</span> » au sein d'un
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> soit une opération triviale
comparé à la réparation d'un ordinateur SMP partiellement défaillant
garantit une disponibilité bien plus élevée aux configurations de
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> soignées. Cela devient important
non seulement pour les applications qui ne peuvent tolérer des
interruptions de service trop importantes, mais aussi dans l'utilisation
en général de systèmes qui contiennent un nombre suffisant de
processeurs pour que la panne d'une machine en particulier soit assez
courante (par exemple, même si la durée moyenne avant la première panne
d'un PC est environ deux ans, dans un
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> de 32 machines, la probabilité
qu'au moins une machine tombe en panne dans les six premiers mois est
assez élevée).
</p></li></ul></div><p>
Très bien. Si les <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> sont gratuits
ou très peu onéreux, peuvent devenir très grands et offrir une haute
disponibilité… pourquoi tout le monde n'utilise pas un
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> ? Eh bien, parce qu'il y a
aussi des problèmes :
</p><div class="itemizedlist"><ul type="disc"><li><p>
À quelques exceptions près, le matériel réseau n'est pas conçu pour le
traitement en parallèle. Typiquement, les temps de latence sont élevés
et la bande passante réduite comparés aux systèmes SMP et processeurs
auxiliaires. Par exemple, si les temps de latence d'un SMP n'excèdent
généralement pas plus de quelques microsecondes, ils atteignent
couramment des centaines, voire des milliers de microsecondes dans un
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span>. La bande passante des
communications dans un système SMP dépasse souvent 100 mégaoctets par
seconde. Bien que le matériel réseau le plus rapide (c'est-à-dire le
« <span class="quote">Gigabit Ethernet</span> ») présente une vitesse comparable, la
plupart des réseaux sont de 10 à 1000 fois plus lents.
La performance d'un matériel réseau est déjà suffisamment médiocre dans
un <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> <span class="emphasis"><em>isolé</em></span>. Si
le réseau n'est pas isolé du reste du trafic, ce qui est souvent le cas
lorsque l'on utilise des « <span class="quote">machines qui sont en réseau</span> »
plutôt qu'un système conçu pour être un
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span>, les performances peuvent être
bien pires encore.
</p></li><li><p>
La gestion logicielle des <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> en
tant que système unique est très mince. Par exemple, la commande
<code class="literal">ps</code> ne fait état que des processus s'exécutant sur un
seul système Linux, pas des processus s'exécutant à travers le
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> Linux entier.
</p></li></ul></div><p>
Moralité, les <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> ont un très grand
potentiel, mais ce potentiel risque d'être très difficile à concrétiser
pour la plupart des applications. La bonne nouvelle, c'est qu'il existe
un soutien logiciel très développé pour vous aider à obtenir de bonnes
performances avec les programmes adaptés à cet environnement, et qu'il
existe également des réseaux conçus spécialement pour élargir la palette
de programmes pouvant avoir de bonnes performances.
</p></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a name="N1078F"></a>3.2. Le matériel réseau</h3></div></div></div><p>
Les réseaux informatiques sont en pleine explosion… mais vous le
savez déjà. Un nombre toujours grandissant de technologies et produits
réseau a été développé, et la plupart d'entre eux sont disponibles sous
une forme qui peut être utilisée pour faire d'un groupe de machines (des
PC fonctionnant chacun sous Linux) un
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> de traitement en parallèle.
</p><p>
Malheureusement, aucune technologie réseau ne résout complètement tous
les problèmes. À vrai dire, le nombre d'approches différentes, en coût
et en performances, est à première vue assez difficile à croire. Par
exemple, le coût par machine mise en réseau s'étend de moins de 5
dollars jusqu'à plus de 4000. La bande passante et les temps de latence
varient aussi selon quatre ordres de grandeur.
</p><p>
Avant d'en apprendre plus sur les spécificités de certains réseaux, il
est important de remarquer que ces choses évoluent très fréquemment
(voir <a href="http://www.linux.org.uk/NetNews.html" target="_top">http://www.linux.org.uk/NetNews.html</a> pour avoir des
nouvelles fraîches concernant les réseaux sous Linux), et qu'il est très
difficile d'obtenir des infos précises concernant certains réseaux.
</p><p>
J'ai placé un « <span class="quote"><span class="emphasis"><em>?</em></span></span> » aux endroits
incertains. J'ai aussi passé beaucoup de temps à faire des recherches
sur ce sujet, mais je reste sûr que ce résumé est plein d'erreurs et
d'omissions importantes. Si vous avez des corrections ou des ajouts à y
apporter, merci de m'envoyer un courrier électronique en anglais à
l'adresse suivante : <code class="email"><<a href="mailto:hankd CHEZ engr POINT uky POINT edu">hankd CHEZ engr POINT uky POINT edu</a>></code>.
</p><p>
Les résumés comme le <a href="http://www.mcgeoch.com/other/lan-technology.html" target="_top">LAN Technology
Scorecard</a><sup>[<a href="#ftn.N107AC" name="N107AC">10</a>]</sup> donnent les caractéristiques de nombreux et
différents types de réseaux et de standards de réseaux locaux (LAN).
Cependant, l'essentiel de ce guide pratique est centré sur les propriétés les
plus indiquées à la construction d'un
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> Linux. Chaque section décrivant
un type de réseau débute par une courte liste de caractéristiques. Ci
dessous, la définition de chaque entrée.
</p><div class="variablelist"><dl><dt><span class="term">Prise en charge sous Linux :</span></dt><dd><p>
Si la réponse est <span class="emphasis"><em>non</em></span>, la signification est claire.
Les autres réponses tentent de décrire l'interface de base utilisée pour
accéder au réseau. La plupart du matériel réseau est interfacé via un
pilote de périphérique du noyau, sachant typiquement gérer les
communications TCP/UDP. D'autres réseaux utilisent des interfaces plus
directes (par exemple des bibliothèques) pour réduire les temps de
latence en évitant d'avoir à passer par le noyau.
</p><p>
Il y a quelques années, il était considéré comme parfaitement acceptable
d'accéder au coprocesseur mathématique (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">floating
point unit</em></span></span> ») par un appel système mais
aujourd'hui, c'est clairement ridicule. À mon avis, nécessiter un appel
système pour chaque communication entre les processeurs exécutant un
programme en parallèle est peu commode. Le problème est que les
ordinateurs n'ont pas encore intégré ces mécanismes de communication, et
que les approches non « <span class="quote">orientées noyau</span> » tendent à présenter
des problèmes de portabilité. Vous allez entendre beaucoup parler de ce
sujet dans un avenir proche, principalement sous la forme de la nouvelle
<span class="emphasis"><em> Virtual Interface (VI) Architecture</em></span> (<a href="http://www.intel.com/intelpress/sum_via.htm" target="_top">http://www.intel.com/intelpress/sum_via.htm</a>) méthode
standardisée pour les opérations des interfaces réseau et servant à
contourner les couches des systèmes d'exploitation usuels. Le standard
VI est appuyé par Compaq, Intel et Microsoft, et aura assurément un
impact important sur la conception des SAN (<span class="foreignphrase"><em class="foreignphrase">System Area
Network</em></span>) dans les prochaines années.
</p></dd><dt><span class="term">Bande passante maximum :</span></dt><dd><p>
C'est le chiffre dont tout le monde se soucie. J'ai généralement repris
les débits maximum théoriques. Votre moyenne, elle,
<span class="emphasis"><em>va</em></span> varier.
</p></dd><dt><span class="term">Temps de latence minimum :</span></dt><dd><p>
À mon avis, c'est le chiffre dont tout le monde devrait se soucier, plus
encore que de la bande passante. Là encore, j'ai utilisé les
(irréalistes) valeurs théoriques idéales, mais au moins ces nombres
prennent en compte <span class="emphasis"><em>toutes</em></span> les sources de latence,
tant logicielles que matérielles. Dans la plupart des cas, les temps de
latence réseau ne durent que quelques microsecondes. Des nombres
beaucoup plus grands reflètent les couches des matériels et logiciels
inefficaces.
</p></dd><dt><span class="term">Disponibilité :</span></dt><dd><p>
Reprise telle quelle, cette ligne décrit la forme sous laquelle vous
pouvez acquérir ce type de matériel. Le matériel de la grande
distribution est disponible largement et de plusieurs fabricants, le
prix étant alors le premier critère de choix. Les choses proposées par
« <span class="quote">différents fabricants</span> » sont disponibles chez plus d'un
seul concurrent, mais il existe des différences significatives, et des
problèmes potentiels d'interopérabilité. Les réseaux produits par un
« <span class="quote">fabricant exclusif</span> » vous laissent à la merci de ce
fournisseur, aussi bienveillant soit-il. « <span class="quote">Domaine public</span> »
signifie que même si vous ne pouvez trouver quelqu'un pour vous vendre
ce type de matériel, vous ou n'importe qui d'autre pouvez acheter les
composants et en fabriquer un exemplaire. C'est typiquement le cas des
prototypes de recherche. Ils ne sont en général ni prêts à être utilisés
par le public, ni disponibles à celui-ci.
</p></dd><dt><span class="term">Port ou bus utilisé :</span></dt><dd><p>
La manière dont on relie l'interface réseau à l'ordinateur. Les
meilleures performances (et désormais les plus courantes) s'obtiennent
avec le bus PCI. Il existe aussi des cartes pour bus EISA, VESA local
bus (VLB), et ISA. ISA fut le premier, et il est toujours utilisé par
les cartes aux basses performances. On trouve toujours l'EISA comme bus
secondaire dans les machines PCI. Ces derniers temps, on ne trouve plus
beaucoup de matériel à base de VLB (même si la <a href="http://www.vesa.org" target="_top">Video Electronics Standards
Association</a> voit les choses autrement).
</p><p>
Bien sûr, toute interface que vous pouvez utiliser sans avoir à ouvrir
le boîtier de votre PC est plus qu'attrayante. les interfaces IrDA
(N.D.T. : port infrarouge) et USB font leur apparition de plus en
plus fréquemment. Le Port Parallèle Standard (SPP) est longtemps resté
« <span class="quote">ce sur quoi vous branchiez votre imprimante</span> », mais s'est
avéré dernièrement être très utile comme extension du bus ISA. Cette
nouvelle fonction est améliorée par le standard IEEE 1284, qui spécifie
les optimisations EPP et ECP. Il y a aussi le bon vieux port série
RS232, lent mais fiable. Je n'ai eu vent d'aucun témoignage concernant
l'interconnexion de machines par le biais des connecteurs vidéo (VGA),
clavier, souris ou joystick…
</p></dd><dt><span class="term">Structure du réseau :</span></dt><dd><p>
Un bus est un fil, un ensemble de fils, ou une fibre (optique). Un
<span class="foreignphrase"><em class="foreignphrase">hub</em></span> (« <span class="quote">concentrateur</span> » ou
« <span class="quote">plaque tournante</span> ») est une petite boite qui peut recevoir
différents types de fils ou de fibres. Les commutateurs
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">switched hubs</em></span></span> ») permettent
à plusieurs connexions de transmettre activement et simultanément leurs
données.
</p></dd><dt><span class="term">Coût par machine reliée :</span></dt><dd><p>
Voici comment lire ces nombres. Supposons que, en dehors des connexions
réseau, acheter un PC comme unité de votre
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> vous coûte 2000 dollars. L'ajout
de Fast Ethernet porte le prix à l'unité à environ 2400 dollars. L'ajout
de Myrinet mène ce prix à 3800 dollars environ. Si vous avez 20 000
dollars à dépenser, vous pouvez alors avoir soit 8 machines reliées par
du Fast Ethernet, soit 5 machines reliées par du Myrinet. Il est
également très raisonnable d'utiliser plusieurs types de réseaux. Par
exemple, avec 20 000 dollars, vous pouvez vous offrir 8 machines
reliées entre elles par Fast Ethernet et TTL_PAPERS. Choisissez un
réseau — ou un ensemble de réseaux — qui permettra à votre
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> d'exécuter votre application le
plus rapidement possible.
</p><p>
Au moment où vous lirez ces lignes, ces chiffres seront faux… En
fait, ils le sont sûrement déjà. Il peut aussi y avoir un grand nombre
de réductions, d'offres spéciales, et cætera. Mais en tout cas, les prix
cités ici ne seront jamais suffisamment erronés pour vous conduire à
faire un choix totalement inapproprié. Nul besoin d'avoir un doctorat
(même si c'est mon cas ;-) pour constater que l'utilisation de réseaux
onéreux n'a de sens que si votre application a réellement besoin de
leurs propriétés ou si les PC utilisés dans votre
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> sont eux aussi relativement
chers.
</p></dd></dl></div><p>
Maintenant que vous êtes avertis, place au spectacle…
</p><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10825"></a>3.2.1. ArcNet</h4></div></div></div><p>
<div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>pilotes du noyau</em></span>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>2,5 Mbits/s</em></span>
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>1000 microsecondes ?</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>différents fabricants</em></span>
</p></li><li><p>
Port ou bus utilisé : <span class="emphasis"><em>ISA</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em><span class="foreignphrase"><em class="foreignphrase">Hub</em></span> ou bus non commutés (anneau logique)</em></span>
</p></li><li><p>
Coût par machine reliée : <span class="emphasis"><em>200 dollars</em></span>
</p></li></ul></div>
</p><p>
ARCNET est un réseau local principalement destiné à être utilisé
dans les systèmes de contrôle temps réel embarqués. Comme Ethernet,
le réseau est physiquement organisé en prises le long d'un bus d'un
ou plusieurs <span class="foreignphrase"><em class="foreignphrase">hubs</em></span>. En revanche, et contrairement
à Ethernet, il utilise un protocole à base de jetons qui structure de manière
logique le réseau comme un anneau. Les entêtes des paquets sont réduites (3 ou 4
octets) et les messages peuvent être très courts (jusqu'à un seul octet).
De fait, ARCNET est plus efficace qu'Ethernet. Malheureusement, il est
aussi plus lent, et moins populaire ce qui le rend plus cher. Vous trouvez
plus d'informations sur le site de l'<a href="http://www.arcnet.com/" target="_top">ARCNET Trade Association</a>.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10861"></a>3.2.2. ATM</h4></div></div></div><p>
<div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>pilotes du noyau, bibliothèques AAL*</em></span>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>155 Mbits/s</em></span> (bientôt, <span class="emphasis"><em>1200 Mbits/s</em></span>)
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>120 microsecondes</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>différents fabricants</em></span>
</p></li><li><p>
Port ou bus utilisé : <span class="emphasis"><em>PCI</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em><span class="foreignphrase"><em class="foreignphrase">hubs</em></span> commutés</em></span>
</p></li><li><p>
Coût par machine reliée : <span class="emphasis"><em>3000 dollars</em></span>
</p></li></ul></div>
</p><p>
A moins d'avoir été dans le coma ces dernières années, vous avez
sûrement beaucoup entendu dire qu'ATM (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Asynchronous Transfer Mode</em></span></span> »)
<span class="emphasis"><em>est</em></span> l'avenir… Eh bien, en quelque sorte.
ATM est meilleur marché que HiPPI et plus rapide que Fast Ethernet,
et il peut être utilisé sur de très longues distances, ce qui
intéresse beaucoup les opérateurs téléphoniques. Le protocole du
réseau ATM est également conçu pour fournir une interface logicielle
aux temps d'accès réduits et gérant plus efficacement les messages
courts et les communications en temps réel (c'est-à-dire les transmissions
audio et vidéo numériques). C'est aussi l'un des réseaux aux plus hauts
débits que Linux prenne actuellement en charge. La mauvaise nouvelle,
c'est qu'ATM n'est pas vraiment bon marché, et qu'il demeure encore des
problèmes de compatibilité entre fabricants. Un aperçu du développement
ATM sous Linux est disponible sur <a href="http://linux-atm.sourceforge.net/" target="_top">http://linux-atm.sourceforge.net/</a>.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N108A4"></a>3.2.3. CAPERS</h4></div></div></div><p>
<div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>bibliothèque AFAPI</em></span>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>1,2 Mbit/s</em></span>
</p></li><li><p>
Temps de latence maximum : <span class="emphasis"><em>3 microsecondes</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>grande distribution</em></span>
</p></li><li><p>
Port ou bus utilisé : <span class="emphasis"><em>SPP (port parallèle)</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>câble entre 2 machines</em></span>
</p></li><li><p>
Coût par machine reliée : <span class="emphasis"><em>2 dollars</em></span>
</p></li></ul></div>
</p><p>
CAPERS (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Cable Adapter for Parallel Execution and
Rapid Synchronisation</em></span></span> » : « <span class="quote">Adaptateur
par Câble pour l'Exécution en Parallèle et la Synchronisation
Rapide</span> ») est un produit dérivé du projet PAPERS, de
l'<span class="foreignphrase"><em class="foreignphrase">University School of Electrical and Computer
Engineering</em></span> de Purdue. En substance, ce projet définit
un protocole logiciel permettant d'utiliser une simple liaison
point-à-point par le port parallèle, type « <span class="quote">LapLink</span> », pour
implémenter la bibliothèque PAPERS sur deux PC sous Linux. L'idée n'est
exploitable à grande échelle, mais le prix est imbattable. Tout comme avec
TTL_PAPERS, pour améliorer la sécurité du système, il est recommandé,
mais pas nécessaire, d'appliquer un correctif mineur au noyau.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N108E4"></a>3.2.4. Ethernet</h4></div></div></div><p>
<div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>pilotes du noyau</em></span>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>10 Mbits/s</em></span>
</p></li><li><p>
Latence minimum : <span class="emphasis"><em>100 microsecondes</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>grande distribution</em></span>
</p></li><li><p>
Port ou bus utilisé : <span class="emphasis"><em>PCI</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>commutateurs ou concentrateurs, ou même bus simple</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>100 dollars</em></span> (sans concentrateur, <span class="emphasis"><em>50 dollars</em></span>)
</p></li></ul></div>
</p><p>
Depuis plusieurs années maintenant, l'Ethernet à 10Mbits/s est le
standard des technologies réseau. Une bonne carte Ethernet s'achète pour
moins de 50 dollars, et bon nombre de PC en sont aujourd'hui équipés de
série, l'interface étant intégrée à la carte-mère. Les réseaux à base
Ethernet dont la charge n'est pas très élevée peuvent être organisés
comme un long bus à prises multiples sans concentrateur
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">hub</em></span></span> »). Une telle
configuration peut servir jusqu'à 200 machines pour un coût minimal,
mais n'est pas appropriée au traitement en parallèle. Ajouter un
concentrateur non commuté n'améliore pas beaucoup les performances. En
revanche, les commutateurs
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">switches</em></span></span> »), qui peuvent
offrir une bande passante maximum à plusieurs connexions simultanément
ne coûtent qu'aux alentours de 100 dollars par port. Linux prend en
charge un nombre impressionnant d'interfaces Ethernet différentes, mais
il est important de garder à l'esprit que les variations entre ces
matériels peuvent engendrer de grandes différences de performance.
Consultez le <a href="http://www.traduc.org/docs/howto/lecture/Hardware-HOWTO.html" target="_top">Guide pratique de
la compatibilité matérielle avec Linux</a> (N.D.T. : version
française du <a href="http://www.tldp.org/HOWTO/Hardware-HOWTO/" target="_top">
<span class="foreignphrase"><em class="foreignphrase">Hardware Compatibility HOWTO</em></span>
</a>) pour plus d'informations concernant les différents équipements
fonctionnant sous Linux, et pour avoir une idée de leur qualité.
</p><p>
Le <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> Linux à 16 machines réalisé
dans le cadre du projet « <span class="quote"><a href="http://www.beowulf.org" target="_top">Beowulf</a></span> » (initialement
développé au CESDIS de la NASA) est une manière intéressante d'augmenter
ses performances. C'est à Donald Becker, auteur de plusieurs pilotes de
cartes Ethernet, que l'on doit la prise en charge de la répartition du
trafic au travers de plusieurs cartes réseau s'éclipsant mutuellement
(autrement dit, partageant les mêmes adresses réseau). Cette fonction
est intégrée en standard dans Linux, et s'effectue de manière invisible
en dessous du niveau des opérations sur les
<span class="foreignphrase"><em class="foreignphrase">sockets</em></span>. Le coût d'un hub n'étant pas
négligeable, relier chaque machine à deux (ou plus) réseaux Ethernet,
sans <span class="foreignphrase"><em class="foreignphrase">hubs</em></span> ni
<span class="foreignphrase"><em class="foreignphrase">switches</em></span>, pour améliorer les performances
peut s'avérer financièrement très rentable. D'une manière générale, dans
les situations où une machine est le goulet d'étranglement d'un réseau,
la répartition de charge à travers plusieurs réseaux
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">shadow networks</em></span></span> ») se
révèle bien plus efficace que l'usage d'un réseau équipé d'un
commutateur seul.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10944"></a>3.2.5. Ethernet (Fast Ethernet)</h4></div></div></div><p>
<div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>pilotes du noyau</em></span>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>100 Mbits/s</em></span>
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>80 microsecondes</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>grande distribution</em></span>
</p></li><li><p>
Port ou bus utilisé : <span class="emphasis"><em>PCI</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>concentrateurs ou commutateurs
(<span class="foreignphrase" lang="en"><em class="foreignphrase">hubs</em></span> ou <span class="foreignphrase" lang="en"><em class="foreignphrase">switches</em></span>)</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>400 dollars (?)</em></span>
</p></li></ul></div>
</p><p>
Bien qu'il existe un certain nombre de technologies différentes nommées
« <span class="quote">Fast Ethernet</span> », elles se réfèrent souvent à un réseau
Ethernet 100 Mbits/s en grande partie compatible avec les anciens câbles
et périphériques 10 Mbits/s type « <span class="quote">10 BaseT</span> ». Comme on peut
s'y attendre, tout ce qui s'appelle Ethernet bénéficie des prix de la
vente de masse, et ces interfaces ne coûtent généralement qu'une
fraction du prix des cartes ATM à 155 Mbits/s. Le problème est qu'une
collection de machines partageant tous le même « <span class="quote">bus</span> » à 100
Mbits/s (à l'aide d'un <span class="foreignphrase"><em class="foreignphrase">hub</em></span> non commuté)
peut présenter des performances n'atteignant en moyenne même pas celles
d'un réseau 10 Mbits/s utilisant un commutateur fournissant à chaque
machine une connexion 10 Mbits/s complète.
</p><p>
Les commutateurs pouvant fournir une connexion 100 Mbits à chaque
machine simultanément sont chers, mais les prix chutent chaque jour,
et ces commutateurs offrent une bande passante autrement plus élevée
que de simples <span class="foreignphrase"><em class="foreignphrase">hubs</em></span> non commutés. Ce qui rend les commutateurs ATM
si onéreux est la nécessité de commuter chaque cellule ATM, cellule
relativement courte. Certains commutateurs Ethernet parient sur une
fréquence de commutation attendue relativement lente et en tirent
profit en utilisant des techniques aux temps de latence réduits à
l'intérieur du commutateur, mais nécessitant quelques millisecondes
pour changer de voie. Si l'itinéraire de votre trafic réseau change
fréquemment, évitez ce type d'équipement.
</p><p>
Notez aussi que, comme pour Ethernet, le projet Beowulf
(<a href="http://www.beowulf.org" target="_top">http://www.beowulf.org</a>) de la NASA développe des pilotes aux performances supérieures
car utilisant la répartition de charge entre plusieurs cartes
Fast Ethernet.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10996"></a>3.2.6. Ethernet (Gigabit Ethernet)</h4></div></div></div><p>
<div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>pilotes du noyau</em></span>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>1000 Mb/s</em></span>
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>300 microsecondes (?)</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>différents fabricants</em></span>
</p></li><li><p>
Port ou bus utilisé : <span class="emphasis"><em>PCI</em></span>
</p></li><li><p>
Structure réseau : <span class="emphasis"><em>commutateurs ou FDR</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>2500 dollars (?)</em></span>
</p></li></ul></div>
</p><p>
Je ne suis pas sûr que <a href="http://www.gigabit-ethernet.org/" target="_top">Gigabit Ethernet</a>
ait une raison technologique valable
de s'appeler Ethernet… mais son nom inspire le fait que
Gigabit Ethernet est conçu pour être une technologie réseau
bon marché et de grande distribution, avec une prise en charge
native de l'IP. En revanche, les prix actuels reflètent le
fait que cela reste un produit difficile à fabriquer.
</p><p>
Contrairement aux autres technologies Ethernet, Gigabit Ethernet apporte
un contrôle du flux, ce qui devrait en faire un réseau plus fiable. Les
FDR, ou « <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Full-Duplex
Repeaters</em></span></span> » (« <span class="quote">répéteurs bidirectionnels
simultanés</span> »), se contentent de multiplexer les lignes, en
utilisant des mémoires tampons et des contrôles de flux localisés pour
améliorer les performances. La plupart des commutateurs sont construits
comme de nouveaux modules pour les différents modèles de commutateurs
compatible Gigabit déjà existants. Les commutateurs ou FDR sont
distribués ou annoncés par au moins Acacianet, <a href="http://www.baynetworks.com/" target="_top">Bay networks</a>, <a href="http://www.cabletron.com/" target="_top">Cabletron</a> (désormais Enterasys.
Page française : <a href="http://www.enterasys.com/fr/" target="_top">http://www.enterasys.com/fr/</a>),
Networks digital, <a href="http://www.extremenetworks.com/homepage_french.asp" target="_top">Extreme
networks</a>, <a href="http://www.foundrynet.com/" target="_top">Foundry
networks</a>, Gigalabs.com, Packet engines, <a href="http://www.plaintree.com/" target="_top">Plaintree systems</a>, <a href="http://www.prominet.com/" target="_top">Prominet</a>, <a href="http://fr.sun.com/" target="_top">Sun microsystems</a>, et Xlnt.
</p><p>
Il existe un pilote pour Linux pour les « <span class="quote">Yellowfin</span> » G-NIC
de Packet Engines<sup>[<a href="#ftn.N109FA" name="N109FA">11</a>]</sup>. Les premiers essais sous Linux ont fait état d'un
taux de transfert environ 2,5 fois supérieur à la plus rapide des cartes
Fast Ethernet à 100 Mbits/s. Avec les réseaux Gigabit, une configuration
soigneuse du bus PCI est un facteur critique. Il reste toujours un doute
quant à la poursuite des améliorations de ce pilote, et du développement
des pilotes Linux des autres cartes réseau.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N109FE"></a>3.2.7. FC (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Fibre Channel</em></span></span> »)</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux :
<span class="emphasis"><em>non</em></span><sup>[<a href="#ftn.N10A0B" name="N10A0B">12</a>]</sup>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>1062 Mbits/s</em></span>
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>?</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>différents fabricants</em></span>
</p></li><li><p>
Interface ou bus utilisé : <span class="emphasis"><em>PCI (?)</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>?</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>?</em></span>
</p></li></ul></div><p>
L'objectif du FC (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Fibre
Channel</em></span></span> ») est de fournir un médium
d'entrée/sortie de type bloc aux performances élevées (une trame FC
transporte un bloc de données d'une longueur forfaitaire de 2048
octets), particulièrement adapté aux partages de disques et autres
périphériques de stockage, qui peuvent alors être reliés directement au
réseau FC plutôt qu'à travers un ordinateur. Niveau bande passante, le
FC est présenté comme étant relativement rapide, avec un taux s'étendant
de 133 à 1062 Mbits/s. Si le FC tend à devenir populaire en tant que
solution haut-de-gamme de remplacement du SCSI, il pourrait rapidement
devenir une technologie très abordable. Pour le moment, ce n'est pas
abordable, et ce n'est pas pris en charge par Linux. La Fibre Channel
Association tient une importante collection de références au FC, sur
<a href="http://www.fibrechannel.org" target="_top">http://www.fibrechannel.org</a><sup>[<a href="#ftn.N10A3B" name="N10A3B">13</a>]</sup>.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10A48"></a>3.2.8. FireWire (IEEE 1394)</h4></div></div></div><p>
<div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>non</em></span><sup>[<a href="#ftn.N10A53" name="N10A53">14</a>]</sup>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>196,608 Mbits/s</em></span> (bientôt, <span class="emphasis"><em>393,216 Mbits/s</em></span>)
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>?</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>différents fabricants</em></span>
</p></li><li><p>
Interface ou bus utilisé : <span class="emphasis"><em>PCI</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>aléatoire, sans cycles (auto-configuré)</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>600 dollars</em></span>
</p></li></ul></div>
</p><p>
FireWire, ou standard IEEE 1394-1995, est voué à être le réseau numérique
à grande vitesse et à prix réduit des appareils électroniques domestiques.
Son application-phare est la connexion des caméscopes numériques aux
ordinateurs, mais FireWire est destiné à être utilisé dans des domaines
s'étendant de l'alternative au SCSI jusqu'à l'interconnexion des différents
composants de votre « <span class="quote">Home Cinéma</span> ». Il vous permet de relier plus de
64000 périphériques dans une topologie utilisant des bus et des ponts
mais ne formant pas de boucle, et détecte automatiquement la configuration
des périphériques lorsqu'ils sont ajoutés ou retirés. Les messages courts
(les « <span class="quote">quadlets</span> », longs de quatre octets) sont également pris en charge,
de même que les transmissions isochrones sur le modèle de l'ATM (utilisées
pour préserver le synchronisme des messages multimédia). Adaptec propose
des produits FireWire permettant de relier jusqu'à 63 périphériques
à une seule carte PCI, et tient aussi un bon site d'information générale
concernant le FireWire sur
<a href="http://www.adaptec.com/worldwide/product/prodtechindex.html?cat=%2fTechnology%2fFireWire-1394&prodkey=1394_summary" target="_top">http://www.adaptec.com</a>.
</p><p>
Bien que le FireWire ne soit pas le réseau le plus rapide disponible
actuellement, le marché de la grande distribution (qui tire les prix
vers le bas) et les temps de latence réduits pourraient en faire d'ici
l'an prochain la meilleure interface réseau pour le <span class="emphasis"><em><span class="foreignphrase"><em class="foreignphrase">message passing</em></span></em></span> dans
un <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> de PC sous Linux.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10A94"></a>3.2.9. HiPPI et Serial HiPPI</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux :
<span class="emphasis"><em>non</em></span><sup>[<a href="#ftn.N10A9D" name="N10A9D">15</a>]</sup>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>1600 Mbits/s</em></span>
(<span class="emphasis"><em>1200 Mb/s</em></span> pour Serial HiPPI)
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>?</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>différents fabricants</em></span>
</p></li><li><p>
Interface ou bus utilisé : <span class="emphasis"><em>EISA, PCI</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>commutateurs</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>3500 dollars</em></span>
(<span class="emphasis"><em>4,500</em></span> dollars pour Serial HiPPI)
</p></li></ul></div><p>
HiPPI (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">High Performance Parallel
Interface</em></span></span> », soit « <span class="quote">Interface Parallèle aux
Performances Élevées</span> ») était initialement censée fournir un taux
de transfert élevé pour l'échange d'immenses blocs de données entre un
supercalculateur et une autre machine (un autre supercalculateur, un
« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">frame buffer</em></span></span> », une batterie
de disques, et cætera), et est devenu le standard dominant dans le monde
des supercalculateurs. Bien que ce soit un oxymoron, <span class="emphasis"><em>Serial
HiPPI</em></span> devient également très populaire en utilisant
typiquement de la fibre optique à la place des câbles HiPPI standard de
32 bits de large (donc parallèles). Ces dernières années, les
commutateurs HiPPI en croix sont devenus courants et les prix ont
sérieusement chuté. Malheureusement, les équipement HiPPI Série, eux,
sont encore très onéreux, et sont en général les seuls pris en charge
par le bus PCI. Pire, Linux ne gère pas encore HiPPI. Le CERN tient une
bonne présentation d'HiPPI sur <a href="http://www.cern.ch/HSI/hippi/" target="_top">http://www.cern.ch/HSI/hippi/</a>. Ils tiennent aussi une liste
assez longue de distributeurs proposant le HiPPI sur <a href="http://www.cern.ch/HSI/hippi/procintf/manufact.htm" target="_top">http://www.cern.ch/HSI/hippi/procintf/manufact.htm</a>.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10AE1"></a>3.2.10. IrDA (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Infrared Data Association</em></span></span> »)</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>non
(?)</em></span><sup>[<a href="#ftn.N10AEE" name="N10AEE">16</a>]</sup>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>1,15 Mbits/s</em></span> et
<span class="emphasis"><em>4 Mbits/s</em></span>
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>?</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>Différents fabricants</em></span>
</p></li><li><p>
Interface ou bus utilisé : <span class="emphasis"><em>IrDA</em></span>
</p></li><li><p>
Structure réseau : <span class="emphasis"><em>Air libre</em></span> ;-)
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>0</em></span>
</p></li></ul></div><p>
L'IrDA (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Infrared Data
Association</em></span></span> » ou « <span class="quote">Association de Données par
Infrarouges</span> », sur <a href="http://www.irda.org" target="_top">http://www.irda.org</a>), c'est ce
petit appareil à infrarouges sur le coté des ordinateurs portables. Il
reste assez difficile, par conception, de relier plus de deux
ordinateurs par ce biais, aussi l'IrDA ne se prête-t-il guère à la
« <span class="quote">clusterisation</span> », ou mise en parallèle massive de
nombreuses machines. Don Becker est toutefois l'auteur de quelques
travaux préliminaires sur l'IrDA.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10B28"></a>3.2.11. Myrinet</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>bibliothèques</em></span>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>1280 Mbits/s</em></span>
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>9 microsecondes</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>matériel propriétaire.</em></span>
</p></li><li><p>
Interface ou bus utilisés : <span class="emphasis"><em>PCI</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>commutateurs</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>1800 dollars</em></span>
</p></li></ul></div><p>
<a href="http://www.myri.com" target="_top">Myrinet</a> est un réseau local
(LAN : « <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Local Area
Network</em></span></span> ») conçu pour servir également de réseau
système <sup>[<a href="#ftn.N10B60" name="N10B60">17</a>]</sup>. Les versions LAN et SAN utilisent des médias
physiques distincts et leur caractéristiques sont sensiblement
différentes. La version SAN est généralement utilisée au sein d'un
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span>.
</p><p>
La structure de Myrinet est très conventionnelle, mais a la réputation
d'être très bien implémentée. Les pilotes pour Linux sont connus pour
donner de très bons résultats, bien qu'il eût été fait état de frappantes
différences de performances d'une implémentation du bus PCI à l'autre.
</p><p>
Actuellement, Myrinet est assurément le réseau favori des responsables
de <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> n'étant pas trop sévèrement
limité au niveau budgétaire. Si, pour vous, un PC Linux typique est un
Pentium Pro dernier cri ou un Pentium II avec au moins 256 Mo de mémoire
vive, et un disque RAID et SCSI, alors le coût de Myrinet apparaît
raisonnable. En revanche, avec des machines plus conventionnelles, il
vous faudra probablement choisir entre relier <span class="emphasis"><em>N</em></span>
machines avec Myrinet, ou <span class="emphasis"><em>2N</em></span> machines avec
plusieurs équipements de type « <span class="quote">Fast Ethernet</span> » ou
« <span class="quote">TTL_PAPERS</span> ». Tout cela dépend réellement de votre budget
et du type de calcul qui vous importe le plus.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10B84"></a>3.2.12. Parastation</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>couches d'abstraction
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">HAL</em></span></span> ») ou bibliothèques
réseau</em></span>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>125 Mbits/s</em></span>
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>2 microsecondes</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>fabricant exclusif</em></span>
</p></li><li><p>
Interface ou bus utilisé : <span class="emphasis"><em>PCI</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>maillage, sans concentrateur</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>plus de 1000 dollars</em></span>
</p></li></ul></div><p>
Le projet ParaStation (<a href="http://wwwipd.ira.uka.de/parastation" target="_top">http://wwwipd.ira.uka.de/parastation</a>) de la section informatique
de l'Université de Karlsruhe est en train de mettre sur pieds un réseau
« <span class="quote">maison</span> » compatible PVM et aux temps de latence réduits.
Ils ont d'abord construit un prototype de ParaPC biprocesseur en
utilisant une carte EISA conçue sur mesure et des PC fonctionnant sous
Unix BSD, puis ont bâti de plus grands
<span class="foreignphrase"><em class="foreignphrase">clusters</em></span> composés de machines Alpha DEC.
Depuis Janvier 1997, Parastation est disponible sous Linux. Les cartes
PCI sont produites en coopération avec une société nommée <a href="http://www.hitex.com" target="_top">Hitex</a>. Le matériel de Parastation
implémente à la fois un système de transmission de messages rapide et
fiable, et des barrières de synchronisation simples.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10BC5"></a>3.2.13. PLIP</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>pilotes du noyau</em></span>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>1,2 Mbits/s</em></span>
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>1000 microsecondes ?</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>grande distribution</em></span>
</p></li><li><p>
Interface ou bus utilisé : <span class="emphasis"><em>SPP</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>câble entre 2 machines</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>2 dollars</em></span>
</p></li></ul></div><p>
Pour le seul coût d'un câble « <span class="quote">LapLink</span> » (N.D.T. : câble
parallèle croisé), PLIP (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Parallel Line Interface
Protocol</em></span></span> », soit « <span class="quote">Protocole d'Interface par
Ligne Parallèle</span> ») permet à deux machines Linux de communiquer par
le port parallèle en utilisant les couches logicielles standard basées
sur la communication par « <span class="quote">sockets</span> ». En termes de bande
passante, de temps de latence et d'évolutivité, il ne s'agit pas d'une
technologie réseau sérieuse. En revanche, le coût de revient quasi-nul
et la compatibilité logicielle s'avèrent être très utiles. Le pilote est
partie intégrante du noyau Linux standard.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10C02"></a>3.2.14. SCI</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>non</em></span>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>4000 Mbit/s</em></span>
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>2,7 microsecondes</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>différents fabricants.</em></span>
</p></li><li><p>
Interface ou bus utilisé : <span class="emphasis"><em>PCI et propriétaire</em></span>
</p></li><li><p>
Structure réseau : <span class="emphasis"><em>?</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>+ de 1000 dollars</em></span>
</p></li></ul></div><p>
L'objectif de SCI (Scalable Coherent Interconnect, ANSI/IEEE 1596-1992)
consiste essentiellement à fournir un mécanisme de haute performance
pouvant assurer des accès cohérents à la mémoire partagée au travers
d'un grand nombre de machines. On peut dire sans se mouiller que la
bande passante et les temps de latences de SCI sont « <span class="quote">très
impressionnants</span> » comparés à la plupart des autres technologies
réseau. Le problème est que SCI n'est pas très répandu et reste donc
assez onéreux, et que ce matériel n'est pas pris en charge par Linux.
</p><p>
SCI est principalement utilisé dans diverses implémentations
propriétaires pour des machines à mémoire partagée logiquement et
distribuée physiquement, comme le HP/Convex Exemplar SPP et le Sequent
NUMA-Q 2000 (voir <a href="http://www.sequent.com" target="_top">http://www.sequent.com</a><sup>[<a href="#ftn.N10C39" name="N10C39">18</a>]</sup>). Ceci dit, SCI est disponible sous forme de
carte PCI et de commutateurs quatre ports de Dolphin (on peut relier
ainsi jusqu'à 16 machines en montant ces commutateurs en cascade),
<a href="http://www.dolphinics.com" target="_top">http://www.dolphinics.com</a>, sous la série "Clustar". Le
CERN tient à jour une bonne collection de liens concernant SCI sur
<a href="http://www.cern.ch/HSI/sci/sci.html" target="_top">http://www.cern.ch/HSI/sci/sci.html</a>.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10C43"></a>3.2.15. SCSI</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>pilotes du noyau</em></span>
</p></li><li><p>
Bande passante maximum : de <span class="emphasis"><em>5 Mbits/s</em></span> à plus
de <span class="emphasis"><em>20 Mbits/s</em></span>
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>?</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>différents fabricants</em></span>
</p></li><li><p>
Interface ou bus utilisé : <span class="emphasis"><em>cartes PCI, EISA ou
ISA</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>bus inter-machines partageant des
périphériques SCSI</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>?</em></span>
</p></li></ul></div><p>
Le SCSI (Small Computer Systems Interconnect) consiste essentiellement
en un bus d'entrée/sortie utilisé par les disques durs, les lecteurs de
CD-ROM, les numériseurs
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">scanners</em></span></span> »), et cætera. Il
existe trois standards distincts : SCSI-1, SCSI-2 et SCSI-3, en
vitesses "Fast" et "Ultra" et en largeur de bus de 8, 16 ou 32 bits
(avec compatibilité FireWire annoncée pour SCSI-3). Tout cela est plutôt
confus, mais nous savons tous qu'un bon SCSI est bien plus rapide que
l'EIDE, et peut gérer plus de périphériques, plus efficacement.
</p><p>
Ce que beaucoup de gens ne réalisent pas, c'est qu'il est très simple de
partager le même bus SCSI entre deux ordinateurs. Ce type de
configuration est très utile pour partager des disques entre deux
machines et mettre en place un système de
<span class="emphasis"><em><span class="foreignphrase"><em class="foreignphrase">fail-over</em></span></em></span>, de façon
à ce qu'une machine prenne à sa charge les requêtes à une base de
données lorsque l'autre machine tombe en panne. C'est actuellement le
seul mécanisme reconnu par le <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> PC
de Microsoft : WolfPack. En revanche, l'incapacité du SCSI à
évoluer vers de plus grands systèmes le rend en général inintéressant
pour le traitement en parallèle.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10C83"></a>3.2.16. ServerNet</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>non</em></span>
</p></li><li><p>
Maximum bandwidth : <span class="emphasis"><em>400 Mbits/s</em></span>
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>3 microsecondes</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>fabricant exclusif</em></span>
</p></li><li><p>
Interface ou bus utilisé : <span class="emphasis"><em>PCI</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>arbre hexagonal / concentrateurs en
mailles tétraédriques</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>?</em></span>
</p></li></ul></div><p>
ServerNet est la solution réseau de haute performance proposée par
Tandem (<a href="http://www.tandem.com" target="_top">http://www.tandem.com</a>). Dans le monde du
traitement des transactions en ligne (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">OnLine
Transation Processing</em></span></span> », ou « <span class="quote">OLTP</span> »)
en particulier, Tandem est réputé être l'un des premiers fabricants de
systèmes de haute fiabilité, aussi n'est-il pas surprenant que leurs
réseaux ne revendiquent pas simplement la haute performance, mais aussi
la « <span class="quote">haute fiabilité et intégrité des données</span> ». Une autre
facette intéressante de ServerNet : ce matériel serait capable de
transférer des données directement de périphérique à périphérique, pas
simplement entre processeurs, mais également entre disques durs, et
cætera, dans un style unilatéral similaire à ce qui a été suggéré pour
les mécanismes d'accès à distance à la mémoire du MPI, décrits dans la
section 3.5. Un dernier mot à propos de Servernet : Bien qu'il n'y
ait qu'un seul fabricant, celui-ci est suffisamment puissant pour faire
établir potentiellement Servernet en tant que standard majeur :
Tandem appartient à Compaq<sup>[<a href="#ftn.N10CC0" name="N10CC0">19</a>]</sup>.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10CC4"></a>3.2.17. SHRIMP</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>interface utilisateur à
mémoire mappée</em></span>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>180 Mbits/s</em></span>
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>5 microsecondes</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>prototype expérimental</em></span>
</p></li><li><p>
Interface ou bus utilisé : <span class="emphasis"><em>EISA</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>Fond de panier en maille (comme
pour le Paragon d'Intel)</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>?</em></span>
</p></li></ul></div><p>
Le projet <a href="http://www.cs.princeton.edu/shrimp/" target="_top">SHRIMP</a> de la section
des sciences des ordinateurs de l'Université de Princeton, met sur pieds
un ordinateur parallèle en utilisant dont les éléments de traitement
sont des ordinateurs PC sous Linux. Le premier SHRIMP
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Scalable, High-Performance, Really Inexpensive
Multi-Processor</em></span></span> », soit « <span class="quote">multiprocesseur
évolutif et de hautes performances vraiment bon marché</span> ») était un
simple prototype biprocesseur utilisant une mémoire partagée sur une
carte EISA développée pour l'occasion. Il existe désormais un prototype
pouvant évoluer vers de plus larges configurations en utilisant une
interface « <span class="quote">maison</span> » pour se connecter à une sorte de
concentrateur, essentiellement conçu comme le réseau de routage en
mailles utilisé dans le Paragon d'Intel. Des efforts considérables ont
été faits pour développer une électronique de « <span class="quote">communication
mappée en mémoire virtuelle</span> » aux
<span class="foreignphrase"><em class="foreignphrase">overheads</em></span> réduits, avec sa couche
logicielle.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10D08"></a>3.2.18. SLIP</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>pilotes du noyau</em></span>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>0,1 Mbits/s</em></span>
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>1000 microsecondes ?</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>grande distribution</em></span>
</p></li><li><p>
Interface ou bus utilisé : <span class="emphasis"><em>RS232C</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>câble entre deux machines</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>2 dollars</em></span>
</p></li></ul></div><p>
Même si SLIP (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Serial Line Interface
Protocol</em></span></span> ») se situe définitivement au pied de
l'échelle des performances, ce protocole (tout comme CSLIP ou PPP)
permet à deux machines de communiquer en utilisant les
« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">sockets</em></span></span> » et ce au travers
d'un câble RS232 ordinaire. Les ports RS232 peuvent être reliés à l'aide
d'un câble série type NULL-MODEM, ou même au travers d'une ligne
téléphonique en utilisant des modems. Dans tous les cas, les temps de
latence sont élevés, et la bande passante réduite. Aussi, SLIP ne
devrait être utilisé qu'en dernier recours. En revanche, la plupart des
PC sont dotés de deux ports RS232. Il doit donc être possible de relier
un groupe de machines sous forme de réseau linéaire ou d'anneau. Il
existe même un logiciel de répartition de la charge appelé EQL.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10D40"></a>3.2.19. TTL_PAPERS</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>bibliothèque AFAPI</em></span>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>1,6 Mbits/s</em></span>
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>3 microsecondes</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>conception dans le domaine public,
fabricant exclusif</em></span>
</p></li><li><p>
Interface ou bus utilisé : <span class="emphasis"><em>SPP (port parallèle)</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>arbre de concentrateurs</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>100 dollars</em></span>
</p></li></ul></div><p>
Le projet PAPERS (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Purdue's Adapter for Parallel
Execution and Rapid Synchronization</em></span></span> », soit
« <span class="quote">Adaptateur pour l'Exécution en Parallèle et la Synchronisation
Rapide de l'université de Purdue</span> »), mené par la Purdue University
School of Electrical and Computer Engineering (« <span class="quote">École Supérieure
d'Électricité et d'Ingénierie en Informatique</span> »), développe un
ensemble logiciel et matériel évolutif et aux temps de latence réduits
pour les communications des fonctions d'agrégation, permettant de mettre
sur pieds un supercalculateur en parallèle utilisant comme nœuds
des PC d'origine, non modifiés.
</p><p>
Plus d'une douzaine de versions de cartes « <span class="quote">PAPERS</span> », reliées
au PC à la station de travail via le port parallèle standard (SPP :
« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Standard Parallel Port</em></span></span> »),
ont été construites, en suivant globalement deux grands axes. Les
versions estampillées « <span class="quote">PAPERS</span> » visent les hautes
performances, quelle que soit la technologie la plus indiquée, la
version actuelle utilisant des FPGA (N.D.T. : famille de réseaux
logiques programmables), et des modèles d'interfaces PCI à haut débit
sont actuellement à l'étude. Par opposition, les versions nommées
« <span class="quote">TTL_PAPERS</span> » sont conçues pour être facilement reproduites
hors de l'université de Purdue, et s'appuient sur des modèles du domaine
public remarquablement simples et qui peuvent être mis en place en
utilisant de la logique TTL ordinaire. L'une de ces versions est
produite commercialement.
</p><p>
Contrairement au matériel sur mesure conçu par d'autres universités, des
<span class="foreignphrase"><em class="foreignphrase">clusters</em></span> TTL_PAPERS ont été assemblés
dans plusieurs écoles depuis les États-Unis jusqu'en Corée du Sud. La
bande passante est sévèrement limitée par la connectivité du port
parallèle, mais PAPERS met en œuvre des fonctions d'agrégation aux
temps de latence très réduits. Même les systèmes orientés messages les
plus rapides ne peuvent offrir de telles performances sur ces fonctions
d'agrégation. Ainsi, PAPERS est particulièrement performant dans la
synchronisation des différents écrans d'un mur vidéo (à débattre dans le
<span class="foreignphrase"><em class="foreignphrase">Video-Wall-HOWTO</em></span> actuellement en
préparation), pour planifier les accès à un réseau à haut débit, pour
évaluer les probabilités en recherche génétique, et cætera. Même si des
<span class="foreignphrase"><em class="foreignphrase">clusters</em></span> PAPERS ont été construits en
utilisant AIX d'IBM sur PowerPC, des DEC Alpha OSF/1, ou HP-UX sur HP
PA-RISC, le PC sous Linux reste la plate-forme la mieux prise en charge.
</p><p>
Les programmes utilisateur utilisant l'AFAPI de TTL_PAPERS attaquent
directement les registres matériels du port parallèle sous Linux, sans
effectuer d'appel système à chaque accès. Pour ce faire, l'AFAPI demande
d'abord les droits d'accès au port parallèle en utilisant soit
<code class="literal">iopl()</code>, soit <code class="literal">ioperm()</code>. Le problème
est que, l'un comme l'autre, ces appels obligent le programme appelant à
être privilégié, ce qui introduit une faille de sécurité potentielle. La
solution réside en un correctif optionnel à appliquer au noyau Linux et
permettant à un processus privilégié de contrôler les permissions
d'accès aux ports d'entrée/sortie pour n'importe quel autre processus.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10D9E"></a>3.2.20. USB (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Universal Serial Bus</em></span></span> »)</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>pilotes du noyau</em></span>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>12 Mbits/s</em></span>
</p></li><li><p>
Temps de latence minimum : <span class="emphasis"><em>?</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>dans le commerce</em></span>
</p></li><li><p>
Interface ou bus utilisé : <span class="emphasis"><em>USB</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>bus</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>5 dollars</em></span>
</p></li></ul></div><p>
USB (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Universal Serial Bus</em></span></span> »,
<a href="http://www.usb.org" target="_top">http://www.usb.org</a>) est un bus fonctionnant à la vitesse
de l'Ethernet conventionnel, dont les périphériques qui s'y rattachent
peuvent être connectés à chaud
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Hot-Plug</em></span></span> » : sans
imposer la mise hors tension préalable du bus) et pouvant accueillir simultanément
jusqu'à 127 de ces périphériques pouvant s'étendre du clavier à la
caméra de vidéo-conférence. La manière dont on relie plusieurs
ordinateurs par le biais de l'USB n'est pas clairement définie. Quoi
qu'il en soit, les ports USB sont en train de s'établir très rapidement
en standard sur les cartes-mères, au même titre que le port série RS232
ou le port parallèle, aussi ne soyez pas surpris si vous voyez
apparaître un ou deux ports USB <sup>[<a href="#ftn.N10DDD" name="N10DDD">20</a>]</sup> sur votre prochain PC.
</p><p>
D'une certaine manière, l'USB est pratiquement la version basse performance
à prix nul du FireWire que l'on peut se procurer aujourd'hui.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10DE3"></a>3.2.21. WAPERS</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
Prise en charge par Linux : <span class="emphasis"><em>bibliothèque AFAPI</em></span>
</p></li><li><p>
Bande passante maximum : <span class="emphasis"><em>0,4 Mbits/s</em></span>
</p></li><li><p>
Temps de latence : <span class="emphasis"><em>3 microsecondes</em></span>
</p></li><li><p>
Disponibilité : <span class="emphasis"><em>modèle dans le domaine public</em></span>
</p></li><li><p>
Interface ou bus utilisé : <span class="emphasis"><em>SPP (Port Parallèle Standard)</em></span>
</p></li><li><p>
Structure du réseau : <span class="emphasis"><em>modèle de câblage entre 2 à 64 machines</em></span>
</p></li><li><p>
Coût par machine connectée : <span class="emphasis"><em>5 dollars</em></span>
</p></li></ul></div><p>
WAPERS (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Wired-AND Adapter for Parallel Execution
and Rapid Synchronization</em></span></span> », soit
« <span class="quote">Adaptateur par ET Câblé pour l'Exécution en Parallèle et la
Synchronisation Rapide</span> ») est une des facettes du projet PAPERS,
de la Purdue University School of Electrical and Computer Engineering
(« <span class="quote">École Supérieure d'Électricité et d'Ingénierie en
Informatique</span> »). S'il est construit proprement, le port parallèle
possède quatre bits de sortie à collecteur ouvert qui peuvent être
câblés entre eux pour former un ET câblé de 4 bits de large. Ce ET câblé
est assez sensible électriquement, et le nombre maximum de machines qui
peuvent y être reliées dépend de façon critique des propriétés
analogiques des ports (les limites maximum des puits de courant et les
valeurs des résistances de <span class="foreignphrase"><em class="foreignphrase">pull-up</em></span>). On
peut typiquement relier 7 à 8 machines en réseau de cette façon, avec
WAPERS. Bien que les coûts et les temps de latences soient très réduits,
la bande passante l'est aussi. WAPERS est donc bien plus indiqué comme
réseau secondaire dédié aux fonctions d'agrégations que comme unique
réseau d'un <span class="foreignphrase"><em class="foreignphrase">cluster</em></span>. Comme pour
TTL_PAPERS, il existe un correctif noyau visant à améliorer la sécurité,
recommandé mais non requis.
</p></div></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a name="N10E23"></a>3.3. Interface Logicielle Réseau</h3></div></div></div><p>
Avant d'explorer les ressources logicielles existantes en matière de
traitement en parallèle, il est utile de couvrir rapidement les bases de
l'interface logicielle de bas niveau gérant l'électronique du réseau. Il
n'existe en réalité que trois options de base : les
<span class="foreignphrase"><em class="foreignphrase">sockets</em></span>, les pilotes de périphériques et
les bibliothèques utilisateur.
</p><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10E2B"></a>3.3.1. Les <span class="foreignphrase"><em class="foreignphrase">sockets</em></span></h4></div></div></div><p>
Le <span class="foreignphrase"><em class="foreignphrase">socket</em></span> est de loin la plus courante
des interfaces réseau de bas niveau. Les
<span class="foreignphrase"><em class="foreignphrase">sockets</em></span> sont partie intégrante d'Unix
depuis plus d'une décennie et la plupart des standards dans le domaine
du matériel électronique de réseau est conçue pour prendre en charge au
moins deux types de protocoles de
<span class="foreignphrase"><em class="foreignphrase">socket</em></span> : TCP et UDP. Ces deux types
de <span class="foreignphrase"><em class="foreignphrase">sockets</em></span> vous permettent d'envoyer des
blocs de données d'une longueur arbitraire d'une machine à l'autre, mais
il existe plusieurs différences importantes. Typiquement, ils engendrent
tous deux un temps de latence minimum d'environ 1000 microsecondes, même
si les performances peuvent bien pires encore en fonction du trafic.
</p><p>
Ces types de <span class="foreignphrase"><em class="foreignphrase">sockets</em></span> constituent
l'interface logicielle réseau de base pour la majorité des logiciels de
traitement en parallèle portables et de plus haut niveau. Par exemple,
PVM utilise une combinaison de l'UDP et du TCP, aussi en connaître les
différences vous aidera à affiner les performances de votre système. Ce
qui suit n'est qu'un aperçu de TCP et UDP. Référez-vous aux pages du
manuel et à un bon livre de programmation pour plus de détails.
</p><div class="sect4" lang="fr"><div class="titlepage"><div><div><h5 class="title"><a name="N10E43"></a>3.3.1.1. Le protocole UDP (SOCK_DGRAM)</h5></div></div></div><p>
<span class="emphasis"><em>UDP</em></span> signifie « <span class="quote"><span class="foreignphrase"><em class="foreignphrase">User Datagram
Protocol</em></span></span> » ou « <span class="quote">Protocole de Datagrammes
Utilisateur</span> » mais il est plus facile de se souvenir des
propriétés d'UDP en tant que « <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Unreliable Datagram
Processing</em></span></span> », ou « <span class="quote">Traitement des Datagrammes
Peu fiable</span> ». En d'autres termes, UDP permet à chaque bloc d'être
émis comme un message individuel, mais un message peut être perdu
pendant la transmission. De fait, selon l'état du trafic sur le réseau,
certains messages UDP peuvent être perdus, arriver plusieurs fois, ou
arriver dans un ordre différent de celui dans lequel ils ont été émis.
L'expéditeur d'un message UDP ne reçoit pas systématiquement d'accusé de
réception, et c'est donc au programme écrit par l'utilisateur qu'il
appartient de détecter et compenser ces problèmes. Heureusement, le
protocole UDP garantit que si un message arrive, son contenu sera intact
(c'est-à-dire que vous ne recevrez jamais un message incomplet).
</p><p>
Le bon coté de l'UDP est qu'il tend à être le plus rapide des protocoles
des <span class="foreignphrase"><em class="foreignphrase">socket</em></span>. En outre, UDP est
« <span class="quote">orienté hors connexion</span> »
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">connectionless</em></span></span> »), ce qui
signifie que chaque message est essentiellement indépendant des autres.
On peut comparer chaque message à une lettre à La Poste. Vous pouvez
envoyer plusieurs lettres à la même adresse, mais chacune d'entre elles
est indépendante des autres, et vous n'êtes pas limité quant aux nombre
de personnes à qui vous pouvez en envoyer.
</p></div><div class="sect4" lang="fr"><div class="titlepage"><div><div><h5 class="title"><a name="N10E65"></a>3.3.1.2. Le protocole TCP (SOCK_STREAM)</h5></div></div></div><p>
Contrairement à l'UDP, le <span class="emphasis"><em>TCP</em></span> est un protocole
fiable et orienté connexion. Chaque bloc est considéré non pas comme un
message, mais comme un bloc de données appartenant à un flot d'octets
voyageant au travers d'une connexion établie entre l'expéditeur et le
destinataire. Ce principe est très différent du système de messages de
l'UDP car chaque bloc n'est qu'une partie du flot d'octets, et il
appartient au programme utilisateur de trouver le moyen de les isoler
car il n'y a aucune marque de séparation pour les distinguer. De plus,
les connexions sont plus vulnérables aux perturbations du réseau, et
seul un nombre limité de connexions simultanées peut exister au sein
d'un même processus. Parce qu'il est fiable, le TCP engendre souvent des
<span class="foreignphrase"><em class="foreignphrase">overheads</em></span> plus importants que l'UDP.
</p><p>
Le TCP réserve en revanche quelques bonnes surprises. Par exemple, si
plusieurs messages sont envoyés à travers une connexion, TCP est capable
de les rassembler dans une mémoire tampon pour mieux correspondre aux
tailles standard des paquets de l'électronique du réseau, ce qui peut
donner de meilleurs résultats que l'UDP dans le cas de groupes de
messages courts ou de taille inhabituelle. Un autre avantage : Les
réseaux bâtis sur des connexions physiques directes entre deux machines
peuvent facilement et efficacement être assimilés à des connexions TCP.
Ce fut le cas pour la « <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Socket
Library</em></span></span> » (« <span class="quote">bibliothèque de gestion de
<span class="foreignphrase"><em class="foreignphrase">Sockets</em></span></span> »), présentant une gestion
compatible TCP au niveau de l'utilisateur qui ne différait des appels
systèmes TCP standard que par le préfixe <code class="literal">PSS</code>, que
l'on rajoutait au début du nom des fonctions à invoquer.
</p></div></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10E7F"></a>3.3.2. Les pilotes de périphériques</h4></div></div></div><p>
Lorsque l'on en arrive au stade où il faut effectivement injecter des
données sur le réseau ou les y en extraire, l'interface logicielle des
Unix standard fait partie du noyau et s'appelle « <span class="quote">pilote</span> »
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">driver</em></span></span> »). UDP et TCP ne se
contentent pas de transporter des données, ils s'accompagnent également
d'importants <span class="foreignphrase"><em class="foreignphrase">overheads</em></span> dus à la gestion
des <span class="foreignphrase"><em class="foreignphrase">sockets</em></span>. Par exemple, il faut que
quelque chose s'occupe du fait que plusieurs connexions TCP peuvent
partager la même interface réseau physique. Par opposition, un pilote de
périphérique dédié à une interface réseau n'a besoin de mettre en
œuvre qu'un petit nombre de fonctions de transport élémentaires.
Ces pilotes peuvent alors être invoqués à l'aide de l'appel
<code class="literal">open()</code> pour identifier le périphérique adéquat, puis
en utilisant par exemple <code class="literal">read()</code> et
<code class="literal">write()</code> sur le « <span class="quote">fichier</span> » ouvert. Ainsi,
chaque opération peut transporter un bloc de données en coûtant à peine
plus cher qu'un appel système, ce qui permet d'atteindre des délais de
l'ordre de quelques dizaines de microsecondes.
</p><p>
Écrire un pilote de périphérique pour Linux n'est pas difficile…
pourvu que vous sachiez <span class="emphasis"><em>parfaitement</em></span> comme
fonctionne votre périphérique. Si vous n'en êtes pas sûr, n'essayez pas
de le deviner. Déboguer un pilote de périphérique n'est pas une chose
amusante, et faire des erreurs peut coûter la vie à votre matériel. En
revanche, si ces risques ne vous effraient pas, il est possible d'écrire
un pilote pour, par exemple, utiliser des cartes Ethernet dédiées comme
des connexions machine-vers-machine « <span class="quote">bêtes</span> » mais très
rapides car exonérées du protocole Ethernet habituel. Pour être exact,
c'est pratiquement la technique utilisée par les premiers
supercalculateurs Intel. Référez-vous au
<span class="foreignphrase"><em class="foreignphrase">Device-Driver-HOWTO</em></span> pour plus
d'informations.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N10EAB"></a>3.3.3. Bibliothèques utilisateurs</h4></div></div></div><p>
Si vous avez pris des cours de programmation système, on a dù vous y
apprendre qu'accéder directement aux registres matériels des
périphériques à partir d'un programme utilisateur était l'exemple
typique de ce qu'il ne faut pas faire, parce que l'un des principes même
d'un système d'exploitation est de contrôler l'accès aux périphériques.
Cependant, le simple fait de passer un appel système coûte au minimum
quelques dizaines de microsecondes. Dans le cas d'interfaces réseau
bâties sur mesure comme TTL_PAPERS, qui peut effectuer des opérations de
base sur un réseau en seulement 3 microsecondes, un tel surcoût pour un
appel système est intolérable. Le seul moyen d'éviter ce temps d'attente
est de faire en sorte que du code s'exécutant au niveau de
l'utilisateur, donc une « <span class="quote">bibliothèque au niveau de
l'utilisateur</span> » <sup>[<a href="#ftn.N10EB3" name="N10EB3">21</a>]</sup>, puisse accéder directement au matériel, mais sans
remettre en cause la souveraineté du système d'exploitation sur la
gestion des droits d'accès aux ressources matérielles.
</p><p>
Sur un système typique, les seuls moyens, pour une bibliothèque utilisateur,
d'accéder directement aux registres du matériel sont les suivants :
</p><div class="orderedlist"><ol type="1"><li><p>
Au lancement du programme utilisateur, faire un appel système pour
mapper l'espace d'adressage qui contient les registres du périphérique
dans le plan mémoire du processus utilisateur. Sur certains systèmes,
l'appel système <code class="literal">mmap()</code> (traité pour la première fois
dans la section 2.6) peut être utilisé pour mapper un fichier spécial
représentant les adresses de la page de mémoire physique du
périphérique. Il est en même temps relativement simple d'écrire un
pilote de périphérique effectuant cette opération. De plus, ce pilote
peut obtenir l'accès en ne mappant que la ou les pages qui contiennent
les registres nécessaires, en maintenant ainsi le contrôle des droits
d'accès sous la coupe du système d'exploitation.
</p></li><li><p>
Accéder ensuite aux registres du périphérique sans passer par un appel
système en se contentant de charger ou de ranger des valeurs sur la
plage d'adressage mappée. Par exemple, un
<code class="literal">*((char *) 0x1234) = 5;</code>
déposera un octet de valeur 5 à l'adresse mémoire 1234 en hexadécimal.
</p></li></ol></div><p>
Par bonheur, il se trouve que Linux pour Intel 386 et compatibles
offre une solution meilleure encore :
</p><div class="orderedlist"><ol type="1"><li><p>
En invoquant l'appel système <code class="literal">ioperm()</code>
depuis un processus privilégié, obtenir la permission d'accéder
aux ports d'entrée/sortie correspondant précisément aux registres
du périphérique. Parallèlement, ces permissions peuvent être gérées
par un processus utilisateur privilégié et indépendant (autrement
dit : un « <span class="quote">méta-système d'exploitation</span> ») en utilisant l'appel
système <span class="emphasis"><em>giveioperm()</em></span>, disponible sous la
forme d'un correctif à appliquer au noyau
Linux.
</p></li><li><p>
Accéder aux registres du périphérique sans appel système en
utilisant les instructions assembleur d'accès aux ports
d'entrée/sortie du 386.
</p></li></ol></div><p>
Cette seconde solution est préférable car il arrive souvent que
les registres de plusieurs périphériques soient réunis sur une
même page, auquel cas la première méthode ne pourrait offrir
de protection contre l'accès aux autres registres résidant dans
la même page que ceux appartenant au périphérique concerné.
L'inconvénient est que ces instructions ne peuvent bien sûr pas
être écrites en langage C. Il vous faudra à la place utiliser
un peu d'assembleur. La fonction utilisant l'assembleur en ligne
intégré à GCC (donc utilisable dans les programmes C) permettant
de lire un octet depuis un port est la suivante :
</p><pre class="programlisting">
extern inline unsigned char
inb(unsigned short port)
{
unsigned char _v;
__asm__ __volatile__ ("inb %w1,%b0"
:"=a" (_v)
:"d" (port), "0" (0));
return _v;
}
</pre><p>
La fonction symétrique permettant l'émission d'un octet est :
</p><p>
<pre class="programlisting">
extern inline void
outb(unsigned char value,
unsigned short port)
{
__asm__ __volatile__ ("outb %b0,%w1"
:/* pas de valeur retournée */
:"a" (value), "d" (port));
}
</pre>
</p></div></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a name="N10EEF"></a>3.4. PVM (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Parallel Virtual Machine</em></span></span> »)</h3></div></div></div><p>
PVM (pour « <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Parallel Virtual
Machine</em></span></span> », soit « <span class="quote">Machine Virtuelle en
Parallèle</span> ») est une bibliothèque de
<span class="foreignphrase"><em class="foreignphrase">message-passing</em></span> portable et disponible
gratuitement, s'appuyant généralement directement sur les
<span class="foreignphrase"><em class="foreignphrase">sockets</em></span>. Cette bibliothèque s'est
incontestablement établie comme le standard <span class="foreignphrase"><em class="foreignphrase">de
facto</em></span> dans le domaine du traitement en parallèle à
l'aide de <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> à transmission de
messages.
</p><p>
PVM prend en charge les machines Linux monoprocesseur et SMP, comme les
<span class="foreignphrase"><em class="foreignphrase">clusters</em></span> de machines Linux reliées entre
elles à l'aide par des réseaux reconnaissant les
<span class="foreignphrase"><em class="foreignphrase">sockets</em></span> (donc SLIP, PLIP, Ethernet, ATM).
En fait, PVM fonctionnera même à travers un groupe de machines utilisant
différents types de processeurs, de configurations et de réseaux
physiques — Un <span class="emphasis"><em>cluster hétérogène</em></span> —
même si l'envergure de ce <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> est de
l'ordre de la mise en parallèle de machines en utilisant Internet pour
les relier entre elles. PVM offre même des facilités de contrôles de
tâches (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">jobs</em></span></span> ») en parallèle
au travers d'un <span class="foreignphrase"><em class="foreignphrase">cluster</em></span>. Cerise sur le
gâteau, PVM est disponible gratuitement et depuis longtemps
(actuellement sur <a href="http://www.epm.ornl.gov/pvm/pvm_home.html" target="_top">http://www.epm.ornl.gov/pvm/pvm_home.html</a>), ce qui a conduit bon
nombre de langages de programmation, de compilateurs, et d'outils de
débogage ou autres à l'adopter comme leur « <span class="quote">bibliothèque cible
portable de <span class="foreignphrase"><em class="foreignphrase">message-passing</em></span></span> ». Il
existe également un groupe de discussion : <a href="news:comp.parallel.pvm" target="_top">news:comp.parallel.pvm</a>.
</p><p>
Il est important de remarquer, en revanche, que les appels PVM ajoutent
généralement aux opérations <span class="foreignphrase"><em class="foreignphrase">socket</em></span> un
<span class="foreignphrase"><em class="foreignphrase">overhead</em></span> non négligeable alors que les
temps de latence de celles-ci sont déjà importants. En outre, les appels
eux-mêmes ne sont pas aisés à manipuler.
</p><p>
Appliquée au même exemple de calcul de Pi décrit en section 1.3,
la version PVM du programme en langage C est la suivante :
</p><pre class="programlisting">
#include <stdlib.h>
#include <stdio.h>
#include <pvm3.h>
#define NPROC 4
main(int argc, char **argv)
{
register double sommelocale, largeur;
double somme;
register int intervalles, i;
int mytid, iproc, msgtag = 4;
int tids[NPROC]; /* Tableau des numéros des tâches */
/* Début du traitement avec PVM */
mytid = pvm_mytid();
/* « Je rejoins le groupe et, si je suis la première instance,
iproc=0, je crée plusieurs copies de moi-même. »
*/
iproc = pvm_joingroup("pi");
if (iproc == 0) {
tids[0] = pvm_mytid();
pvm_spawn("pvm_pi", &argv[1], 0, NULL, NPROC-1, &tids[1]);
}
/* On s'assure que tous les processus sont prêts */
pvm_barrier("pi", NPROC);
/* Récupère le nombre d'intervalles */
intervalles = atoi(argv[1]);
largeur = 1.0 / intervalles;
sommelocale = 0.0;
for (i = iproc; i<intervalles; i+=NPROC) {
register double x = (i + 0.5) * largeur;
sommelocale += 4.0 / (1.0 + x * x);
}
/* On ajuste les résultats locaux en fonction de la largeur */
somme = sommlocale * largeur;
pvm_reduce(PvmSum, &sum, 1, PVM_DOUBLE, msgtag, "pi", 0);
/* Seul le processus rattaché à la console renvoie le résultat */
if (iproc == 0) {
printf("Estimation de la valeur de pi: %f\n", somme);
}
/* On attend que le programme soit terminé,
on quitte le groupe et
on sort de PVM. */
pvm_barrier("pi", NPROC);
pvm_lvgroup("pi");
pvm_exit();
return(0);
}
</pre></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a name="N10F38"></a>3.5. MPI (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Message Passing Interface</em></span></span> »)</h3></div></div></div><p>
Bien que PVM soit le standard de fait en matière de bibliothèque de
<span class="foreignphrase"><em class="foreignphrase">message-passing</em></span>, MPI
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Message Passing
Interface</em></span></span> ») tend à devenir le nouveau standard
officiel. Le site du standard MPI se trouve sur <a href="http://www.mcs.anl.gov:80/mpi/" target="_top">http://www.mcs.anl.gov:80/mpi/</a> et le groupe de discussion
correspondant sur <a href="news:comp.parallel.mpi" target="_top">news:comp.parallel.mpi</a>.
</p><p>
En revanche, avant d'explorer MPI, je me sens obligé de parler
rapidement de la guerre de religion qui oppose PVM à MPI et qui
dure depuis quelques années. Je ne penche ni pour l'un ni pour
l'autre. Voici un résumé aussi impartial que possible des
différences entre les deux interfaces :
</p><div class="variablelist"><dl><dt><span class="term">Environnement de contrôle de l'exécution</span></dt><dd><p>
Pour faire simple, PVM en a un, et MPI ne précise pas
s'il existe, ni comment il doit être implémenté. Cela
signifie que certaines choses comme lancer l'exécution
d'un programme PVM se fait de la même manière partout,
alors que pour MPI, cela dépend de l'implémentation
utilisée.
</p></dd><dt><span class="term">Prise en charge des <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> hétérogènes.</span></dt><dd><p>
PVM a grandi dans le monde de la collecte des cycles machines
inutilisés sur les stations de travail, et sait donc gérer donc
directement les mélanges hétérogènes de machines et de systèmes
d'exploitation. A contrario, MPI part du principe général que
la cible est un MPP (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Massively Parallel Processor</em></span></span> », soit
« <span class="quote">Processeur Massivement Parallèle</span> ») ou un <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> dédié
de stations de travail pratiquement toutes identiques.
</p></dd><dt><span class="term">Syndrome de l'évier.</span></dt><dd><p>
PVM se révèle être conçu pour une catégorie d'utilisation bien
définie, ce que MPI 2.0 ne fait pas. Le nouveau standard MPI 2.0
inclut une variété de fonctionnalités qui s'étendent bien au delà
du simple modèle de <span class="foreignphrase"><em class="foreignphrase">message-passing</em></span>, comme le RMA
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Remote Memory Access</em></span></span> », soit « <span class="quote">Accès Mémoire à Distance</span> ») ou les
opérations d'entrée/sortie en parallèle sur les fichiers. Toutes
ces choses sont-elles bien utiles ? Assurément… mais assimiler
MPI 2.0 est comparable à réapprendre depuis zéro un langage de
programmation totalement nouveau.
</p></dd><dt><span class="term">Conception de l'interface utilisateur.</span></dt><dd><p>
MPI a été conçu après PVM, et en a incontestablement tiré les leçons.
MPI offre une gestion des tampons plus simple et plus efficace et
une couche d'abstraction de haut-niveau permettant de transmettre
des données définies par l'utilisateur comme des messages.
</p></dd><dt><span class="term">Force de loi.</span></dt><dd><p>
Pour ce que j'ai pu en voir, il existe toujours plus d'applications
conçues autour de PVM qu'autour de MPI. Néanmoins, porter celles-ci
vers MPI est chose facile, et le fait que MPI soit soutenu par un
standard formel très répandu signifie que MPI est, pour un certain nombre
d'institutions, une question de vision des choses.
</p></dd></dl></div><p>
Conclusion ? Disons qu'il existe au moins trois versions de MPI
développées de façon indépendante et disponibles gratuitement pouvant
fonctionner sur des <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> de machines Linux (et j'ai écrit l'un
d'eux) :
</p><div class="itemizedlist"><ul type="disc"><li><p>
LAM (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Local Area Multicomputer</em></span></span> », soit « <span class="quote">MultiOrdinateur Local</span> »)
est une mise en œuvre complète du standard 1.1. Il permet aux programmes
MPI de s'exécuter sur un système Linux individuel ou au travers d'un
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> de systèmes Linux communiquant par le biais de <span class="foreignphrase"><em class="foreignphrase">sockets</em></span> TCP/UDP.
Le système inclut des facilités de base de contrôle de l'exécution, ainsi que
toute une gamme d'outils de développement et de débogage de programmes.
</p></li><li><p>
MPICH (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">MPI CHameleon</em></span></span> ») est
conçu pour être une implémentation complète et hautement portable du
standard MPI 1.1. Tout comme LAM, il permet aux programmes MPI d'être
exécutés sur des systèmes Linux individuels ou en
<span class="foreignphrase"><em class="foreignphrase">clusters</em></span> via une communication par
<span class="foreignphrase"><em class="foreignphrase">socket</em></span> TCP/UDP. En revanche, l'accent est
porté sur la promotion de MPI en fournissant une implémentation efficace
et facilement repositionnable. Pour porter cette implémentation, il faut
réimplémenter soit les cinq fonctions de la « <span class="quote">channel
interface</span> », soit, pour de meilleures performances, la totalité de
l'ADI (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Abstract Device
Interface</em></span></span> », soit « <span class="quote">Interface Périphérique
Abstraite</span> »). MPICH, et beaucoup d'informations concernant ce
sujet et la façon de le porter, sont disponibles sur <a href="http://www.mcs.anl.gov/mpi/mpich/" target="_top">http://www.mcs.anl.gov/mpi/mpich/</a>.
</p></li><li><p>
AFMPI (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Aggregate Function
MPI</em></span></span> ») est une sous-implémentation du standard MPI
2.0. C'est celle que j'ai écrite. S'appuyant sur AFAPI, elle est conçue
pour être la vitrine des RMA et des fonctions de communications
collectives, et n'offre donc qu'un soutien minimal des types MPI, de ses
systèmes de communication, et cætera. Elle permet à des programmes C
utilisant MPI d'être exécutés sur un système Linux individuel ou au
travers d'un <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> mis en réseau par du
matériel pouvant prendre en charge l'AFAPI.
</p></li></ul></div><p>
Quelque soit l'implémentation MPI utilisée, il est toujours très simple
d'effectuer la plupart des types de communication.
</p><p>
En revanche, MPI 2.0 incorpore plusieurs paradigmes de communication
suffisamment différents entre eux fondamentalement pour qu'un programmeur
utilisant l'un d'entre eux puisse ne même pas reconnaître les autres
comme étant des styles de programmation MPI. Aussi, plutôt que d'explorer
un seul exemple de programme, il est utile de passer en revue un exemple de chacun
des (différents) paradigmes de communication de MPI. Tous les programmes
qui suivent emploient le même algorithme (celui de la section 1.3)
utilisé pour calculer Pi.
</p><p>
Le premier programme MPI utilise les appels de <span class="foreignphrase"><em class="foreignphrase">message-passing</em></span> MPI sur
chaque processeur pour que celui-ci renvoie son résultat partiel au
processeur 0, qui fait la somme de tous ces résultats et la renvoie à
l'écran :
</p><p>
<pre class="programlisting">
#include <stdlib.h>
#include <stdio.h>
#include <mpi.h>
main(int argc, char **argv)
{
register double largeur;
double somme, sommelocale;
register int intervalles, i;
int nproc, iproc;
MPI_Status status;
if (MPI_Init(&argc, &argv) != MPI_SUCCESS) exit(1);
MPI_Comm_size(MPI_COMM_WORLD, &nproc);
MPI_Comm_rank(MPI_COMM_WORLD, &iproc);
intervalles = atoi(argv[1]);
largeur = 1.0 / intervalles;
sommelocale = 0;
for (i=iproc; i<intervalles; i+=nproc) {
register double x = (i + 0.5) * largeur;
sommelocale += 4.0 / (1.0 + x * x);
}
sommelocale *= largeur;
if (iproc != 0) {
MPI_Send(&lbuf, 1, MPI_DOUBLE, 0, 0, MPI_COMM_WORLD);
} else {
somme = sommelocale;
for (i=1; i<nproc; ++i) {
MPI_Recv(&lbuf, 1, MPI_DOUBLE, MPI_ANY_SOURCE,
MPI_ANY_TAG, MPI_COMM_WORLD, &status);
somme += sommelocale;
}
printf("Estimation de la valeur de pi: %f\n", somme);
}
MPI_Finalize();
return(0);
}
</pre>
</p><p>
Le second programme MPI utilise les communications collectives (qui,
pour ce cas précis, sont incontestablement les plus appropriées) :
</p><p>
<pre class="programlisting">
#include <stdlib.h>
#include <stdio.h>
#include <mpi.h>
main(int argc, char **argv)
{
register double largeur;
double somme, sommelocale;
register int intervalles, i;
int nproc, iproc;
if (MPI_Init(&argc, &argv) != MPI_SUCCESS) exit(1);
MPI_Comm_size(MPI_COMM_WORLD, &nproc);
MPI_Comm_rank(MPI_COMM_WORLD, &iproc);
intervalles = atoi(argv[1]);
largeur = 1.0 / intervalles;
sommelocale = 0;
for (i=iproc; i<intervalles; i+=nproc) {
register double x = (i + 0.5) * largeur;
sommelocale += 4.0 / (1.0 + x * x);
}
sommelocale *= largeur;
MPI_Reduce(&sommelocale, &somme, 1, MPI_DOUBLE,
MPI_SUM, 0, MPI_COMM_WORLD);
if (iproc == 0) {
printf("Estimation de la valeur de pi: %f\n", somme);
}
MPI_Finalize();
return(0);
}
</pre>
</p><p>
La troisième version MPI utilise le mécanisme RMA de MPI 2.0 sur chaque processeur
pour ajouter la valeur locale de la variable <code class="literal">sommelocale</code> de ce dernier
à la variable <code class="literal">somme</code> du processeur 0 :
</p><p>
<pre class="programlisting">
#include <stdlib.h>
#include <stdio.h>
#include <mpi.h>
main(int argc, char **argv)
{
register double largeur;
double somme = 0, sommelocale;
register int intervalles, i;
int nproc, iproc;
MPI_Win somme_fen;
if (MPI_Init(&argc, &argv) != MPI_SUCCESS) exit(1);
MPI_Comm_size(MPI_COMM_WORLD, &nproc);
MPI_Comm_rank(MPI_COMM_WORLD, &iproc);
MPI_Win_create(&somme, sizeof(somme), sizeof(somme),
0, MPI_COMM_WORLD, &somme_fen);
MPI_Win_fence(0, somme_fen);
intervalles = atoi(argv[1]);
largeur = 1.0 / intervalles;
sommelocale = 0;
for (i=iproc; i<intervalles; i+=nproc) {
register double x = (i + 0.5) * largeur;
sommelocale += 4.0 / (1.0 + x * x);
}
sommelocale *= largeur;
MPI_Accumulate(&sommelocale, 1, MPI_DOUBLE, 0, 0,
1, MPI_DOUBLE, MPI_SUM, somme_fen);
MPI_Win_fence(0, somme_fen);
if (iproc == 0) {
printf("Estimation de la valeur de pi: %f\n", somme);
}
MPI_Finalize();
return(0);
}
</pre>
</p><p>
Il est utile de préciser que le mécanisme RMA de MPI 2.0 prévient
de façon remarquable tout problème de structures de données se trouvant
à des adresses mémoires différentes selon les processeurs, en se référant
à une "fenêtre" incluant l'adresse de base, une protection contre les
accès mémoire hors de portée, et même le rééchelonnement d'adresse. À une
implémentation efficace, s'ajoute le fait qu'un traitement RMA peut-être
reporté jusqu'à la prochaine <code class="literal">MPI__Win_fence</code>.
Pour faire simple, le mécanisme RMA est un étrange croisement entre
mémoire partagée distribuée et <span class="foreignphrase"><em class="foreignphrase">message passing</em></span>,
mais reste une interface très propre pouvant générer des communications très efficaces.
</p></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a name="N10FF0"></a>3.6. AFAPI (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Aggregate Function API</em></span></span> »)</h3></div></div></div><p>
Contrairement à PVM, MPI, et cætera, l'interface AFAPI
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Aggregate Function API</em></span></span> »,
ou « <span class="quote">Interface à Fonctions d'Agrégation</span> ») n'a pas débuté sa
vie en tant que couche d'abstraction portable s'appuyant sur un réseau
matériel ou logiciel existant. AFAPI était plutôt la bibliothèque de
gestion bas niveau d'un matériel spécifique pour PAPERS
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Purdue's Adapter for Parallel Execution and Rapid
Synchronization</em></span></span> », soit « <span class="quote">Adaptateur pour
l'Exécution en Parallèle et la Synchronisation Rapide de l'université de
Purdue</span> »).
</p><p>
PAPERS a été rapidement présenté dans la section 3.2. Il s'agit d'un
réseau à fonction d'agrégations conçu sur mesure dont le modèle est dans
domaine public et qui présente des temps de latence inférieurs à quelques
microsecondes. Mais surtout, il s'agit de la tentative de construction
d'un supercalculateur formant une meilleure cible pour la technologie des
compilateurs que les supercalculateurs déjà existants. Il se distingue
en qualité de la plupart des efforts en matière de <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> Linux et de
PVM/MPI, qui s'attachent généralement à essayer d'exploiter les réseaux
standard au profit des rares applications en parallèle présentant une
granularité suffisante. Le fait que les éléments de PAPERS soient des
machines PC sous Linux ne sert qu'à permettre l'implémentation de
prototypes à des coûts les plus avantageux possibles.
</p><p>
La nécessité d'avoir une interface logicielle de bas niveau commune à
plus d'une douzaine d'implémentations différentes d'un prototype a
conduit la bibliothèque PAPERS à être standardisée sous le nom d'AFAPI.
Mais le modèle utilisé par AFAPI est simple en lui-même et bien plus
adapté aux interactions à la granularité plus fine, typiquement du code
compilé par des compilateurs parallélisés, ou écrit pour des architectures
SIMD. Non seulement la simplicité du modèle rend les machines PAPERS
aisées à construire, mais elle apporte également une efficacité surprenante
aux ports d'AFAPI sur différents types de système, tels que les SMP.
</p><p>
AFAPI fonctionne actuellement sur des <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> Linux utilisant TTL_PAPERS,
CAPERS ou WAPERS. Elle fonctionne également (sans appel système ni même
instruction de verrouillage de bus, voir la section 2.2) sur les machines
SMP utilisant une bibliothèque de gestion de mémoire partagée type System V
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">System V Shared Memory</em></span></span> ») appelée SHMAPERS. Une version fonctionnant sur
des <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> Linux utilisant la diffusion UDP sur des réseaux conventionnels
(Ex : Ethernet) est en cours de développement. Toutes les versions d'AFAPI sont écrites
pour être appelées à partir des langages C ou C++.
</p><p>
L'exemple suivant est la version AFAPI du programme de calcul de
Pi décrit dans la section 1.3.
</p><p>
<pre class="programlisting">
#include <stdlib.h>
#include <stdio.h>
#include "afapi.h"
main(int argc, char **argv)
{
register double largeur, somme;
register int intervalles, i;
if (p_init()) exit(1);
intervalles = atoi(argv[1]);
largeur = 1.0 / intervalles;
sum = 0;
for (i=IPROC; i<intervalles; i+=NPROC) {
register double x = (i + 0.5) * largeur;
somme += 4.0 / (1.0 + x * x);
}
somme = p_reduceAdd64f(somme) * largeur;
if (IPROC == CPROC) {
printf("Estimation de la valeur de pi: %f\n", somme);
}
p_exit();
return(0);
}
</pre>
</p></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a name="N11022"></a>3.7. Autres bibliothèques de gestion de <span class="foreignphrase"><em class="foreignphrase">clusters</em></span></h3></div></div></div><p>
Outre PVM, MPI et AFAPI, les bibliothèques suivantes proposent des
services qui peuvent s'avérer utiles au travers de grappes de machines
Linux. Ces systèmes sont traités ici de manière moins approfondie
simplement parce que, contrairement à PVM, MPI et AFAPI, je n'ai que
peu, voire aucune expérience pratique de l'utilisation de ceux-ci sur
des <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> Linux. Si l'une de ces
bibliothèques (ou même d'autres) vous est particulièrement utile, merci
de m'envoyer un courrier électronique en anglais à
<code class="email"><<a href="mailto:hankd CHEZ engr POINT uky POINT edu">hankd CHEZ engr POINT uky POINT edu</a>></code>
en me détaillant vos découvertes. J'envisagerai alors d'ajouter une
section plus complète à son sujet.
</p><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N1102F"></a>3.7.1. Condor (migration de processus)</h4></div></div></div><p>
Condor est un système de gestion de ressources distribuées qui peut
diriger de vastes <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> de stations de
travail hétérogènes. Sa conception a été motivée par les besoins des
utilisateurs souhaitant utiliser la puissance inexploitée de tels
<span class="foreignphrase"><em class="foreignphrase">clusters</em></span> au profit de leurs tâches aux
temps d'exécution prolongés et aux calculs intensifs. Condor reproduit
dans une large mesure l'environnement de la machine initiale sur celle
qui exécute le processus, même si ces deux machines ne partagent pas un
système de fichier ou un mécanisme de mot de passe communs. Les tâches
sous Condor qui se résument à un processus unique sont automatiquement
interceptées et déplacées entre les différentes stations en fonctions
des besoins pour les mener à terme.
</p><p>
Condor est disponible sur <a href="http://www.cs.wisc.edu/condor/" target="_top">http://www.cs.wisc.edu/condor/</a>.
Une version Linux existe également. Contactez l'administrateur du site,
<code class="email"><<a href="mailto:condor TIRET admin CHEZ cs POINT wisc POINT edu">condor TIRET admin CHEZ cs POINT wisc POINT edu</a>></code>,
pour plus de détails.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N11042"></a>3.7.2. DFN-RPC (Réseau Allemand de la Recherche — « <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Remote Procedure Call</em></span></span> »)</h4></div></div></div><p>
Le DFN-RPC (un outil du Réseau Allemand de la Recherche —
« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Remote Procedure Call</em></span></span> ») a
été développé pour distribuer et paralléliser des applications d'intéret
scientifique ou technique entre une station de travail et un serveur de
calcul ou un <span class="foreignphrase"><em class="foreignphrase">cluster</em></span>. L'interface est
optimisée pour les applications écrites en Fortran, mais le DFN-RPC peut
aussi être utilisé dans un environnement de langage C. Une version Linux
a été écrite. Plus d'information sur <a href="ftp://ftp.uni-stuttgart.de/pub/rus/dfn_rpc/README_dfnrpc.html" target="_top">ftp://ftp.uni-stuttgart.de/pub/rus/dfn_rpc/README_dfnrpc.html</a>.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N11055"></a>3.7.3. DQS (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Distributed Queueing System</em></span></span> »)</h4></div></div></div><p>
Pas vraiment une bibliothèque, DQS 3.0 (« <span class="quote">Distributed Queueing
System</span> », soit « <span class="quote">Système de Files d'attente
Distribuées</span> ») est un système de mise en file d'attente des tâches
qui a été développé et testé sous Linux. Ce système a été conçu pour
permettre à la fois l'utilisation et l'administration d'un
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> de machines hétérogènes comme une
seule entité. Disponible sur <a href="http://www.scri.fsu.edu/~pasko/dqs.html" target="_top">http://www.scri.fsu.edu/~pasko/dqs.html</a>.
</p><p>
Il existe aussi une version commerciale nommée CODINE 4.1.1 (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">COmputing in
DIstributed Network Environments</em></span></span> », soit « <span class="quote">CAlcul en Environnement Réseau Distribué</span> »).
</p></div></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a name="N11073"></a>3.8. Références générales aux <span class="foreignphrase"><em class="foreignphrase">clusters</em></span></h3></div></div></div><p>
Les <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> peuvent être construits et utilisés de tellement
de manières différentes que certains groupes ont apporté des
contributions particulièrement intéressantes. Ce qui suit fait référence aux
différents projets liés à la mise en place de <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> pouvant
avoir un intérêt d'ordre général. Ceci inclut un mélange de
références à des <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> spécifiques à Linux et à des <span class="foreignphrase"><em class="foreignphrase">clusters</em></span>
génériques. Cette liste est présentée dans l'ordre alphabétique.
</p><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N11086"></a>3.8.1. Beowulf</h4></div></div></div><p>
Le projet <a href="http://www.beowulf.org/" target="_top">Beowulf</a>, se
focalise sur la production de logiciels pour une utilisation de stations
de travail immédiatement disponibles basée sur du matériel PC de grande
distribution, un réseau à haut débit interne au
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span>, et le système d'exploitation
Linux.
</p><p>
Thomas Sterling a été le principal acteur de Beowulf, et continue
d'être un promoteur franc et éloquent de l'utilisation de <span class="foreignphrase"><em class="foreignphrase">clusters</em></span>
Linux dans le domaine du calcul scientifique en général. À vrai dire,
plusieurs groupes parlent à présent de leur <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> comme de système
de « <span class="quote">classe Beowulf</span> », et ce même si la conception de ce <span class="foreignphrase"><em class="foreignphrase">cluster</em></span>
s'éloigne du modèle Beowulf officiel.
</p><p>
Don Becker, apportant son appui au projet Beowulf, a produit nombre
des pilotes réseau utilisés par Linux en général. Plusieurs de ces
pilotes ont même été adaptés pour être utilisés sous BSD. C'est
également à Don que l'on doit la possibilité, pour certains pilotes,
de répartir le trafic réseau à travers plusieurs connexions parallèles
pour augmenter les taux de transfert sans utiliser d'onéreux commutateurs.
Ce type de répartition de la charge réseau était le principal atout des
<span class="foreignphrase"><em class="foreignphrase">clusters</em></span> Beowulf.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N110A5"></a>3.8.2. Linux/AP+</h4></div></div></div><p>
Le projet <a href="http://cap.anu.edu.au/cap/projects/linux" target="_top">Linux/AP+</a> ne
concerne pas exactement le <span class="emphasis"><em>clustering</em></span> sous Linux,
mais s'attache à faire fonctionner Linux sur l'AP1000+ de Fujitsu, et à
y apporter les améliorations appropriées en matière de traitement en
parallèle. L'AP1000+ est une machine en parallèle à base de SPARC et
disponible dans le commerce, utilisant un réseau spécifique avec une
topologie en tore, un taux de transfert de 25Mo/s et un temps de latence
de 10 microsecondes… Pour faire court, cela ressemble beaucoup à
un <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> Linux SPARC.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N110B4"></a>3.8.3. Locust</h4></div></div></div><p>
Le projet Locust est en train de mettre au point un système de mémoire partagée
virtuelle qui utilise les informations obtenues à la compilation pour
masquer les temps de latence des messages et réduire le trafic réseau
lors de l'exécution. « <span class="quote">Pupa</span> » forme la base du système de communication de
Locust, et est implémenté à l'aide d'un réseau Ethernet reliant des
machines PC 486 sous FreeBSD. Et Linux ?
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N110BC"></a>3.8.4. Midway DSM (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Distributed Shared Memory</em></span></span> »)</h4></div></div></div><p>
<a href="http://www.cs.cmu.edu/afs/cs.cmu.edu/project/midway/WWW/HomePage.html" target="_top">Midway</a> est une DSM (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Distributed Shared Memory</em></span></span> »,
soit « <span class="quote">Mémoire Partagée Distribuée</span> ») logicielle, similaire à TreadMarks.
Le bon coté réside en l'utilisation d'indications à la compilation plutôt que de relativement
lents mécanismes d'erreur de page, et en sa gratuité. Le mauvais coté est cela ne fonctionne
pas sur des <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> Linux.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N110D3"></a>3.8.5. Mosix</h4></div></div></div><p>
MOSIX apporte des modifications au système d'exploitation BSD
« <span class="quote">BSDI</span> » pour proposer une répartition de charge réseau
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">load balancing</em></span></span> ») dynamique
et une migration de processus préemptive au travers d'un groupe de PC
mis en réseau. C'est un système très utile non seulement pour le
traitement en parallèle, mais d'une manière générale pour utiliser un
<span class="foreignphrase"><em class="foreignphrase">cluster</em></span> comme une machine SMP évolutive.
Y aura-t-il une version Linux ? Voyez <a href="http://www.mosix.org" target="_top">http://www.mosix.org</a> pour plus d'informations<sup>[<a href="#ftn.N110E5" name="N110E5">22</a>]</sup>.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N110E9"></a>3.8.6. NOW (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Network Of Workstations</em></span></span> »)</h4></div></div></div><p>
Le projet NOW (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Network Of Workstations</em></span></span> », ou « <span class="quote">Réseau de Stations de Travail</span> ») de l'université de Berkeley (<a href="http://now.cs.berkeley.edu/" target="_top">http://now.cs.berkeley.edu</a>) a conduit dans une large mesure l'effort pour le calcul en
parallèle en utilisant des réseaux de stations de travail. Bon
nombre de travaux sont menés là-bas, tous tournés vers la
« <span class="quote">démonstration en pratique d'un système à 100 processeurs dans
les prochaines années</span> ». Hélas, ils n'utilisent pas Linux.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N11100"></a>3.8.7. Traitement en parallèle avec Linux</h4></div></div></div><p>
Le site web du « <span class="quote">Traitement en parallèle avec Linux</span> »
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Parallel processing using Linux</em></span></span> »), sur <a href="http://yara.ecn.purdue.edu/~pplinux" target="_top">http://yara.ecn.purdue.edu/~pplinux</a>>, est le site officiel
de ce guide pratique et de plusieurs documents en rapport avec ce thème,
y compris des présentations en ligne.
Parallèlement aux travaux du projet PAPERS, l'École Supérieure
d'Électricité et d'Informatique de Purdue (« <span class="quote">Purdue
University School of Electrical and Computer Engineering</span> ») reste
un leader en matière de traitement en parallèle. Ce site a été
mis en place pour aider les autres à utiliser des PC sous Linux
pour faire du traitement en parallèle.
</p><p>
Depuis l'assemblage du premier <span class="foreignphrase"><em class="foreignphrase">cluster</em></span> de PC Linux en février 1994,
bien d'autres furent également assemblés à Purdue, dont plusieurs
équipés de murs vidéos. Bien que ces <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> s'appuyaient sur des
machines à base de microprocesseurs 386, 486 ou Pentium (mais pas de
Pentium Pro), Intel a récemment accordé à Purdue une donation qui lui
permettra de construire plusieurs grands <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> de systèmes à
Pentium II (avec pas moins de 165 machines par <span class="foreignphrase"><em class="foreignphrase">cluster</em></span>). Même si
tous ces <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> sont ou seront équipés de réseaux PAPERS, la plupart
sont également dotés de réseaux conventionnels.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N11124"></a>3.8.8. Pentium Pro Cluster Workshop</h4></div></div></div><p>
Les 10 et 11 avril 1997, le laboratoire AMES a tenu à Des Moines,
dans l'état de l'Iowa aux États-Unis, le « <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Pentium Pro Cluster
Workshop</em></span></span> » (« <span class="quote">Atelier de <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> Pentium Pro</span> »). Le site web
de cet atelier, <a href="http://www.scl.ameslab.gov" target="_top">http://www.scl.ameslab.gov</a>, renferme une mine d'informations concernant les <span class="foreignphrase"><em class="foreignphrase">clusters</em></span> PC,
glanées auprès de tous les participants.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N1113A"></a>3.8.9. TreadMarks DSM (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Distributed Shared Memory</em></span></span> »)</h4></div></div></div><p>
La DSM (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Distributed Shared
Memory</em></span></span> », ou « <span class="quote">Mémoire Partagée
Distribuée</span> ») est une technique avec laquelle un système de
<span class="foreignphrase"><em class="foreignphrase">message-passing</em></span> peut se présenter et agir
comme un SMP. Il existe quelques systèmes de ce genre, la plupart
utilisant les mécanismes d'erreur de page du système d'exploitation pour
déclencher la transmission des messages. <a href="http://www.cs.rice.edu/~willy/TreadMarks/overview.html" target="_top">TreadMarks</a>
est l'un des plus efficaces, et fonctionne sur les
<span class="foreignphrase"><em class="foreignphrase">clusters</em></span> Linux. La mauvaise nouvelle est
que « <span class="quote">TreadMarks est distribué à un coût réduit aux universités et
organisations à but non lucratif</span> ». Pour plus d'informations
concernant le logiciel, prenez contact (en anglais) avec
<code class="email"><<a href="mailto:tmk CHEZ cs POINT rice POINT edu">tmk CHEZ cs POINT rice POINT edu</a>></code>.
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N1115A"></a>3.8.10. U-Net (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">User-level NETwork interface architecture</em></span></span> »)</h4></div></div></div><p>
Le projet U-Net (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">User-level NETwork interface
architecture</em></span></span> », ou « <span class="quote">Architecture d'interface
Réseau au Niveau Utilisateur</span> »), accessible sur <a href="http://www.eecs.harvard.edu/~mdw/proj/old/unet" target="_top">http://www.eecs.harvard.edu/~mdw/proj/old/unet</a>, tente d'apporter
temps de latence réduits et taux de transfert élevés sur du matériel
réseau du commerce en virtualisant les interfaces réseau de manière à ce
que les applications puissent envoyer et recevoir des messages sans
passer par un appel système. U-Net fonctionne sur des PC Linux en
utilisant du matériel Fast Ethernet basé sur une puce DEC DC21140, ou
une carte ATM Fore Systems PCA-200 (mais pas PCA-200E).
</p></div><div class="sect3" lang="fr"><div class="titlepage"><div><div><h4 class="title"><a name="N1116D"></a>3.8.11. WWT (« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Wisconsin Wind Tunnel</em></span></span> »)</h4></div></div></div><p>
On trouve bon nombre de projets relatifs à l'utilisation de
<span class="foreignphrase"><em class="foreignphrase">clusters</em></span> dans le Wisconsin. Le projet WWT
(« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Wisconsin Wind Tunnel</em></span></span> », ou
« <span class="quote">Soufflerie du Wisconsin</span> »), sur <a href="http://www.cs.wisc.edu/~wwt/" target="_top">http://www.cs.wisc.edu/~wwt/</a>, mène toutes sortes de travaux
orientés vers le développement d'une interface « <span class="quote">standard</span> »
entre les compilateurs et le matériel réseau sur lequel ils s'appuient.
Il existe le « <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Wisconsin COW</em></span></span> »
(pour « <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Cluster Of
Workstation</em></span></span> »), « <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Cooperative
Shared Memory</em></span></span> » et
« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Tempest</em></span></span> », le
« <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Paradyn Parallel Performance
Tools</em></span></span> », et cætera. Malheureusement, il n'y a pas
grand chose concernant Linux.
</p></div></div><div class="footnotes"><br><hr align="left" width="100"><div class="footnote"><p><sup>[<a href="#N107AC" name="ftn.N107AC">10</a>] </sup>
N.D.T. : il semble que ce panel ne soit plus mis à jour depuis un
certain temps. Le site suggéré proposait à la date de rédaction de la
version française le bulletin le plus récent, mais n'est pas officiel.
</p></div><div class="footnote"><p><sup>[<a href="#N109FA" name="ftn.N109FA">11</a>] </sup>
N.D.T. : désormais intégré aux sources du noyau.
</p></div><div class="footnote"><p><sup>[<a href="#N10A0B" name="ftn.N10A0B">12</a>] </sup>
N.D.T. : les pilotes FC pour le noyau Linux ont en fait été écrits
en 1999.
</p></div><div class="footnote"><p><sup>[<a href="#N10A3B" name="ftn.N10A3B">13</a>] </sup>
N.D.T. : La <span class="foreignphrase"><em class="foreignphrase">Fibre Channel
Association</em></span> (FCA) et la <span class="foreignphrase"><em class="foreignphrase">Fibre Channel
Loop Community</em></span> (FCLC) ont fusionné en 2000 pour former
la <span class="foreignphrase"><em class="foreignphrase">Fibre Channel Industry Association</em></span>.
</p></div><div class="footnote"><p><sup>[<a href="#N10A53" name="ftn.N10A53">14</a>] </sup>
N.D.T. : les premiers pilotes FireWire pour Linux ont été écrits en
1999 mais, bien que disponibles en standard, sont toujours considérés
comme expérimentaux.
</p></div><div class="footnote"><p><sup>[<a href="#N10A9D" name="ftn.N10A9D">15</a>] </sup>
N.D.T. : HiPPI est aujourd'hui pris en charge par Linux, mais de
façon restreinte et expérimentale.
</p></div><div class="footnote"><p><sup>[<a href="#N10AEE" name="ftn.N10AEE">16</a>] </sup>
N.D.T. : l'IrDA est pris en charge par le noyau depuis 2000.
</p></div><div class="footnote"><p><sup>[<a href="#N10B60" name="ftn.N10B60">17</a>] </sup>
SAN : « <span class="quote"><span class="foreignphrase"><em class="foreignphrase">System Area
Network</em></span></span> ».
</p><p>
N.D.T. : à ne pas confondre avec « <span class="quote"><span class="foreignphrase"><em class="foreignphrase">Storage Area
Network</em></span></span> », qui partage le même acronyme.
</p></div><div class="footnote"><p><sup>[<a href="#N10C39" name="ftn.N10C39">18</a>] </sup>
N.D.T. : Sequent a été absorbé par IBM en septembre 1999.
</p></div><div class="footnote"><p><sup>[<a href="#N10CC0" name="ftn.N10CC0">19</a>] </sup>
N.D.T. : et donc désormais à Hewlett-Packard.
</p></div><div class="footnote"><p><sup>[<a href="#N10DDD" name="ftn.N10DDD">20</a>] </sup>
N.D.T. : les ports et le standard USB sont aujourd'hui parfaitement
reconnus par Linux.
</p></div><div class="footnote"><p><sup>[<a href="#N10EB3" name="ftn.N10EB3">21</a>] </sup>
N.D.T. : par opposition à un « <span class="quote">appel système</span> », donc sans franchir
la barrière du passage en mode noyau.
</p></div><div class="footnote"><p><sup>[<a href="#N110E5" name="ftn.N110E5">22</a>] </sup>
N.D.T. : MOSIX fonctionne aujourd'hui sous Linux.
</p></div></div></div><div class="navfooter"><hr><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="ar01s02.html">Précédent</a> </td><td align="center" width="20%"> </td><td align="right" width="40%"> <a accesskey="n" href="ar01s04.html">Suivant</a></td></tr><tr><td valign="top" align="left" width="40%">2. Linux sur SMP </td><td align="center" width="20%"><a accesskey="h" href="index.html">Sommaire</a></td><td valign="top" align="right" width="40%"> 4. SIMD <span class="foreignphrase"><em class="foreignphrase">Within A Register</em></span> : SWAR (Ex : utilisation de MMX)</td></tr></table></div></body></html>
