Der 3. Juli 1994 war nicht der Tag fuer einige US-Amerikaner im Silicon Valley: Von Haus aus wenig urlaubsverwoehnt, genossen sie ein durch den Nationalfeiertag am 4. Juli verlaengertes Wochenende. Vielleicht wuerde man sich eins dieser komischen Spiele im Fernsehen ansehen, die der Rest der Welt Soccer nennt. Da fiel der Blick auf die Schlagzeile der Seite 1 der "San Jose Mercury News", erstes Blatt der heimlichen US-High-Tech-Kapitale: SCHLAG-

LOECHER BRANDMARKEN DV-PROJEKT.

Den Veranwortlichen und Mitarbeitern der Tandem Computers Inc. duerfte es gruendlich die Sonntagsstimmung verhagelt haben, zog doch die Gazette ihr Unternehmen gehoerig durch den Kakao. Rechner des Spezialisten und weltweiten Marktfuehrers fuer fehlertolerante Systeme hatten sich in einem Top-Prestigeprojekt offensichtlich einen boesen Flop geleistet.

1986 unterzog sich das kalifornische Department of Motor Vehicles (DMV) der Sisyphusaufgabe, 30 Millionen Fahrzeughalter-Daten von einer betagten Sperry-Univac-Applikation auf ein anspruchsvolleres relationales Datenbankmodell zu uebertragen.

IBM verlor seinerzeit das Ausschreibungsfinale mit einem 3090- 400S-Mainframe unter MVS/

ESA und DB/2 klar gegen Tandem, das einen VLX-Nonstop-Rechner mit dem Nonstop-SQL-Datenbankprodukt unter dem Guardian-Betriebssystem aufbot. "Benchmarks", ueberschrieb der US-Journalist Pedro Gomez am 22. September 1989 seinen CW-Artikel, "entschieden Duell IBM gegen Tandem."

"Die Logistik dieses Projekts war ein einziger Alptraum", zitierten dagegen die "Mercury News" einen DMV-Experten. Einer der zwei letzten Projektverantwortlichen des DMV, Don Leachman, wurde in einem internen Bericht konkreter: Gemessen an den Anforderungen der kalifornischen Behoerde, sei das Tandem-System ueberschaetzt worden, protokollierte Leachman schon im Fruehjahr 1992.

Die Negativpresse am 3. Juli 1994 konnte zu keinem unguenstigeren Zeitpunkt kommen: Gerade erst hatten die PR-Strategen von Tandem ueberall auf der Welt Benchmark-Ergebnisse des renommierten und herstellerunabhaengigen TPC-Konsortiums

(Transaction Processing Performance Council) fuer ihre leistungsstaerkste Rechnerfamilie zelebriert, die ihresgleichen so schnell nicht wieder finden wuerden.

Gleich mit drei ihrer zu massiv-parallelen Systemen skalierbaren "Himalaya"-Maschinen hatten sie die Konkurrenz von HP, AT&T, IBM, Sun, Fujitsu, ICL, Bull und Unisys das Fuerchten gelehrt. Tandems Topmodell mit 112 Prozessoren spulte den TPC-C-Test am 15. Juli 1994 gar 14,8 mal schneller ab als das staerkste Nicht-Tandem- System, ein AV-9500-System von Data General, das 1416 TPC-C- Transaktionen pro Minute schaffte.

So sicher waren sich die Tandem-Vertreter der Staerken ihrer Rechner, dass sie ihr bestes Ergebnis von 20 918 Transaktionen pro Minute als Dollarbetrag auslobten - zahlbar an eine gemeinnuetzige Institution -, sollte es einem Konkurrenten innerhalb eines Jahres gelingen, ihre Himalaya-Spitzen zu erklimmen. Und dann solch ein Artikel.

Vor diesem Hintergrund stellt sich die Frage, welche Aussagekraft Benchmarks eigentlich besitzen. Die mehr oder weniger ausgekluegelten Hindernislaeufe ueber kuenstliche, realitaetsferne Parcours seien rein synthetischer Natur, monierten Insider immer wieder - von Hard- und Softwareherstellern zudem missbraucht, um ihre Compiler auf die jeweils speziellen Testanforderungen windschnittig zuzuschneidern. Traumhafte Testergebnisse ergaeben sich da zwangslaeufig.

