LONDON - Würde die IBM die Spezifikationen ihres eigenen Leistungstests "Ramp-C" offenlegen, so ließen sich die derzeitigen Benchmark-Streitigkeiten leichter lösen. Der Branchenprimus will jedoch zunächst die Standardisierung des Debit/Kredit-Tests durch das US-amerikanische "Transaction Processing Council" (TPC) abwarten.

Die vollständige Offenlegung des IBM-Ansatzes für die Leistungsmessung unter Cobol (Ramp-C) würde es anderen Software- und Systemherstellern erlauben, ihre Produkte dem gleichen Testverfahren zu unterziehen, das Big Blue intern benutzt. Und das wiederum bedeutet einen Schritt vorwärts bei der Klärung der langdauernden Benchmark-Debatte.

Bis dato hat die IBM jedoch nur einen groben Überblick über ihre Ramp-C-Spezifikation gegeben; sie setzt das Verfahren ein, um die Leistungsmerkmale von Systemen zu bestimmen, die sich noch in der Entwicklung befinden, und um die Systeme der Mitbewerber zu testen.

Einigung schwieriger als anfangs erwartet

Die vollen Ramp-C-Spezifikationen werden die Armonker voraussichtlich erst dann veröffentlichen, wenn die Bemühungen des TPC von Erfolg gekrönt sind. Das "Council" wurde 1988 von 26 Software- und Systemherstellern ins Leben gerufen; es hat sich zur Aufgabe gemacht, die Implementation des häufig eingesetzten Debit/Kredit-Benchmark zu standardisieren und zu regulieren.

Das Gremium hatte gehofft, die Arbeit bis Ende 1988 fertigzustellen. Aber die Aufgabe, alle Parteien zu einer Übereinstimmung zu bringen, ist offensichtlich komplexer als die TPC-Gründer, die unabhängigen Berater Tom Sawyer und Omri Serlin, vorhergesehen hatten. IBM ist Mitglied des Council - ebenso DEC, Hewlett-Packard, Relational Technology, Oracle, Tandem und Unisys.

Der verschiedenartige Einsatz bei den Herstellern hat zu technischen Problemen beim Debit/Kredit-Test geführt. Sollte es dem TPC gelingen, diese Probleme zur Zufriedenheit der IBM zu lösen, so wird der blaue Riese in Erwägung ziehen, die vollen Spezifikationen des Ramp-C zu veröffentlichen.

Immerhin hat IBM über Ramp-C schon soviel verlauten lassen, daß Unisys behaupten kann, eine eigene Version erstellt zu haben. Big Blue bestreitet jedoch, daß es möglich sei das Verfahren nachzubauen, ohne technische Details zu kennen, die zur Zeit noch von der Veröffentlichung zurückgehalten werden. Allerdings lüftet das Unternehmen den Schleier stückchenweise - umso mehr, je stärker es einen aktiven Part in der öffentlichen Debatte über Benchmarking einnimmt.

Es ist mittlerweile bekannt, daß Ramp-C einen Test über die kommerzielle Kapazität eines Systems darstellt. Der Benchmarkt-Ansatz wird von IBM hauptsächlich genutzt, um Prozessoren der Mittelklasse zu evaluieren. Aufgebaut ist Ramp-C aus vier Arten interaktiver Transaktionen - nach Schwierigkeitsgraden geordnet: "einfach", "durchschnittlich", "komplex" und "sehr komplex".

Schwierigkeitsgrade von einfach bis sehr komplex

Alle vier Arten laufen während des Tests zur gleichen Zeit ab. Die "einfache" Transaktion greift auf zwei Daten-Files zu und simuliert einen Benutzerbildschirm mit einem Input-Feld und 23 Output-Feldern von insgesamt 533 Zeichen. Diese Transaktion repräsentiert die Verarbeitung von 70 Cobol-Statements.

Die "sehr komplexe" Transaktion spricht fünf Daten-Files in 41 Aktivitäten an und baut einen Schirm mit 74 Feldern auf, die 689 Zeichen enthalten; sie entspricht einer Verarbeitung von 625 Cobol-Zeilen. Ein Terminal-Netzwerk wird durch den Einsatz der Teleprocessing-Netzwerk-Simulatorsoftware von IBM nachgebildet, die auf einem 4381 Mainframe läuft.

IBM veröffentlichte auch schon Vergleiche von Ramp-C und Debit/Kredit: Der Hauptunterschied beider Verfahren liegt darin, daß Debit/Kredit eine Response-Zeit von unter einer Sekunde voraussetzt und verschiedene Möglichkeiten anbietet, um dieser Zeit zu entsprechen. Ramp-C hingegen soll zunächst einen Punkt ermitteln, an dem das System mit einer Kapazität von 70 Prozent läuft, um dann eine Anzahl leistungsbestimmter Antwortzeiten zu generieren.

