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 hubs. 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'ARCNET Trade Association.

A moins d'avoir été dans le coma ces dernières années, vous avez sûrement beaucoup entendu dire qu'ATM (« Asynchronous Transfer Mode ») est 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 http://linux-atm.sourceforge.net/.

CAPERS (« Cable Adapter for Parallel Execution and Rapid Synchronisation » : « Adaptateur par Câble pour l'Exécution en Parallèle et la Synchronisation Rapide ») est un produit dérivé du projet PAPERS, de l'University School of Electrical and Computer Engineering 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 « LapLink », 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.

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 (« hub »). 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 (« switches »), 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 Guide pratique de la compatibilité matérielle avec Linux (N.D.T. : version française du Hardware Compatibility HOWTO ) pour plus d'informations concernant les différents équipements fonctionnant sous Linux, et pour avoir une idée de leur qualité.

Le cluster Linux à 16 machines réalisé dans le cadre du projet « Beowulf » (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 sockets. Le coût d'un hub n'étant pas négligeable, relier chaque machine à deux (ou plus) réseaux Ethernet, sans hubs ni switches, 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 (« shadow networks ») se révèle bien plus efficace que l'usage d'un réseau équipé d'un commutateur seul.

Bien qu'il existe un certain nombre de technologies différentes nommées « Fast Ethernet », 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 « 10 BaseT ». 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 « bus » à 100 Mbits/s (à l'aide d'un hub 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.

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 hubs 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.

Notez aussi que, comme pour Ethernet, le projet Beowulf (http://www.beowulf.org) de la NASA développe des pilotes aux performances supérieures car utilisant la répartition de charge entre plusieurs cartes Fast Ethernet.

Je ne suis pas sûr que Gigabit Ethernet 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.

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 « Full-Duplex Repeaters » (« répéteurs bidirectionnels simultanés »), 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, Bay networks, Cabletron (désormais Enterasys. Page française : http://www.enterasys.com/fr/), Networks digital, Extreme networks, Foundry networks, Gigalabs.com, Packet engines. Plaintree systems, Prominet, Sun microsystems, et Xlnt.

Il existe un pilote pour Linux pour les « Yellowfin » G-NIC de Packet Engines^[11]. 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.

L'objectif du FC (« Fibre Channel ») 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 http://www.fibrechannel.org^[13].

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 « Home Cinéma ». 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 « quadlets », 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 http://www.adaptec.com.

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 message passing dans un cluster de PC sous Linux.

HiPPI (« High Performance Parallel Interface », soit « Interface Parallèle aux Performances Élevées ») é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 « frame buffer », une batterie de disques, et cætera), et est devenu le standard dominant dans le monde des supercalculateurs. Bien que ce soit un oxymoron, Serial HiPPI 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 http://www.cern.ch/HSI/hippi/. Ils tiennent aussi une liste assez longue de distributeurs proposant le HiPPI sur http://www.cern.ch/HSI/hippi/procintf/manufact.htm.

L'IrDA (« Infrared Data Association » ou « Association de Données par Infrarouges », sur http://www.irda.org), 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 « clusterisation », ou mise en parallèle massive de nombreuses machines. Don Becker est toutefois l'auteur de quelques travaux préliminaires sur l'IrDA.

Myrinet est un réseau local (LAN : « Local Area Network ») conçu pour servir également de réseau système ^[17]. 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 cluster.

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.

Actuellement, Myrinet est assurément le réseau favori des responsables de clusters 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 N machines avec Myrinet, ou 2N machines avec plusieurs équipements de type « Fast Ethernet » ou « TTL_PAPERS ». Tout cela dépend réellement de votre budget et du type de calcul qui vous importe le plus.

Le projet ParaStation (http://wwwipd.ira.uka.de/parastation) de la section informatique de l'Université de Karlsruhe est en train de mettre sur pieds un réseau « maison » 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 clusters 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 Hitex. 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.

Pour le seul coût d'un câble « LapLink » (N.D.T. : câble parallèle croisé), PLIP (« Parallel Line Interface Protocol », soit « Protocole d'Interface par Ligne Parallèle ») permet à deux machines Linux de communiquer par le port parallèle en utilisant les couches logicielles standard basées sur la communication par « sockets ». 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.

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 « très impressionnants » 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.

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 http://www.sequent.com^[18]). 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), http://www.dolphinics.com, sous la série "Clustar". Le CERN tient à jour une bonne collection de liens concernant SCI sur http://www.cern.ch/HSI/sci/sci.html.

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 (« scanners »), 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.

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 fail-over, 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 cluster 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.

ServerNet est la solution réseau de haute performance proposée par Tandem (http://www.tandem.com). Dans le monde du traitement des transactions en ligne (« OnLine Transation Processing », ou « OLTP ») 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 « haute fiabilité et intégrité des données ». 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^[19].

Le projet SHRIMP 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 (« Scalable, High-Performance, Really Inexpensive Multi-Processor », soit « multiprocesseur évolutif et de hautes performances vraiment bon marché ») é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 « maison » 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 « communication mappée en mémoire virtuelle » aux overheads réduits, avec sa couche logicielle.

Même si SLIP (« Serial Line Interface Protocol ») 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 « sockets » 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.

Le projet PAPERS (« Purdue's Adapter for Parallel Execution and Rapid Synchronization », soit « Adaptateur pour l'Exécution en Parallèle et la Synchronisation Rapide de l'université de Purdue »), mené par la Purdue University School of Electrical and Computer Engineering (« École Supérieure d'Électricité et d'Ingénierie en Informatique »), 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.

Plus d'une douzaine de versions de cartes « PAPERS », reliées au PC à la station de travail via le port parallèle standard (SPP : « Standard Parallel Port »), ont été construites, en suivant globalement deux grands axes. Les versions estampillées « PAPERS » 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 « TTL_PAPERS » 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.

Contrairement au matériel sur mesure conçu par d'autres universités, des clusters 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 Video-Wall-HOWTO 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 clusters 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.

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 iopl(), soit ioperm(). 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.

USB (« Universal Serial Bus », http://www.usb.org) est un bus fonctionnant à la vitesse de l'Ethernet conventionnel, dont les périphériques qui s'y rattachent peuvent être connectés à chaud (« Hot-Plug » : sans imposer la mise hors tension 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 ^[20] sur votre prochain PC.

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.

WAPERS (« Wired-AND Adapter for Parallel Execution and Rapid Synchronization », soit « Adaptateur par ET Câblé pour l'Exécution en Parallèle et la Synchronisation Rapide ») est une des facettes du projet PAPERS, de la Purdue University School of Electrical and Computer Engineering (« École Supérieure d'Électricité et d'Ingénierie en Informatique »). 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 pull-up). 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 cluster. Comme pour TTL_PAPERS, il existe un correctif noyau visant à améliorer la sécurité, recommandé mais non requis.

Le socket est de loin la plus courante des interfaces réseau de bas niveau. Les sockets 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 socket : TCP et UDP. Ces deux types de sockets 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.

Ces types de sockets 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.

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 « pilote » (« driver »). UDP et TCP ne se contentent pas de transporter des données, ils s'accompagnent également d'importants overheads dûs à la gestion des sockets. 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 open() pour identifier le périphérique adéquat, puis en utilisant par exemple read() et write() sur le « fichier » 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.

Écrire un pilote de périphérique pour Linux n'est pas difficile… pourvu que vous sachiez parfaitement 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 « bêtes » 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 Device-Driver-HOWTO pour plus d'informations.

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 « bibliothèque au niveau de l'utilisateur » ^[21], 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.

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 :

Par bonheur, il se trouve que Linux pour Intel 386 et compatibles offre une solution meilleure encore :

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 :

extern inline unsigned char
inb(unsigned short port)
{
    unsigned char _v;
__asm__ __volatile__ ("inb %w1,%b0"
                      :"=a" (_v)
                      :"d" (port), "0" (0));
    return _v;
}

La fonction symétrique permettant l'émission d'un octet est :

extern inline void
outb(unsigned char value,
unsigned short port)
{
__asm__ __volatile__ ("outb %b0,%w1"
                      :/* pas de valeur retournée */
                      :"a" (value), "d" (port));
}

Condor est un système de gestion de ressources distribuées qui peut diriger de vastes clusters 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 clusters 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.

Condor est disponible sur http://www.cs.wisc.edu/condor/. Une version Linux existe également. Contactez l'administrateur du site, <condor TIRET admin CHEZ cs POINT wisc POINT edu>, pour plus de détails.

Le DFN-RPC (un outil du Réseau Allemand de la Recherche — « Remote Procedure Call ») 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 cluster. 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 ftp://ftp.uni-stuttgart.de/pub/rus/dfn_rpc/README_dfnrpc.html.

Pas vraiment une bibliothèque, DQS 3.0 (« Distributed Queueing System », soit « Système de Files d'attente Distribuées ») 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 cluster de machines hétérogènes comme une seule entité. Disponible sur http://www.scri.fsu.edu/~pasko/dqs.html.

Il existe aussi une version commerciale nommée CODINE 4.1.1 (« COmputing in DIstributed Network Environments », soit « CAlcul en Environnement Réseau Distribué »).

Le projet Beowulf, 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 cluster, et le système d'exploitation Linux.

Thomas Sterling a été le principal acteur de Beowulf, et continue d'être un promoteur franc et éloquent de l'utilisation de clusters Linux dans le domaine du calcul scientifique en général. À vrai dire, plusieurs groupes parlent à présent de leur cluster comme de système de « classe Beowulf », et ce même si la conception de ce cluster s'éloigne du modèle Beowulf officiel.

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 clusters Beowulf.

Le projet Linux/AP+ ne concerne pas exactement le clustering 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 cluster Linux SPARC.

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. « Pupa » 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 ?

Midway est une DSM (« Distributed Shared Memory », soit « Mémoire Partagée Distribuée ») 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 clusters Linux.

MOSIX apporte des modifications au système d'exploitation BSD « BSDI » pour proposer une répartition de charge réseau (« load balancing ») 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 cluster comme une machine SMP évolutive. Y aura-t-il une version Linux ? Voyez http://www.mosix.org pour plus d'informations^[22].

Le projet NOW (« Network Of Workstations », ou « Réseau de Stations de Travail ») de l'université de Berkeley (http://now.cs.berkeley.edu) 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 « démonstration en pratique d'un système à 100 processeurs dans les prochaines années ». Hélas, ils n'utilisent pas Linux.

Le site web du « Traitement en parallèle avec Linux » (« Parallel processing using Linux »), sur http://yara.ecn.purdue.edu/~pplinux>, 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 (« Purdue University School of Electrical and Computer Engineering ») 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.

Depuis l'assemblage du premier cluster 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 clusters 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 clusters de systèmes à Pentium II (avec pas moins de 165 machines par cluster). Même si tous ces clusters sont ou seront équipés de réseaux PAPERS, la plupart sont également dotés de réseaux conventionnels.

Les 10 et 11 avril 1997, le laboratoire AMES a tenu à Des Moines, dans l'état de l'Iowa aux États-Unis, le « Pentium Pro Cluster Workshop » (« Atelier de clusters Pentium Pro »). Le site web de cet atelier, http://www.scl.ameslab.gov, renferme une mine d'informations concernant les clusters PC, glanées auprès de tous les participants.

La DSM (« Distributed Shared Memory », ou « Mémoire Partagée Distribuée ») est une technique avec laquelle un système de message-passing 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. TreadMarks est l'un des plus efficaces, et fonctionne sur les clusters Linux. La mauvaise nouvelle est que « TreadMarks est distribué à un coût réduit aux universités et organisations à but non lucratif ». Pour plus d'informations concernant le logiciel, prenez contact (en anglais) avec <tmk CHEZ cs POINT rice POINT edu>.

Le projet U-Net (« User-level NETwork interface architecture », ou « Architecture d'interface Réseau au Niveau Utilisateur »), accessible sur http://www.eecs.harvard.edu/~mdw/proj/old/unet, 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).

On trouve bon nombre de projets relatifs à l'utilisation de clusters dans le Wisconsin. Le projet WWT (« Wisconsin Wind Tunnel », ou « Soufflerie du Wisconsin »), sur http://www.cs.wisc.edu/~wwt/, mène toutes sortes de travaux orientés vers le développement d'une interface « standard » entre les compilateurs et le matériel réseau sur lequel ils s'appuient. Il existe le « Wisconsin COW » (pour « Cluster Of Workstation »), « Cooperative Shared Memory » et « Tempest », le « Paradyn Parallel Performance Tools », et cætera. Malheureusement, il n'y a pas grand chose concernant Linux.