Nur eins seien die Benchmarks eben nicht, kritisieren Kenner der Szene: tauglich, ein Abbild des DV-Alltags wiederzugeben.

Das DMV-Team hatte seinerzeit gehofft, mit einer gehoerigen Stange Geld fuer eine extensive Systemanalyse genau diese Wirklichkeit hochrechnen zu koennen. Ueber eine Million Dollar, so Gomez, habe man allein in der Finalrunde investiert, um das bestmoegliche aller Wettbewerbssysteme herauszufiltern. Neun Mannjahre veranschlagten die Verantwortlichen im kalifornischen Strassenverkehrsamt fuer die Auslotung des Klassenbesten. Die Dienstleistungen der beiden Beratungsunternehmen Codd and Date Consulting Group und Andersen Consulting schlugen mit 400 000 Dollar zu Buche.

Fuer Anwender ist diese Geschichte alles andere als trivial. Koennte sie doch zu einem irrigen Schluss verleiten: Wenn schon solch ein extrem aufwendiges Analyseverfahren ins Chaos fuehrte, dann seien Benchmarks e la Linpack, Dhrystone oder die Suiten der Testkonsortien System Performance Evaluation Corp.

(Spec), der AIM Technology oder des TPC erst recht unge-

eignete Instrumente, Computersysteme gegeneinander aufzuwiegen.

Doch eins haben diese Gruppierungen gemeinsam: Es handelt sich bei ihren Pruefsuiten um herstellerunabhaengige beziehungsweise normierte Verfahren, auf die sich in der Regel alle gewichtigen Industriekraefte des DV-Marktes geeinigt haben. Sie lassen mit Einschraenkungen vergleichende Aussagen zu unterschiedlichen Rechnersystemen zu, weil ihre Testbedingungen nachvollziehbar und ueberpruefbar sind - ein gewichtiges Argument fuer Anwender, die offensichtlich alle ihre Erfahrungen mit den Versprechungen von Herstellern gemacht haben. "Jeder sagt doch, sein System sei das beste." Deswegen sind Vergleichswerte fuer Bernhard Braeunig, Hard- und Software-Einkaeufer bei der Landesbank Hessen-Thueringen, durchaus eine Hilfe. "Sie muessen allerdings", schraenkt er ein, "allgemein verfuegbar sein".

Und sie duerfen nicht den Stempel eines einzigen Herstellers tragen. Genau aus diesem Grund gerieten etwa die TPC-A-Benchmarks 1993 erheblich ins Gerede.

Oracle hatte den TPC-A-Benchmark durch den Einsatz der sogenannten diskreten Transaktionstechnologie in der 1992 vorgestellten Datenbankversion Oracle 7 entscheidend veraendert. Das setzte zwar Hardwarehersteller in den Stand, einen Leistungsrekord nach dem anderen zu produzieren - weswegen uebrigens die damals haeufig benutzte Informix-Datenbank etwas in den Windschatten von Oracle geriet. Die Aberdeen Group urteilte jedoch in ihrem Report vom 19. April 1994, die so gewonnenen Resultate seien "fuer die Mehrzahl der IS-Entscheidungstraeger irrelevant". Oracle habe naemlich eine TPC-A-Version kreiert, bei der ausschliesslich Oracle der Ideengeber sei.

Die TPC-C-Testsuiten hingegen haben einen guten Ruf bei Anwendern. "TPC-C ist neutral und deshalb durchaus ernstzunehmen", meint Enrico Alff von der Audi AG. Zwar muesse man auch die damit gewonnenen Ergebnisse genau pruefen, "denn hundertprozentig standardisiert ist auch hier nicht alles". Der grosse Vorteil allgemein verfuegbarer Resultate sei aber, dass man sich den erheblichen Aufwand eigener Tests sparen koenne, wenn man vor Investitionsentscheidungen stehe oder ein neues Produkt richtig einschaetzen wolle.