Debit/Kredit kennt nur einen Typ von Transaktion. Der Test simuliert einen Zugriff auf vier Daten-Files durch einen Schrim mit 20 Feldern und 200 Zeichen. Die Transaktion entspricht 25 Cobol-Lines. Zudem entwickelte IBM einen dritten Benchmarktest der speziell für Bürosoftware und -systeme ausgelegt ist. Das Verfahren wurde auf mittelstarken Prozessoren eingesetzt, zum Beispiel DECs "AII-inone"-Produkte auf der VAX-Serie und "Deskmanager" von Hewlett-Packard auf der HP-Serie 3000.

Benchmark-Zentrum aus dem Boden gestampft

Ihr Benchmark-Zentrum für Prozessoren dieser Klasse richtete die IBM vor über zweieinhalb Jahren ein. Mehr als 70 Systeme sind in diesem Zentrum installiert; sie stellen eine Mischung aus IBM- und Fremdsystemen dar.

Die Benchmarks, die IBM für die Office-Automation-Software veröffentlicht hat, geben einen Eindruck davon, wie umfangreich die Hardware ist, die IBM in diesem Midrange-Benchmark-Zentrum einsetzt. So gibt es dort DEC-VAX-Prozessoren mit entsprechender Peripherie AS/400 Prozessoren mit Peripherie und HP-Systeme. Darüber hinaus mußte IBM in die Software, die auf diesen Hardware-Basen läuft, sowie in das entsprechende Wissen, um die Systeme lauffähig zu halten, investieren.

Die Softwarehersteller werden bald merken, was IBMs Hardware-Mitbewerber schon seit geraumer Zeit wissen: Wenn IBM anfängt, sich ernsthaft um Performance oder einen anderen Vergleich zu kümmern, kann das Unternehmen in kürzester Zeit ein exzellentes Zentrum mit hochkarätigem Personal aus dem Boden stampfen.

Ist ein solches Zentrum erst einmal etabliert, unter Volldampf und willens, in der Öffentlichkeit aufzutreten, werden die Mitbewerber schnell lernen, ihre Vorankundigungen bezüglich der Performance vorsichtiger zu handhaben. Denn IBM nähert sich einer Aussage zum Thema Leistung mit der ihr eigenen Gründlichkeit, die den Mitbewerb bisweilen entmutigen muß.

Die ersten Softwarehersteller, die den Druck zu spüren bekommen, werden aller Voraussicht nach die Anbieter von Office-Automation-Software sein. Im Zentrum des Interesses standen bislang der Ramp-C-Benchmark zur Bewertung kommerzieller Systeme und der transaktionsorientierte Debit/Kredit-Test. Während die Debatte über diese zwei Benchmarks derzeit hohe Wellen schlägt, scheint der innerhalb der letzten beiden Jahre entwickelte "Office-Benchmark" der Prüfstein zu sein, der die meisten Auswirkungen nach sich zieht.

Sechs Monate, nachdem die IBM ihr Mittelklasse-Leistungsanalyse-Zentrum in Texas eröffnet hatte, begann sie die Arbeiten zur Entwicklung dieses Tests für Büroautomationspakete. Der Benchmark testet alle üblichen Funktionen eines OA-Programmes: beispielsweise das Erstellen und Absenden einer Notiz, die Durchführung elektronischer Mail-Arbeiten sowie das Anschauen und Updaten eines Kalenders. Diese Funktionen werden in verschiedenen Zusammenhängen miteinander kombiniert - je nachdem, in welcher Zusammensetzung und Häufigkeit sie üblicherweise, entsprechend vorhergehenden IBM-Untersuchungen, in Büroautomationspaketen verwendet werden.

Office-Benchmark für mittlere Systeme ausgelegt

Die unterschiedliche Betonung, die Anwender auf die verschiedenen Teile eines Büroautomationspakets legen, sind in die Test-Routinen der IBM eingearbeitet. Entsprechend der Voruntersuchung ist das Verfassen und Absetzen einer Notiz über ein elekronisches Postsystem in 6 von 19 Ereignissen aktiviert, wenn ein Büroautomationspaket benutzt wird. Textverarbeitung wird in 2 von 19 Fällen aufgerufen. Diese und andere Eigenheiten des Einsatzes von Office-Automation-Software werden direkt in dem entsprechenden Benchmark reflektiert.

Der Benchmark wird eingesetzt, um das System unter Testbedingungen zu fahren. Von der Bürobesatzung benutzte Terminals sind simuliert; der Host-Computer stellt aufgrund seiner Konfiguration ein Maximum an Leistung bereit. Zudem hat die IBM ihre Testobjekte im Markt für Büroautomation sorgfältig innerhalb der mittleren Klasse ausgewählt: bei DEC und HP, die als bekannteste Mitbewerber im Bereich der Büroautomationssoftware gewertet werden.

