Mitte September letzten Jahres hat sich die Gesellschaft für Mathematik und Datenverarbeitung (GMD) mit Krupp-Atlas Elektronik in Bremen sowie Stollmann, Hamburg, zusammengetan, um mit diesen Partnern das Projekt SUPRENUM zu realisieren: die Erschaffung des ersten "Supercomputers" deutscher Konzeption und Produktion. Diese Entwicklung ist Anlaß genug. die Aktivitäten des Bremer Krupp-Ablegers und der genannten Partnergesellschaften in Sachen Parallelverarbeitung einmal näher unter die Lupe zu nehmen.
SUPRENUM ist ein Parallelrechner-Projekt, über dessen Details zur Zeit intensiv beraten wird. Mit den Prozeßrechner-Spezialisten von der Waterkant ist die GMD nicht ganz von ungefähr zusammengekommen.
Konkret empfahlen sich die Krupp-Atlas-Elektroniker offenbar nicht zuletzt durch ihr Mehrprozessor-Rechnersystem "MPR 1300" sowie außerdem durch ihren Mehrprozessor-Synchron-Duplexrechner "MPR 1300 SD". Bei der Konzeption des MPR 1300 gingen die Krupp-Atlas-Ingenieure davon aus, daß die Software " insbesondere auf dem Gebiet der Prozeßdatenverarbeitung durch hohe Parallelität auf Task-Ebene" gekennzeichnet ist, wie die Autoren G. Landsberg und H. Meyerhoff auf einer Fachtagung darlegten. Diese Art Software sei also wohl ideal geeignet, die parallele Hardware-Struktur - die sichtlich im Trend unserer Zeit liege und dank preiswerter Mikroprozessoren heute auch schon mit relativ geringem Aufwand realisiert werden könne - zu nutzen. Zumal man hier ja keinen Extraaufwand betreiben müsse, um einzelne Algorithmen zum Zwecke der Parallelbearbeitung parallel aufzubrechen". Genau dies aber sei ja bei den Konzepten sogenannter Datenflußrechner immer noch mit vielfältigen Problemen verbunden.
Wer parallele Rechner entwerfen will und dabei auch gleich noch den Vorteil der Fehlertoleranz, der diesen Architekturen ja inhärent ist, nutzen möchte, der kann eine von zwei möglichen Grundstrukturen vorsehen; dabei sind aber auch Kombinationen beider Basiskonzepte möglich. Es handelt sich dabei einmal um die "homogene symmetrische Struktur" mit gemeinsamem Speicher und zum anderen um kooperierende selbständige Prozessoren mit jeweils ihrem "privaten" Speicher.
Bei der ersten Struktur benutzen gleichberechtigte Universalprozessoren alle den gleichen Speicher, auf den sie über einen gemeinsamen Bus zugreifen; dabei kann dann jeder Prozessor jede Aufgabe beziehungsweise Task bearbeiten.
Diese Struktur weist aber einen Nachteil auf, und zwar den sogenannten von-Neumann-Flaschenhals bemerken Landsberg und Meyerhoff; denn Bus und Speicher begrenzen nun einmal den erzielbaren Durchsatz. Und das begrenze auch die Zahl der "sinnvollen parallelen Prozessoren" auf zwei bis maximal vier.
Andererseits biete diese homogene "Grundstruktur I" den Vorteil eines guten Verhaltens im Fehlerfalle. Denn man müsse das System bei Ausfall eines Prozessors nicht umkonfigurieren, und außerdem brauche man die auf dem System laufende Anwendersoftware nicht zu verändern, setzt man zusätzliche Prozessoren ein. Und soweit die Software nur überhaupt ein hinreichendes Maß an Parallelität aufweist, sei auch "eine gleichmäßige Auslastung der Prozessoren gewährleistet".
Nun zur zweiten Möglichkeit, also zu den mit privaten Speichern versehenen Prozessoren, die über einen Bus kommunizieren. Hier, so bemerken die Autoren, bearbeite "jeder Rechner festgelegte Aufgaben" entsprechend dem in seinem Privatspeicher untergebrachten Programm. Der Bus diene nur dazu, die nötigsten Informationen zwischen den einzelnen Rechnern auszutauschen.
Diese Struktur habe nun aber den Nachteil, meinen die Fachleute aus Bremen, daß man "die Verteilung der Tasks schon bei der Initialisierung des Prozesses durch Laden des privaten Speichers festlegen" müsse. Und das bedeute, man brauche weine genaue Kenntnis des zeitlichen Ablaufs des gesamten Prozesses", wolle man die Tasks alle so verteilen, daß die Prozessoren gleichmäßig ausgelastet werden. Doch leider: Eben die
Kenntnis sei "auf dem Gebiet des Prozeßdatenverarbeitung mit Realzeitanforderungen im allgemeinen nicht vorhanden".
Ein weiterer Nachteil dieser Struktur liege noch darin, kann man erfahren, daß hier die Software geändert werden müsse, wird die Struktur, etwa durch Hinzufügen weiterer Prozessoren, geändert. Hingegen biete so ein Konzept wiederum den Vorteil, daß man im Grunde soviel Prozessoren vorsehen kann, wie "die Parallelität der Software auf Taskebene" nur eben erlaubt, Wobei allerdings wiederum bedacht sein will, daß die maximale Busbelastbarkeit diesem unbekümmerten Ausbau irgendwann ja doch eine feste Grenze setzt; dann nämlich, wenn der Austausch von Informationen zwischen den einzelnen Rechnern sowie der Zugriff auf die globalen Daten eines Prozesses beginnen, den Bus zu überlasten.
Steht man in dieser Art vor der Wahl zwischen zwei technischen Grundkonzepten mit jeweils ihren spezifischen Vor- und Nachteilen, so muß man sich letztlich an den konkreten Anforderungen orientieren, denen die Maschinerie später genügen soll. Und das hieße im Falle der Prozeßdatenverarbeitung, man sieht besser eine zentrale Datenhaltung vor, also einen gemeinsamen Speicher für alle beteiligten Rechner. Andernfalls nämlich würden die der Prozeßdatenverarbeitung nun einmal inhärenten Besonderheiten einen sehr intensiven, den Bus stark belastenden Datenaustausch und außerdem einen beträchtlichen Synchronisationsaufwand erzwingen.
Ein weiterer Gesichtspunkt bei der Wahl, die hier getroffen werden mußte, ist der, daß man zwar auch bei einer Konfiguration mit jeweils einem privaten Speicher pro Prozessor Programme hin- und herschaufeln kann, wenn dies erforderlich wird; nur koste dieses Umladen viel Zeit und bedinge auch eine Unterbrechung des Prozesses. Außerdem, so die weitere Überlegung des Bremer Ingenieurteams, sei dieses Umkonfigurieren anwendungsabhängig und beeinflusse die Anwendersoftware.
Vier Busse verbinden acht Bit-Slice-Prozessoren
Der Rechner MPR 1300 weist daher nur im grundsätzlichen die Struktur I (mit gemeinsamem Speicher) auf, verfügt aber nicht nur über einen, sondern gleich über vier parallele Busse. Diese Busse verbinden maximal acht 16-Bit-Prozessor-Bausteine vom "Bit-Slice"-Typ. Sie haben je 16 MB Adreßraum mit maximal 24 Vierport-Speicherbaugruppen von je 512 KWorten zu 16 plus 6 Bit. Die Verbindung mit der Außenwelt stellen maximal acht Peripherie-Kopplungsbaugruppen her, die an die Busse 0 und 1 angeschlossen sind. Je System können maximal 25 Baugruppen vorgesehen werden, wobei deren Kombination nahezu beliebig ist. Die vier Busse arbeiten völlig unabhängig voneinander, und da eine Prozessorzykluszeit immer größer ist als die zugehörige Busbelegungszeit, können sich ohne weiteres auch zwei Prozessoren einen Bus teilen; es gibt keine Buskonflikte.
Wie Landsberg und Meyerhoff dazu erläutern, hatte "die Unabhängigkeit der Software von der Struktur", also von der Zahl der eingesetzten Prozessoren, "absolute Priorität" beim Entwurf des Konzepts. Deshalb griff der Hersteller ja auch zur Grundstruktur I. Und da dieser Computer als zentraler Leitrechner in größeren Systemen der Prozeßdatenverarbeitung eingesetzt werden soll, kann man ohnedies voraussetzen, daß die Software ein hohes Maß an Parallelität aufweisen wird; "typisch sind 50 bis 200 Tasks". Damit aber, so hört man, "bietet sich eine parallele Hardwarestruktur mit paralleler Verteilung der Software" - und zwar "auf Task-Ebene" - geradezu an.
Solange so ein System ausreichend viele parallele Tasks zur Verfügung hat, kann es immer mit gleichmäßiger Auslastung arbeiten; auch wenn man weitere Prozessoren "hinzusteckt". Denn es wirkt ja dann nach außen hin einfach wie "ein Einprozessorsystem mit zusteckbarer Leistung" - aber eben nun eines, bei dem ..jede Komponente ausfallen kann, ohne daß eine grundsätzliche Umkonfiguration notwendig wird".
Mit den vier Bussen - die Beschränkung auf diese Zahl folgte aus konstruktiven sowie aus Gründen der Aufwandsbegrenzung - kann der Rechner nach Meinung der Autoren auch mit acht und mehr Prozessoren noch sinnvoll betrieben werden. Allerdings dürften die Möglichkeiten dieser Struktur, selbst bei späteren Verbesserungen, bei etwa 16 Prozessoren erschöpft sein.
Das hier diskutierte Mehrrechnersystem arbeitet mit einem Betriebssystem, das in der Sprache META geschrieben ist und auf einem Echtzeit-Betriebssystem namens MOS 1300 basiert. Es besteht, so sagen Landsberg und Meyerhoff, "aus Tasks beziehungsweise stellt Monitorschnittstellen zur Verfügung, die dann von den Anwender-Tasks aufgerufen werden". Alle Synchronisationen erfolgen dabei über Semaphore, nicht über Prioritäten.
Rechenfähige Tasks nach Priorität
Dieses Betriebssystem verteilt die "rechenfähigen Tasks" einschließlich seiner eigenen Betriebssystem-Tasks in der Reihenfolge ihrer Prioritäten auf die jeweils gerade vorhandenen ein bis acht Prozessoren und läuft dabei "wie alle anderen Task-Systeme" auch selber verteilt ab. Das soll, liegen einmal mehrere Betriebssystem-Aufträge gleichzeitig vor, die Antwortzeiten verkürzen.
Damit das Betriebssystem in der skizzierten Weise verteilt laufen kann, sind sein Kern sowie das Laufzeitpaket der Echtzeitsprache META und auch Teile der Sprache PEARL direkt "im Mikroprogramm der Prozessoren untergebracht". Auch dies sorgt für einen weiteren Gewinn an Betriebssystem-Geschwindigkeit sowie für eine schnellere Bearbeitung der Sprache PEARL; außerdem wird so die - für den Durchsatz manchmal kritische - Zahl der Zugriffe auf den Bus verringert.
Der Laufbereich beziehungsweise Datenbereich eines Programmsystems, also eines Prozesses, kann beim MPR 1300 "beliebig groß sein"; dabei soll der Rechner einen "hohen Schutz gegen Hard- und Softwarefehler" bieten.
Beliebig groß können die genannten Bereiche sein, weil beim hier diskutierten Rechner nicht etwa ein ganzes Anwenderprogramm "sichtbar gemacht" wird, sondern nur jeweils die gerade benötigte Task; sie wird "mit ihrem Programmcode und ihren lokalen Datenbereichen im Task-Adreßraum abgebildet.
Ruft nun eine Task andere Tasks oder Prozeduren auf, so wird nur jeweils deren Programmcode sowie deren lokaler Datenbereich im gleichen Task-Adreßraum sichtbar gemacht, während der Programmcode der aufrufenden Task, der ja vorübergehend nicht mehr benötigt wird, gleichzeitig unsichtbar gemacht wird. Hingegen bleiben die lokalen Datenbereiche der Tasks und der - eventuell mehrfach gestaffelt - aufgerufenen Unterprogramme "immer erhalten". Und wird die Verarbeitung wieder von der aufrufenden Task fortgesetzt, so wird natürlich sogleich auch deren Programmcode wieder "sichtbar gemacht".
Wie teilt nun dieser Computer den einzelnen Tasks die Prozessoren zu? Das ist eine Aufgabe, die von der META-Maschine qua Mikroprogramm vorgenommen wird, wobei alle momentan auf Zuteilung eines Prozessors wartenden Tasks in der Reihung ihrer Prioritäten in eine CPU-Liste einsortiert sind. Wird ein Prozessor frei, so holt er sich die wichtigste der wartenden Tasks aus dieser Liste und beginnt, sie zu bearbeiten.
Unnötiger Prozessorwechsel läßt sich vermeiden
Läuft eine Unterbrechungsanforderung ein, so bewirkt sie nur bei dem Prozessor eine Reaktion, der mit der momentan niedrigsten Priorität arbeitet. Dadurch "wird ein unnötiger Prozessorwechsel von vornherein vermieden, erläutern die Fachleute von Krupp-Atlas.
Bestimmte Mechanismen zur störungsfreien Synchronisierung der Prozessoren sowie zur Sicherstellung einer reibungsfreien Kommunikation zwischen den Prozessoren eines Rechners sorgen dafür, daß die gesamte Anlage in geordneter und zuverlässiger Weise zusammenspielt. Es würde allerdings zu weit führen, sie im Rahmen dieses Beitrags ausführlicher vorzustellen.
Um so mehr sei dafür zum Thema "Fehlertoleranz" gesagt. Wobei kurz daran zu erinnern ist, daß ein Rechner sich ja nur dann fehlertolerant verhalten kann, wenn er erstens über "eingebaute Redundanz" und zweitens über Mechanismen zur Fehlererkennung verfügt.
Daß das hier besprochene System redundant aufgebaut ist, braucht nicht nochmals beschrieben zu werden - wie aber steht es um die Fehlererkennung? Dafür steht erstens ein Speicher mit Fehlererkennungs- und Korrekturautomatik (EDC) zur Verfügung, wobei für jeden der vier Busse auf einer zentralen Steuerungs- und EDC-Baugruppe des Systems eine Hardwareeinrichtung vorhanden ist, die per Hamming-Code Zweibit-Speicherfehler erkennen und Einbit-Fehler korrigieren kann. Dabei wird wiederum, durch Vergleich des Speicherzugriffs, über zwei Busse ständig geprüft, ob die EDC selber und auch die Busse noch korrekt arbeiten.
Die zweite Sicherung gegen unerkannte Fehler stellen die Speicherverwaltungseinrichtungen dar, die sich auf jeder Prozessorplatine und auf jeder Kopplungseinrichtung für die Ein-/Ausgabe und den Speicherdirektzugriff befinden. Sie sorgen dafür, daß Lesezugriffe wirklich nur auf den Code der momentan ausgeführten Task beziehungsweise Prozedur möglich sind; der entspricht übrigens im allgemeinen einem Speicherbereich kleiner als 1 KB. Ebenso verhindern sie Lese- und Schreibzugriffe auf andere Daten als die der eigenen Task, und sie sorgen auch dafür, daß die Peripherie im Speicherdirektzugriffsverfahren nur auf den speziell vorgesehenen Adreßbereich zugreifen kann. Lesend und schreibend. Diese Mechanismen sorgen dafür daß alle Fehler einschließlich Softwarefehler erkannt werden, die die Folge falscher Adreßberechnungen und Adressierungen sein mögen.
Einen dritten Schutzring schließlich bilden auf der Ebene der Maschinenbefehle implementierte Sicherheitsmechanismen; zu ihnen gehören vor allem Wächter für jene Befehle, die "zur Unterstützung des Betriebssystems und der Sprachen META und PEARL eingebracht wurden".
Diese Mechanismen können zwischen privilegierten, unprivilegierten und unzulässigen Befehlen unterscheiden, die Indizes von Feldern überwachen und auch bestimmte Prüfungen durchführen, die der Zulässigkeit von Echtzeitbefehlen gelten.
Weil das gesamte Rechnersystem aus mehrfach vorhandenen, gleichberechtigten Teilen, wie Prozessoren, Speichern, Bussen, Ein-/Ausgabe- und Speicherdirektzugriffswegen, besteht, ist es laut Landsberg und Meyerhoff nun leicht möglich, fehlerhafte Systemkomponenten, wie etwa einen Bus oder einen Prozessor, "nach einer Fehlererkennung und -diagnose durch Softwarebefehle wegzuschalten ".
Das hat dann nichts weiter zur folge, als daß der Prozeß mit "geringen Einschränkungen" weitergeführt werden kann. Oder, um es anders auszudrücken: Vergleicht man das Multiprozessorsystem mit üblichen Einprozessorsystemen, so stellt man fest Krupp-Atlas-Berechnung, fest die "Nichtverfügbarkeit" sei hier "um den Faktor 10 bis 100 geringer" als bei jenen. Nur jeder zwanzigste Fehler führt zum Abschalten des Gesamtsystems. Aber "nur für einige Minuten", wie es heißt.
Acht Prozessoren bringen nicht achtfache Leistung
Mehrrechnersysteme mit gemeinsamem Bus haben generell die Eigenschaft, daß zum Beispiel eine Konfiguration mit acht Prozessoren nicht einfach den achtfachen Durchsatz eines Einzelprozessors leisten kann; Buszugriffskonflikte und die Notwendigkeiten der Prozessor-Prozessor-Kommunikation stehen dem im Wege. Und deshalb ist stets besonders interessant, betrachtet man (...) konkrete Konzeption, wie es denn hier nun mit dem Leistungsgewinn steht, fügt man einen Prozessor nach dem anderen hinzu.
Für entsprechende Messungen erstellten Landsberg und Meyerhoff zunächst ein Programmsystem mit "n" parallelen Tasks, wobei drei Task-Grundtypen eingesetzt wurden: Programme mit vorwiegend kurzen Befehlen, auch als INTEGER bezeichnet, Programme mit vorwiegend langen Befehlen, auch FLOAT genannt, und schließlich eine Mischung aus beiden Arten, hier mit MIXED bezeichnet. Und sie maßen dann den "Durchsatz" einfach als Kehrwert der Zeit, die für die Bearbeitung des Programmsystems benötigt wurde. Wobei sie dieses Programmsystem aber natürlich so (günstig) wählten, daß die Zahl "n" der parallelen Tasks genauso groß war wie die Zahl der im Versuch maximal eingesetzten Prozessoren, hier also sechs.
In einer ersten Reihe wurde nun der Frage nachgegangen, wie der Durchsatz beim Hinzufügen von Prozessoren steigt, wenn ein System nur einen Bus hat. Es zeigte sich, daß sechs Prozessoren beim Programmtyp FLOAT dann zwar noch ordentliche 487 (von maximal 600) Prozent der Leistung nur eines Prozessors an Durchsatz bringen, beim Programmtyp INTEGER aber bloß kärgliche 249 Prozent.
Dieser Wert konnte drastisch verbessert werden, als man von einem auf vier Busse überging. Denn nun leisteten sechs Prozessoren bei INTEGER-Programmen immerhin schon 408 Prozent, und bei FLOAT ging der Durchsatz sogar auf kaum mehr überbietbare 590 Prozent hinauf; was zeigt, daß mehr Prozessoren, wenigstens bei FLOAT-Programmen, praktisch wirklich entsprechend mehr Durchsatz bringen.
Waren die Programme bei den bisherigen Beispielen physisch alle in einem einzigen Speicher-Baustein konzentriert, was natürlich zu erheblichen Speicherkonflikten führen kann, so wurden sie in einer weiteren Versuchsreihe mit ebenfalls vier Bussen gleichmäßig auf sechs Speicherbaugruppen verteilt. Und siehe da: Nun stieg der Sechsprozessor-Durchsatz bei INTEGER nochmals deutlich an, nämlich auf 520 Prozent, und er legte sogar bei FLOAT noch ein bißchen zu: nämlich auf 595 Prozent.
Ein Bus verarbeitet maximal drei Prozessoren
Bringt man alle Resultate dieser Versuche auf eine knappe Formel, so läßt sich mit Landsberg und Meyerhoff sagen, es sei, hat man bloß einen Bus, höchstens sinnvoll, drei Prozessoren einzusetzen; zusätzliche Leistung durch Hinzuaddieren von Prozessoren wäre bei nur einem Bus nämlich einfach zu teuer erkauft.
Kann man hingegen vier Busse nutzen, so lassen sich "weitgehend problemlos" sechs bis acht Prozessoren betreiben. Wobei übrigens im Falle der vier Busse bei vier Prozessoren und gleichverteilten Speichern der amüsante Effekt auftritt, daß dieses Quartett dann genau 401 Prozent der Leistung des Einzelprozessors bringt! Das aber hat nichts mit Zauberei zu tun, sondern resultiert einfach daraus, daß die Aktivitäten der Betriebssysteme hier von einem auf nunmehr vier Prozessoren verteilt werden können.
Die Autoren aus Bremen schließen aus ihren Arbeiten weiterhin, "eine weitere Erhöhung der Parallelität der Prozessoren" sei wohl nur "durch eine Verringerung der Busspeicherbelastung" möglich, und dazu böten sich teils technologische" und teils "strukturelle Verbesserungen" an; - jedenfalls dann, wenn man die vorliegende Grundstruktur mit den gleichberechtigten Prozessoren und dem gemeinsamen Speicher beibehalten wolle. Was ja angesichts der Vorteile, die diese in Sachen Fehlertoleranz und Softwareeinfachheit bietet, mir sinnvoll sein könne.
Beispiele für technologische Verbesserungen" des Systems wären schnellere Speicher und schnellere Busse, doch notieren die Experten hier mahnend: Sobald eines Tages schnellere Prozessoren verfügbar seien, würden diese die mit solchen Verbesserungen erzielten Effekte wieder aufheben.
Datenverluste möglich trotz hoher Verfügbarkeit
Und was kommt an "strukturellen Verbesserungen" in Frage? Hier denken die Rechnerentwickler einmal an den Einsatz schneller Befehls-Pufferspeicher für jeden Prozessor und zweitens - doch noch - an die Verwendung privater Speicher. Damit, so meinen sie, sollte diese Struktur bis zu einem 16-Prozessor-System ausbaubar sein, ehe ihre Möglichkeiten dann wohl endgültig erschöpft sind.
Eine ganz spezielle Art, im Rahmen des hier diskutierten Konzepts maximal 16 Prozessoren einzusetzen, stellte S. Wasmund, der Leiter des Bereichs Prozeßdatensysteme der Firma Krupp-Atlas Elektronik, im Rahmen der Hannover-Messe '85 vor. Es handelt sich um eine Konfiguration, die die Durchsatzstärke des; MPR 1300 mit der Ausfallsicherheit eines Synchron-Duplexrechners verbinden soll.
Worum es dabei genau geht, wird klar, bedenkt man, daß beim MPR 1300 laut Wasmund ja immer noch "Datenverluste und damit Störungen möglich" sind, sollten einmal, ungeachtet seiner an sich hohen Verfügbarkeit von mehr als 99,9 Prozent Teilausfälle vorkommen. Denn die können ja, siehe oben, manchmal bewirken, daß dann beispielsweise die Aufgaben eines ausgefallenen Prozessors auf einem anderen Prozessor neu gestartet werden müssen.
Deshalb wurde nun also das Konzept des "MPR 1300 SD" entwickelt, der praktisch ein Verbundsystem von zwei mit gleichvielen Prozessoren versehenen MPR 1300 darstellt,
die über je eine Kopplungs- und Multiplexer-Einheit miteinander verbunden sind. Die (zwei bis acht) einzelnen Prozessoren beider Teilsysteme werden hier jeweils miteinander synchronisiert.
Diese Konfiguration soll eine Verfügbarkeit von 99,9999 Prozent erreichen können, indem sie bei Störungen auf höchst trickreiche Weise arbeitet.
Tritt beispielsweise im Prozessor 3 des Teilsystems 1 ein Fehler auf, so "verläßt" das Gesamtsystem vorübergehend den "gewöhnlichen" Synchron-Duplexbetrieb. Es führt auf dem intakten Prozessor 3 des Teilrechners 2 die betroffene Task geordnet zu Ende und sorgt dann dafür, daß dieser Prozessor 3 in beiden Teilsystemen abgeschaltet wird. Erst dann kann wieder der volle Synchron-Duplexbetrieb aufgenommen werden, aber natürlich nun mit jeweils einem Prozessor pro Teilsystem weniger. Was natürlich den Durchsatz vermindert und das Antwortzeitverhalten verlangsamt.
Sollten - was in der Praxis kaum vorstellbar ist - einmal der Reihe nach soviel Prozessoren ausgefallen sein, daß man aufgrund des reduzierten Antwortzeitverhaltens keinen sinnvollen Betrieb mehr aufrechterhalten kann, so wird der Synchron-Duplexbetrieb endgültig verlassen und fortan nur noch das weniger defekte der beiden Teilsysteme eingesetzt, das dann eben wie ein einzelner MPR 1300 arbeitet. Wobei ja auch hier immer noch die Redundanz dieses Mehrrechnersystems genutzt werden kann.
Sowohl statisch als auch dynamisch redundant
Es handelt sich bei dieser von Wasmund beschriebenen Anlage mit ihrer "doppelten Ersatzwegschaltung" also um ein System, das sowohl statisch als auch dynamisch redundant ist; statisch, weil ja im Grunde ein Teilsystem doppelt vorhanden und aktiv ist, und dynamisch, weil im Fehlerfalle eine Aufgabenverteilung auf andere Prozessoren erfolgen kann. Dieses System soll laut Wasmund ein Höchstmaß an Betriebssicherheit bieten. Dennoch soll es "während des laufenden Betriebs" wartbar sowie in Hard- und Software aufrüstbar sein.
Interessant ist auch, was der Krupp-Atlas-Manager aus einem Vergleich mit herkömmlichen
Einprozessorrechnern der 16- und der 32-Bit-Klassen abliest. Er bemerkt nämlich, bei jenen Systemen falle die Verfügbarkeit - auf die es in manchen Anwendungsfällen ja mehr als auf alles andere ankommen dürfte mit steigender Leistung im allgemeinen ab". Denn bei diesen Rechnen schlage dann eben deren zunehmende Komplexität beziehungsweise deren anfälligere Technik negativ zu Buche.
Anders hingegen Mehrprozessorsysteme. Hier steige die Leistung ja durch Addieren weiterer, parallel eingesetzter Hardware, und daher steige hier die Verfügbarkeit sogar an, fordert man von ihnen mehr Leistung.