Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.


04.06.1976

Alternative zum Realtime - Dinosaurier?

Mit Arnold Pott Direktor für DV und Systemorganisation bei der Thyssen - Niederrhein AG, Oberhausen, sprach CW - Chefredakteur Dr. Gerhard Maurer

- Vielgepriesene neue Konzepte des Distributed Processing fordern, daß künftig zunehmend Intelligenz in dezentralen Svstemen verteilt werden soll. Gilt das Gesetz der Größendegression nicht mehr, nach dem auch Datenverarbeitung auf größeren Maschinen billiger ist als auf vielen kleinen?

Das Gesetz der Größendegression gilt wie bei anderen Produktionsanlagen nach wie vor - auch für die Datenverarbeitung -, jedoch nicht für alle Betriebsarten der DV. Das Gesetz ist unumstritten, solange Datenverarbeitungsanlagen im Batch - Mode arbeiten, es gilt aber nicht mehr in vollem Umfang, wenn Realtime - Anwendungen vorliegen.

- Ist nicht für jeden Rechner jede Aufgabe eine Kette von anonymen Bits, die abzuarbeiten sind?

Das stimmt im rein technischen Sinne. Die Verarbeitung der Bit - Ketten in einem Rechner erfordert jedoch eine Organisation, die auf eine möglichst große Auslastung der Anlage ausgerichtet sein sollte und den Benutzerbedürfnissen genügen muß. Bei der Batch - Verarbeitung kann das Ziel der optimalen Auslastung der Anlage Vorrang haben, da diese in der Regel nicht sehr zeitkritisch sind. Batch - Kunden wünschen ihre Ergebnisse in der Regel innerhalb von Stunden, während die Resourcen - Optimierung in einem Rechner innerhalb von Sekunden oder Millisekunden erfolgt. Im Falle der Batch - Verarbeitung stellt sich die Maschine mit für jede Aufgabe einmaligem internem Organisationsaufwand für relativ große Zeiträume auf die Verarbeitung homogener Daten ein. Im Realtime - Betrieb treffen jedoch ständig unterschiedliche Einzelnachrichten ein, die jeweils eine sofortige gesonderte Zuordnung von Systemkomponenten und Programmen in der Maschine erforderlich machen. Damit ist der Organisationsaufwand der Maschine je Menge tatsächlich verarbeiteter Bits unvergleichlich viel höher als bei der Batch - Verarbeitung. Entsprechend sinkt der Throughput im Vergleich zur Bearbeitung des gleichen Aufgabenvolumens im Stapelverarbeitungsbetrieb.

- Also müssen entsprechend große Maschinen installiert werden, die diesen Mehraufwand bei der transaktionsorientierten Datenverarbeitung bewältigen können.

Dieser Gedanke wäre nur dann richtig, wenn man ein Datenverarbeitungssystem in all seinen Komponenten leistungsmäßig proportional beliebig steigern könnte und der Kostenzuwachs so klein wäre, daß die geringere mittlere Auslastungsmöglichkeit großer Realtime - Rechner kompensiert wurde. Das ist aber nicht der Fall, lediglich Zentraleinheit und Hauptspeicher erfüllen zur Zeit in etwa diese Anforderungen, während die

peripheren Geräte - speziell Plattenspeicher und Bänder - praktisch keinen nennenswerten Leistungszuwachs zulassen. Bestimmend für die in diesem Zusammenhang richtige Auslastungsmöglichkeit von Realtime - Systemen ist die Streuung der Ankunftsrate und der Bearbeitungszeit der einzelnen Transaktionen.

- Können Sie das noch etwas detaillierter ausführen?