Die DEC-Prozessoren wurden mit Digital-eigener "All-in-one"-Software und die HP-Prozessoren mit dem "Deskmanager" geladen. Im Vergleich dazu läuft auf einer Mittelklasse- AS/400 das IBM-Büropaket unter dem Betriebssystem OS/400, "OS/ Office" (siehe Tab. 1 ).

Für Mitbewerber und Anwender stellt sich die Frage nach der Korrektheit dieser Leistungsmessungen. Amerikanische User können die Antwort bald selbst herausfinden, indem sie ihre Version der IBM-OA-Software beziehungsweise jede andere IBM-System- oder Anwendungssoftware in dem texanischen Zentrum ablaufen lassen.

Wollen die Anwender die Ergebnisse, die sie erhalten, mit denen anderer Hersteller vergleichen, so werden sie allerdings die betreffenden Hersteller davon überzeugen müssen, daß sie die passenden Einrichtungen zur Verfügung stellen sollen. Die DEC- und HP-Hardware, die in dem IBM-Zentrum steht, ist nämlich nur Big Blue selbst zugänglich.

Die Konkurrenten werden also in eigene Zentren zu investieren haben, wenn sie zu einem klaren Ergebnis über die Aussagefähigkeit der IBM-Werte kommen wollen. Zu Beginn ihres Einstiegs in die öffentliche Diskussion hat IBM denn auch klargestellt, daß ernsthafte Mitbewerber ebenfalls ein solches Zentrum auf bauen müßten. Viele der Angesprochenen besitzen bereits etwas Vergleichbares.

Allerdings ist es teuer, diese Zentren zu unterhalten. IBM hat neben der eigenen Ausrüstung solche von DEC, HP und Data General installiert. Die Company unterhält Personal, das die System- und Anwendungssoftware auf dem laufenden hält. Durch ihr Engagement in der Debatte über Benchmark-Systeme hat die IBM die Einsätze für ihre Mitbewerber erhöht. Wenn DEC oder HP den Leistungsdaten, die IBM für OA-Software veröffentlicht, entgegentreten wollen, werden sie letztlich genausoviel in eine Testeinrichtung mit einer ähnlichen Konfiguration investieren müssen wie der Branchenprimus.

Während das IBM-Zentrum auf der einen Seite die Schwellen für einige Mitbewerber erhöht, ist es für andere Mitbewerber von direktem Vorteil: Unabhängige Hersteller bekommen von IBM einen wachsenden Datensatz darüber in die Hände, was die gebräuchlichsten Hardware-Plattformen leisten; sie können dann wählen, welchen Benchmarks sie Beachtung schenken und welche sie an ihre Kunden weiterreichen wollen.

Will der Hersteller die Geschwindigkeit eines Systems hervorheben, so wird er den Debit/Kredit-Benchmark anführen. Der Test ist in einer Art und Weise ausgelegt, die ungeachtet der Kapazität eines Systems auf die beste Antwortzeit zielt.

Soll die Kapazität eines Systems im Vordergrund stehen, also die Anzahl der Anwender, die sinnvoll unterstützt werden, so wird sich der Hersteller auf den Ramp-C-Benchmark stützen. IBM hat dieses Verfahren entwickelt, um das zu testende System mit einem für die Benutzer akzeptablen Antwortverhalten an die Grenzen der Kapazität zu fahren.

Es gibt jedoch immer noch einige Lücken in dem Benchmarking-Bild, das die IBM der Öffentlichkeit präsentiert. Mainframes lassen sich nicht mit Mittelklassesystemen vergleichen und Midranges wiederum nicht mit PCs.

Nun, da die IBM so offen in die Diskussion eingestiegen ist, verstärkt sich der Druck zur Teilnahme für alle Software- und Systemhersteller. Das führt auf alle Fälle dazu, daß der Markt von den vielen undurchsichtigen Leistungsdaten gesäubert wird. Und dann erst wird der richtige Konkurrenzkampf beginnen.

IBM und Digital Equipment haben in der Benchmark-Frage bereits die Klingen gekreuzt: Unter Einsatz des Debit/Kredit-Banchmark hat DEC vier DEC-Systeme und zwei IBM-Systeme evaluiert; dabei entstanden einige für Big Blue wenig schmeichelhafte Aussagen (siehe Tab. 2).

Die DEC-Systeme fuhren "DECintact"; die IBM-Rechner arbeiteten mit CICS und VSAM. Die Armonker waren geschockt von den Ergebnissen: Nichts, was bisher in ihrem Benchmark-Zentrum gelaufen war, bestätigte diese Zahlen. Das Unternehmen ließ eine eigene Testreihe des Debit/Kredit laufen; die Ergebnisse waren bemerkenswert different (siehe Tab.3).