Dieses Argument wiegt in der Tat schwer, haelt man sich die immensen Ausgaben des DMV vor Augen. Sowohl Alff als auch sein Kollege Braeunig sind sich allerdings einig, dass Benchmarks immer nur im Licht der Alltagsanforderungen von DV-Abteilungen zu sehen sind. Braeunig: "Fuer uns stellt sich immer die Frage: Ist ein bestimmter Benchmark fuer unsere kommerziellen Anwendungen halbwegs repraesentativ?"

An dieser Gretchenfrage scheiden sich denn auch die Argumente: Einerseits, so der DV-Manager einer grossen Zigarettenfabrik, scheue man zwar den erheblichen Aufwand eigener Tests. Andererseits "haben wir aber Probleme, anderen vorbehaltlos zu glauben".

Bei Industrie-Benchmarks sei er skeptisch: Die IBM zeige einem heute mit einem Benchmark auf, eine individuelle Problemstellung sei auf ihren blauen Rechnern am besten zu loesen, und "morgen beweist Ihnen HP mit einem anderen Test genau das gleiche fuer deren Rechner."

Er versucht deshalb, sich im Vorfeld von Kaufentscheidungen bei ihm bekannten Unternehmen und solchen vergleichbarer Groessenordnung und aehnlicher Aufgabenstellung schlau zu machen - ein Verfahren, das nicht ganz unueblich zu sein scheint. Der Kollege einer bekannten Kuechenmoebelfirma strickte sich ein Variantengenerator- Testverfahren, das er auf Systemen von befreundeten Unternehmen laufen laesst und mit den Ergebnissen seines aktuellen Rechners vergleicht.

Fuer Anwender gipfelt die Problematik von Benchmark-Ergebnissen letztlich in deren Vergleichbarkeit: Tandem habe seine TPC-C-Tests auf Himalaya-Rechnern, mithin auf massiv-parallen Systemen, durchgefuehrt, auf denen zudem das proprietaere Nonstop- Betriebssystem und die Tandem-eigene Nonstop-SQL-Datenbank liefen, noergelte die Konkurrenz. Offenheit koenne man da vergessen, ausserdem wuerden im Vergleich mit den Unix-basierten SMP(Symmetrical Multiprocessing)-Rechnern etwa von Sun, HP oder AT&T GIS Aepfel mit Birnen verglichen.

Indirekt pflichtet die Meta Group Inc. in einem Report vom 15. Juni 1994 dieser Einschraenkung bei, wenn sie schreibt, heutige MPP-Architekturen seien noch "unreif", es werde noch drei bis fuenf Jahre dauern, bis sie wettbewerbstauglich seien.

Allerdings sagen die Analysten aus den USA auch, dass Tandems Nonstop-SQL neben Teradata DBC das einzige heute verfuegbare und fuer MPP-Architekturen optimierte Datenbankkonzept darstelle.

Die Aberdeen-Analysten andererseits bescheinigen den Tandem- Ingenieuren, einen guten Job bei der Oeffnung ihrer proprietaeren Softwareplattform gemacht zu haben. Sie realisieren heute industrieweit genutzte APIs wie SQL und C++, unterstuetzen ferner offene Standards wie den Transaktionsmonitor Tuxedo, DCE, Corba, Posix, XPG4 oder Microsofts ODBC- sowie MAPI-Schnittstellen.

Tandem pocht ferner auf ein im Vergleich zu den Unix-Anbietern sehr guenstiges Verhaeltnis bei den Kosten pro Transaktion, worauf die Aberdeen Group ebenfalls hinweist. Deren Fachleute attestieren den Tandem-Systemen im uebrigen eine extrem gute Skalierbarkeit.

So eignet sich das DMV-Beispiel vor allem als Exempel, um aufzuzeigen, dass auch intensive Benchmark-Laeufe spaeteren Problemen nicht lueckenlos vorbeugen koennen. Die TPC-C-Ergebnisse der Himalaya-Rechner sind jedenfalls so aussergewoehnlich, dass die Tandem-Mitarbeiter gute Chancen haben, am naechsten amerikanischen Nationalfeiertag mit dem ausgesetzten Preisgeld selbst ein rauschendes Fest veranstalten zu koennen.