par Frank G. Soltis
Un système équilibré exige une mémoire et des entrées/sorties rapides
Depuis toujours, les entrées/sorties (I/O : Input/Output) ont été les parents
pauvres des modèles des systèmes informatiques. La vedette étant presque toujours
le processeur. Pourquoi ? A cause de la suprématie du Mégahertz (MHz), la mesure
des performances informatiques la plus répandue. Comme il est impossible de mesurer
la qualité du système des I/O d'un ordinateur avec des MHz, les concepteurs ont
le plus souvent ignoré cet aspect pour se concentrer sur les performances du processeur.
Après tout, c'est quand même le MHz qui fait vendre. Qui, devant un nouvel ordinateur
cherche à savoir quelle est la bande passante des I/O plutôt que les prouesses
en MHz du processeur ?
Pourtant, un ordinateur sans I/O, c'est comme une voiture sans roues, malgré toute
la puissance du moteur, elle n'ira pas loin. Au même titre que la mémoire, le
système des I/O détermine le temps de réponse et le débit de la plupart des ordinateurs.
Ce sont ces mesures qui intéressent le plus les clients, même si les concepteurs
de processeurs ne l'admettent pas.
La puissance des I/O pourrait alors bien devenir le seul critère distinctif
Heureusement, les choses sont en train de changer. Dans un futur proche, tous
les ordinateurs, des PC d'entrée de gamme aux superordinateurs les plus rapides,
utiliseront les mêmes briques de microprocesseur. La puissance des I/O pourrait
alors bien devenir le seul critère distinctif.
Même les concepteurs de processeurs commencent à prendre les I/O plus au sérieux.
C'est ainsi que les concepteurs de la prochaine génération de puces microprocesseur
PowerPC (appelées POWER4) mettent davantage en avant les largeurs de bande de
leurs nouvelles puces plutôt que leur performance en MHz. La situation s'est inversée,
et les I/O ont enfin leur heure de gloire. Et comme le système des I/O de la nouvelle
iSeries 400 est très différent de celui de l'AS/400, il convient d'examiner les
modifications apportées pour juger de leurs conséquences sur nos modèles de systèmes
futurs.
L’AS/400 et le iSeries utilisent tous deux une hiérarchie de composants servant
à l’attachement des I/O. Il s’agit en général des centres d’I/O, des bus d’I/O,
des ponts d’I/O, des processeurs I/O (IOP), des adaptateurs d’I/O (IOA), ainsi
que des unités d’I/O et des connexions réseaux. Pour bien comprendre l’évolution
de ce modèle, il faut examiner le prédécesseur de l’AS/400, le System/38.
Le S/38 utilisait un canal d’I/O très semblable à un canal de System/370. Un
canal, sorte d’ordinateur spécialisé au flanc du processeur principal, est destiné
à libérer le processeur principal du traitement des l’I/O. Un canal a son propre
jeu d’instructions écrit spécialement pour communiquer avec les adaptateurs
d’I/O attachés au bus et pour transférer des données entre les unités d’I/O
et la mémoire. Le processeur principal transmet les programmes (appelés programmes
de canaux) au canal, et le matériel de ce dernier les exécute simultanément
aux autres programmes tournant dans le processeur principal. Quand un canal
a terminé son programme, il interrompt le processeur principal pour demander
d’autres travaux.
Le S/38 devait son canal aux personnes impliquées dans le projet. En effet,
pour concevoir et construire le S/38, IBM a amené beaucoup de nouvelles têtes
à Rochester. La plupart venaient d’autres secteurs d’IBM et comme les concepteurs
du matériel d’I/O avaient déjà travaillé sur des canaux S/370, ils ont décidé
d’utiliser une variante d’un modèle qu’ils connaissaient bien.
|
Comment on est passé des canaux aux bus
Au cours de la décennie 1980, la direction d’IBM déplorait le fait que
trop d’ordinateurs midrange soient en concurrence sur le même marché client.
Pour résoudre le problème ainsi perçu, la direction a transféré à la SPD
(Systems Product Division) la responsabilité de cinq systèmes midrange
différents. Deux d’entre eux, le System/34 (remplacé plus tard par le
System/36) et le System/38, étaient des produits de Rochester. Sous le
nom de code Fort Knox, la SPD a démarré un nouveau projet visant à intégrer
les cinq systèmes dans un nouveau système dont les diverses parties seraient
fabriquées dans différentes usines d’IBM.
Endicott, New York, a hérité des produits System/370 milieu de gamme,
les développeurs avaient pour mission de concevoir le processeur du nouveau
système. Ce fut le premier processeur RISC d’IBM. Endicott s’est également
chargé de concevoir le packaging du nouveau système. Ils ont opté pour
un vaste et plutôt coûteux rack, que l’on utiliserait plus tard dans un
produit S/370 milieu de gamme appelé 9370.
L’unité IBM de Boca Raton, Floride, avait déjà fabriqué la famille Série/1.
Comme la Série/1 était un très bon contrôleur d’I/O, on a demandé aux
ingénieurs de Boca Raton de concevoir et de réaliser le système d’I/O
pour Fort Knox. Eux aussi ont pris ce qu’ils connaissaient le mieux et
ont conçu un bus d’I/O très semblable à celui d’une Série/1, appelé bus
SPD.
Les ingénieurs de Rochester ne sont que très peu intervenus dans la conception
de Fort Knox. A tel point que certains de leurs managers s’interrogeaient
sur leur avenir. Ils devaient encore livrer les nouveau modèles des S/36
et S/38, mais il n’y avait plus grand chose derrière. Et quand les ingénieurs
de Rochester ont proposé de fabriquer un nouveau package entrée de gamme
moins coûteux pour Fort Knox, la direction de la SPD a rejeté l’idée.
Lorsqu’il est apparu que le processeur RISC n’exécuterait aucun logiciel
applicatif existant, les ingénieurs ont été chargés de concevoir les coprocesseurs
S/36 et S/38 pour Fort Knox. Un client désirant migrer sur Fort Knox devait
acheter l’un de ces coprocesseurs pour exécuter les anciennes applications
pendant que les nouvelles seraient développées pour le processeur RISC.
Endicott a également commencé à travailler sur un coprocesseur S/370 qui
deviendrait finalement le processeur principale du 9370.
Dans le même temps, la direction de la SPD a confié à certains programmeurs
de Rochester le soin d’écrire un nouveau système d’exploitation pour Fort
Knox. Une nouvelle organisation de programmation a été constituée et de
nombreux programmeurs ont commencé allègrement à travailler sur un nouveau
système d’exploitation. En fait, il fallait plusieurs variantes du système
d’exploitation, capables de travailler avec les divers coprocesseurs.
Ils avaient Beethoven, Bach et Chopin comme noms de code, et les programmeurs
de Rochester baignaient dans une ambiance musicale.
Quand IBM a enfin pris conscience que Fort Knox ne fonctionnerait pas,
la division SPD a hérité d’une nouvelle direction. Un groupe d’ingénieurs
et de programmeurs de Rochester ont annoncé immédiatement un projet sur
lequel ils avaient travaillé en secret : Silverlake. Ils s’agissait d’un
S/38 pouvant aussi exécuter du code applicatif S/36. La nouvelle direction
a rapidement approuvé le projet. Mais le matériel et le logiciel du S/38
avaient été négligés à un point tel que d’importantes mises à niveau s’avéraient
nécessaires.
Les ingénieurs et programmeurs ont immédiatement commencé à voir combien
de composants de Fort Knox seraient réutilisés. Les programmeurs ont commencé
à étendre le système d’exploitation S/38, dénommé CPF (Control Program
Facility), avec beaucoup des nouvelles fonctions auparavant destinées
à Fort Knox. En interne, ils ont appelé le nouveau système d’exploitation
XPF (extended CPF).
Les ingénieurs ont eux aussi commencé à réutiliser des composantes de
Fort Knox. Prenant le package développé à Endicott, ils ont installé les
nouveaux coprocesseurs S/38 nouvellement conçus. Ils ont aussi entrepris
de terminer le package d’entrée de gamme rejeté auparavant par l’ancienne
direction.
Deux ans et demi plus tard, Silverlake était annoncé comme sous le nom
d’AS/400. Chaque nouveau modèle AS/400 contenait un bus SPD. Le bus SPD
inspiré par la Série/1 était un excellent modèle qui a servi l’AS/400
pendant des années. Aujourd’hui, c’est tout ce qu’il reste de Fort Knox.
FGS
|
Téléchargez cette ressource
Guide de Sécurité IA et IoT
Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.