Zur Zeit existieren zwei Hauptversionen des Debit/Kredit-Benchmark. "TP1" bedeutet normalerweise, daß der Debit/Kredit mit einem Treiberprogramm innerhalb des Testsystems gefahren wird. Diese Variante nutzen hauptsächlich die Hersteller relationaler Datenbanken, die stärker an dem Antwortzeitverhalten der Datenbank als an der des Systems interessiert sind. "ET 1" wird meist mit einem externen Simulator für den Test eingesetzt; die Version läuft auf einem Prozessor, der zwar mit dem Testsystem verbunden ist, aber separat arbeitet.

Wenn die Hersteller mit ihrem höheren technischen Niveau sich schon nicht über einen öffentlichen Benchmark einigen können, wie sollen sich dann die User durch dieses Minenfeld tasten? - Die Anwender müssen vor allem ihre Prioritäten im Kopf behalten: Es gibt mindestens vier Meßpunkte für einen kommerziellen Benchmark. Am gebräuchlichsten ist die grundsätzliche Geschwindigkeit der Instruktionen; sie wird oft in Millionen Instruktionen pro Sekunde (MIPS) gemessen.

Die Antwortzeit ist der zweite Meßpunkt für die Leistungsbestimmung. Hier ist der Hauptfaktor die benötigte Zeit pro Funktion. Der Durchsatz eines Systems, mit anderen Worten: seine Kapazität, ist der dritte Punkt; hier werden die beendeten Transaktionen in einer gegebenen Zeit gemessen.

Letztendlich müssen die Anwender aber auch auf ihre Bedürfnisse bezüglich der Zahl der mit dem System verbundenen Anwender achten. Hier ist die Anzahl der physisch anschließbaren Arbeitsplätze ebenso wichtig wie auch die Anzahl der aktiven User, die zu jeder Zeit tatsächlich bedient werden können. So mag zum Beispiel ein System 200 unregelmäßig anfragende Anwender verkraften - aber nur 20, die gleichzeitig schreiben, kompilieren oder Programme testen können.

Nachdem die Anwender sich darüber im klaren sind, was sie exakt getestet haben wollen, können sie sich auf den Benchmark spezialisieren, der ihnen die benötigten Daten zur Verfügung stellt. Wenn Anwender akzeptieren, daß die totale Netzwerkzeit irrelevant ist und beispielsweise 95 Prozent der Transaktionen innerhalb einer Sekunde bedient sein sollen, dann geht der Debit/Kredit einen guten Weg, diese Daten bereitzustellen.

Die Anzahl der Benchmark-Varianten erhöht sich eher, als daß sie geringer wird. Diese Tests werden einerseits die Systeme in einem stärker detaillierten und komplexeren Vorgehen testen; andererseits schaffen sie die Gelegenheit für noch mehr Konfusion und technische Streitereien - solange, bis die Autorität und der Einfluß des TPC gefestigt und erweitert werden, um auch andere Benchmarks abzudecken.

Technische Spezifikationen eines Debit/Kredit-Benchmarks:

- Zugriff auf vier Daten-Files

- sieben logische Input/Output-Aktionen

- festgelegte Anzahl von Files

- variable Anzahl von Records auf jedem File

- 20 Terminal-Felder

- 200 Zeichen in den Terminal-Feldern

- Transaktion entspricht 25 Zeilen Cobol

- Transaktionen können im Test konstant oder exponentiell auftreten

- Transaktionen müssen beendet werden

- Der Meßpunkt ist die interne Antwortzeit: Wie lange dauert es vom ersten Bitstrom der Transaktion zum Prozessor bis zum letzten Bitstrom, der den Prozessor zum Terminal hin verläßt?

- Für 95 Prozent der Transaktionen muß die Antwortzeit unter 1 Sekunde liegen.

Der Debit/Kredit-Benchmark simuliert die Verarbeitung, die nötig ist, um eine finanzielle Transaktion von einem automatischen Bankschalter aus durchzuführen.

Die vier Files sind Kundenkonto, Zweigstellen-File, Bankschalterdatei und historischer File

Der Transaktionsfluß im einzelnen:

1. Beginne die Transaktion

2. Lies eine Nachricht von 100 Bytes von einem Terminal

3. Berichtige einen Konten-File

4. Schreibe einen Historien-File

5. Berichtige eine Schalterdatei

6. Berichtige eine Zweigstellendatei

7. Schreibe eine 200-Byte-Meldung an ein Terminal

8. Bestätige die Transaktion

Für jede Transaktion pro Sekunde, die gemessen wird, benötigt der Debit/Kredit-Benchmark:

- 100 000 Kontensätze

- 100 Schaltersätze

- 10 Zweigstellensätze und

- 2500 Historien-Files

*Richard Sharpe ist freier DV-Fachjournalist in London.