Bei vorgegebener Antwortzeit und Verarbeitungszeit ist die mögliche Auslastung eines Realtime - EDV - Systems begrenzt und zwar in Abhängigkeit von der Streuung der Ankunftsrate. Unter der Ankunftsrate versteht man die Verteilung der jeweiligen Intervalle zwischen den einzelnen eintreffenden Nachrichten. Je nach Anwendungsfall ist diese Verteilung sehr eng - etwa konstant eine Nachricht je Sekunde - oder aber weit gestreut, so daß zwischen den einzelnen Nachrichten Zeiten in der Größenordnung von wenigen Millisekunden bis zu einigen Minuten vergehen. Es läßt sich mit Hilfe der Warteschlangen -Theorie nachweisen, daß die Streuung dieser Ankunftsrate einen außerordentlich großen Einfluß auf die mögliche Auslastung eines Rechners hat. Bei einem relativ konstanten Eintreffen der einzelnen Nachrichten - das heißt bei einer sehr geringen Streuung, wie sie bei vielen Prozeßrechner - Anwendungen üblich ist - kann wegen der besseren Überschaubarkeit der zeitlichen Verhältnisse im Rechner eine relativ hohe Auslastung des Systems erreicht werden. Hierbei muß lediglich die Bedingung erfüllt sein, daß die Verarbeitungsdauer des einzelnen Falles kürzer ist als der Abstand zwischen zwei aufeinanderfolgenden Nachrichten.

- Also muß auch die Streuung der Verarbeitungszeit einzelner Aufgaben betrachtet werden. Welche Rolle spielt die feste Vorgabe von maximalen Response - Zeiten?

Wir müssen dazu die Wahrscheinlichkeit, in der eine geforderte Response - Zeit

erreicht werden soll, betrachten. Wenn die Forderung an diese Wahrscheinlichkeit sehr hoch ist - wenn also beispielsweise die Reaktion in 95 Prozent der Fälle innerhalb von maximal drei Sekunden erfolgen soll -, dann ergeben sich dadurch selbst bei leistungsfähigen Anlagen sehr niedrige Auslastungsraten. In der Praxis bedeutet das, daß ein entsprechend großer Teil der Anlage im Mittel nicht genutzt werden kann, wenn die geforderten Antwortzeiten eingehalten werden sollen, insbesondere bei einer breiten Streuung der Ankunftsrate, die mit einer ebenso breiten Streuung der Bearbeitungszeit in der Maschine gekoppelt ist.

- Soweit die Warteschlangen - Theorie. Kommt der Parkinson noch hinzu?

Der Parkinson'sche Overhead ergibt sich beim Betriebssystem aus der zuvor erwähnten Notwendigkeit, den Zustand der Anlage auf jede einzelne eintreffende

Nachricht jeweils neu einzustellen, und was man auch nicht vergessen sollte, ständig den Nachrichtenverkehr auf den DFÜ - Kanälen zu steuern. Er wächst bei einer steigenden Anzahl aktiver Benutzer überproportional an und trägt nennenswert dazu bei, daß bei umfangreichen Realtime - Anwendungen eine sehr große Blindleistung benötigt wird, und die effektive Leistung des Systems entsprechend vermindert.

- Ist es im Rahmen der heute üblichen Rechner - Architektur also unumgänglich, daß bei Datenbank - Anwendungen mit stetiger Zunahme der transaktionsorientierten Bearbeitungsfälle - wie es so schön heißt - die Lichter ausgehen, also recht bald selbst große Maschinen überlastet sind?

Etwas vereinfacht betrachtet, heißt die Antwort: Ja. Bei einer großen Zahl von aktiven Terminal - Benutzern, die in der Taktzeit ihres jeweiligen Arbeitsablaufes arbeiten und ständig auf kurze Antwortzeiten angewiesen sind, werden sehr bald Grenzen erreicht, die bei Einzelsystemen oder auch Multiprozessoren der heutigen Rechnergeneration nicht überschritten werden können.

- Gibt es Auswege aus diesem Dilemma?

Der Ausweg aus diesem Dilemma heißt Distributed Processing, heißt Aufbau von Netzwerksystemen, in denen die Funktion der Datenverarbeitung den Anforderungen der Benutzer entsprechend dezentral verteilt sind, ohne jedoch die organisatorische Einheit zu zerstören.

- Sollte also jede Fachabteilung, ihr eigenes Auskunftsystem erhalten? Und was kann man tun, um Insellösungen zu vermeiden?

