> Tech > La revanche des I/O

La revanche des I/O

Tech - Par iTPro.fr - Publié le 24 juin 2010

Windows

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

Sécuriser Microsoft 365 avec une approche Zero-Trust

Découvrez comment renforcer la cyber-résilience de Microsoft 365 grâce à une approche Zero-Trust, une administration granulaire et une automatisation avancée. La technologie Virtual Tenant de CoreView permet de sécuriser et simplifier la gestion des environnements complexes, tout en complétant vos stratégies IAM, y compris dans les secteurs réglementés.

Les articles les plus consultés

A travers cette chaîne

A travers ITPro

Les plus consultés sur iTPro.fr

Articles les + lus

Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic

Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine

Analyse Patch Tuesday Mai 2026

Les coûts cachés des merge requests générées par l’IA

Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants

A lire aussi sur le site

L’anxiété liée à l’IA, un risque sous-estimé pour la sécurité

L’anxiété, le manque de confiance ou l’incertitude jouent un rôle clé et influencent les comportements et créent des vulnérabilités.

À la une de la chaîne Tech

Préparez votre entreprise à l’ère de l’IA avec Windows 11

Alors que l’intelligence artificielle s’impose comme un levier majeur de transformation, Lenovo, Microsoft et inmac wstore invitent les entreprises à franchir le pas vers Windows 11.

A la Une des Ressources IT

Inscrivez-vous !

Actualités, Dossiers et Ressources IT Professionnelles - dimanche 07 juin 2026