Die Kunst beim Entwurf großer DV - Systeme besteht darin, zwischen einer Dezentralisierung - also dem Abteilungscomputer mit speziellem Auskunftssystem - und der für die Gesamt - Unternehmung notwendigen Integration unter Beachtung der Gesamtkosten einen Kompromiß zu finden. Leider können der Preisverfall bei Hardware und die relativ hohen Kosten für die Datenübertragungsdienstleistungen der Bundespost heute allzu leicht dazu verführen, nur mit dem Rechenstift Systeme zu konzipieren, die den Interessen des Gesamt - Unternehmens diametral entgegenstehen.

- Wie ist solche Subsystem - Optimierung zu verhindern?

Eine allgemeine Lösung für diesen Problemcomplex gibt es zur Zeit noch nicht. Grundsätzlich sind Fehlentwicklungen nur dann zu verhindern, wenn es gelingt, den nach wie vor notwendigen zentralen Integrationsrechner nicht nur technisch, sondern auch organisatorisch mit den unter Umständen aus technischen oder Kostengründen notwendigen dezentralen Subsystemen zu verbinden. Wie bereits dargestellt, arbeitet der zentrale Integrationsrechner am kostengünstigsten im Batch - Mode.

Daraus folgt, daß den dezentralen Systemkomponenten - den Abteilungsrechnern - die Rolle zufallen muß, die Realtime - Verarbeitung sozusagen abzufangen und eine Umsetzung der zeitlichen Anforderungen vom Realtime in Batch vorzunehmen. Der Abteilungscomputer würde dann mit den Benutzern im Realtime - Mode verkehren, seinerseits aber mit dem zentralen Integrationsrechner im Batch - Mode Nachrichten und insbesondere Dateien austauschen.

- Wie kann dabei sichergestellt werden, daß Update - Informationen einer Fachabteilung in einer anderen Fachabteilung, wo sie auch benötigt werden, rechtzeitig zur Verfügung stehen?

Das hier von ihnen ausgesprochene Problem der verteilten Datenbanken und ihrer Organisation ist bisher nicht gelöst. Soviel wissen wir jedoch heute schon: Bei weitgehender Autarkie der beteiligten Subsysteme muß sichergestellt werden, daß zu festgelegten Zeitpunkten ein Datei - Austausch zwischen den einzelnen Systemkomponenten stattfindet. Da verteilte Datenbanken - in dem von uns besprochenen Zusammenhang - aus technischen und Kostengründen verteilt sind, muß ihre Integration, das heißt ihr materieller Zusammenhang, auch technisch realisierbar sein.

- Das hieße, daß umfangreiche Dateien schnell zwischen den einzelnen Rechnern ausgetauscht werden müßten.

Tatsächlich ist die Forderung zu erheben, daß Dateien in der Größenordnung von einigen Millionen Stellen in sehr kurzer Zeit - zum Beispiel in weniger als drei Minuten - ausgetauscht werden können. Dies ist eine andere Aufgabenstellung als bei den heute üblichen Remote - Anwendungen. Bei der herkömmlichen DFÜ handelt es sich um einen meist Kontinuierlichen Nachrichenstrom relativ geringen Volumens. Voraussetzung für in Vermeiden teurer Realtime - Dinosaurier ist die Möglichkeit, in Netzwerker ganze Dateien sozusagen im Burst - Mode kostengünstig auszutauschen.

- Dafür fehlen wohl derzeit die Technischen Voraussetzungen bei der Bundespost. Zu fragen wäre, ob die ohnehin nicht prohibitiv teuren 48 000 - Baud - Leitungen dafür genügen?

Die heute als schnellste Verbindungen verfügbaren 48 - Kilobaud - Leitungen sind für diese Aufgaben und für viele andere um eine Zehnerpotenz zu langsam. Besonders gilt dies bei den hier nicht behandelten Störungen im Realtime - System. Die Anwender müssen der Post deutlichmachen, welche Vorkehrungen für die mittelfristige Entwicklung getroffen werden sollten, damit diese neuen Probleme des Datei - Austausches beim Distributed Processing gelöst werden können.