Quelle: obs/Handicap International

Die beste Basis für eine Kaufentscheidung sind Tests und Benchmarks aus verlässlichen Quellen. Wer der Werbung nicht traut, sondern selbst testet und die Ergebnisse veröffentlicht, gerät aber schnell in ein Minenfeld aus Lizenzfallen, Testverboten und Mogeleien der Hersteller.

Die Industrie investiert viel Geld in die Werbung, die den Käufer von den Vorzügen ihrer Produkte überzeugen soll, und scheut auch nicht vor mancher Halbwahrheit oder Übertreibung zurück. Bei vielen Anschaffungen im Computerbereich genügt es nicht, die Prospekte und technischen Daten der Hersteller durchzublättern, um eine weise Kaufentscheidung zu treffen. Hier helfen Testergebnisse aus glaubwürdigen Quellen wie Zeitschriften oder eigene Benchmarks – wobei die Tests gut vorbereitet sein müssen, um später auch aussagekräftig und vor allem beständig zu sein.

Hassliebe der Hersteller

Beim Verhältnis von Software- und Hardware-Herstellern zu Benchmarks kann man ohne Übertreibung von einer Hassliebe sprechen: Gerade bei sehr ähnlichen Produkten, etwa Tintenstrahldruckern, können sich die Hersteller kaum durch Features von der Konkurrenz abgrenzen. Gibt es hingegen einen allgemein anerkannten Test kann der Hersteller bei einem Sieg oder einer guten Platzierung mit dem Testergebnis oder gar einem Logo werben, zudem erfährt das Produkt durch die Veröffentlichung des Tests viel Aufmerksamkeit.

Der Standardbenchmark des Linux-Magazins für den Test von Workstation-Grafikkarten ist die Spec Viewperf Suite [1]. Deren Stärke ist, dass sie echte Anwenderdaten aus weit verbreiteten CAD- und Render-Programmen für den Test verwendet: Hersteller Spec hat die Grafikdaten von Programmen wie Catia, Pro/Engineer (Abbildung 1) oder Maya (Abbildung 2) unmittelbar vor dem Grafikkartentreiber abgefangen (gesnifft) und als Testdatensatz gespeichert.

Die Viewperf Suite überträgt diese Daten beim Test lediglich mit maximaler Geschwindigkeit zur Grafikkarte, die CPU des Rechners muss sich also nicht mit den aufwändigen 3D-Berechnungen der CAD-Programme herumschlagen. Auch lässt sich mit der Viewperf Suite die Grafikleistung unter verschiedenen Betriebssystemen testen und vergleichen, unabhängig davon, ob die Basisanwendung überhaupt auf das jeweilige System portiert wurde.

Abbildung 1: Die Spec Viewperf Suite verwendet sehr praxisnahe Testdaten. Der Hersteller fängt die Grafikbefehle bekannter Programme wie zum Beispiel des Konstruktionsprogramms Pro/Engineer …

Abbildung 2: … oder des Render-Programms Maya unmittelbar vor dem Grafikkartentreiber ab. Der Testrechner muss die Grafikbefehle nur noch mit maximaler Geschwindigkeit zum Treiber übermitteln.

Mit gezinkten Karten

Die Frame-Raten bei Spielen überprüfte das Linux-Magazin in der Vergangenheit mit den Demo-Levels von Quake 3 Arena und Parsec. Zwei mit verschiedenen Testprogrammen ermittelte Werte helfen etwaige Manipulationen in den Treibern aufzudecken: So “optimierte” ATI im Jahr 2001 den Treiber für den Radeon-8500-Prozessor: Erkannte der Treiber die Demosequenz von Quake, verringerte er selbsttätig die Bildqualität und lieferte somit bessere Ergebnisse [2].

Auch Nvidia hat keine weiße Weste, 2003 überführte Futuremark den Grafikkarten-Hersteller des Betrugs: Der Treiber erkannte spezielle Sequenzen des 3D-Mark-Bench und ersetzte einige Befehlsfolgen, sodass letztlich nur ein Teilbild mit geringerer Farbtiefe berechnet wurde, was die Ausgabegeschwindigkeit drastisch erhöhte.

Für den Test anderer Komponenten und Dienste eines Systems bedarf es weiterer spezialisierter Benchmarks, die Standard Performance Evaluation Corporation, kurz Spec [1], hat eine Reihe fertiger Benchmark-Suites im Programm, allerdings laufen viele nur unter Windows. Eine der Ausnahmen neben der Viewperf Suite ist die CPU Suite, sie eignet sich deutlich besser für die Einschätzung der Rechenleistung als die beliebte Methode, die Kompilier-Zeit des Kernels als Maß für die Geschwindigkeit des Rechners zu verwenden.

Die Zeit, die ein bestimmter Rechner zum Übersetzen des Kernels benötigt, ist zwar durchaus stabil und wird von Randbedingungen wie der Datentransferrate der Festplatte oder auch der Fragmentierung des Dateisystems kaum beeinflusst. Zum Vergleichen mit Zeiten aus früheren Tests oder mit verschiedenen Prozessor-Architekturen taugt das Kernel-Kompilieren aber kaum: Zu groß sind die Unterschiede zwischen dem aktuellen Kernel und etwa der Version von vor einem Jahr. Zudem werden auch die Compiler ständig weiterentwickelt.

Nicht zuletzt verändert sich auch die Standardkonfiguration des Kernels und es kommen immer wieder neue Kernelmodule hinzu. Daher sind die Zeiten, die beim Übersetzen des Kernels ermittelt werden, nur dann vergleichbar, wenn zwei Rechner den gleichen Kernel mit den gleichen Konfigurationsoptionen, dem gleichen Compiler und der gleichen Zielplattform übersetzen.

Trügerische Präzision

Den Datendurchsatz des lokalen Festplattenspeichers ermittelt der FS-Bench [3], der sich auf die Messwerte der beiden Festplatten-Benchmarks Bonnie++ [4] und Iozone [5] stützt. Wie viele andere Benchmark-Programme liefern Bonnie und Iozone Messwerte mit mehreren Nachkommastellen. Diese vermeintliche Genauigkeit ist jedoch trügerisch: Parallel im Hintergrund laufende Dienste verursachen immer Messfehler, die sich durch mehrere Testläufe vielleicht mitteln lassen. In der Praxis sind jedoch Unterschiede von wenigen KByte pro Sekunde in der Transferrate als gleichwertig anzusehen. Das sollte sich auch in einer Wertetabelle und dem zugehörigen Diagramm niederschlagen, indem man die Werte praxisrelevant auf ganze MByte pro Sekunde oder ein Prozent des Wertes rundet.

Für Fileserver-Tests haben sich der Dbench und der Tbench aus der Samba-Testsuite etabliert [6]. Beide skalieren auf Mehrprozessorsystemen gut, weshalb sie das Linux-Magazin in [7] zum Vergleich des ersten Dual-Opteron-Servers mit einem Dual-Xeon-Rechner verwendete (Abbildung 3). Wie bei allen Netzwerk-Benches ist bei der Samba-Testsuite unbedingt zu beachten, dass Clients und Server in einem eigenen Testnetz arbeiten, um Störungen oder Bandbreitenverluste durch den Netzwerkverkehr anderer Rechner im gleichen Netz von vornherein auszuschließen.

Abbildung 3: Die Samba-Testsuite enthält mit Dbench und Tbench zwei Netzwerk-Benchmarks, die auf Systemen mit mehreren Prozessoren gut skalieren.

Das Open Source Development Lab (OSDL) arbeitet seit einigen Jahren an einer Reihe freier Benchmarks, bislang sind allerdings insgesamt nur vier Datenbank-Benchmarks [8] erschienen, die unterschiedliche Anwendungszenarien vom Online-Buchhändler bis hin zum Warensystems eines Großhändlers abdecken. Die Spezifikationen der OSDL-Benches orientieren sich dabei an den renommierten kommerziellen Tests TPC-W, TPC-C, TPC-H und TPC-App des Transaction Processing Performance Council (TPC) [9].

Mit dem MySQL-Bench steht ein zweiter unabhängiger Test zur Verfügung. Bei ihm ist allerdings zu berücksichtigen, dass der MySQL-Bench von Mehrprozessor-Systemen kaum profitiert und sich daher nur für den Test von Ein-CPU-Rechnern eignet. Wer mit dem MySQL-Bench auf Mehrprozessor-Systemen testet, muss sich auf Einwände seitens der Prozessorhersteller oder auch der Systemintegratoren gefasst machen.

Testen verboten

Juristisches Ungemach droht jenen, die sich nicht ausreichend mit den Lizenzbedingungen von Benchmarks und Applikationen beschäftigen: So verbietet zum Beispiel VMware bei praktisch all seinen Produkten im Kleingedruckten grundsätzlich die Veröffentlichung von Testergebnissen, die nicht vorher beim Hersteller eingereicht und freigegeben wurden: “You may not disclose the results of any benchmark test of the Software to any third party without VMware\’s prior written approval.”

Das kommt einerseits presserechtlich einer Zensur gleich und bietet andererseits Potenzial für zahlreiche Abmahnungen, denn bereits die Aussage, eine bestimmtes Programm würde mit der neuen Version schneller oder langsamer laufen als mit der alten, kann ein Benchmark-Ergebnis sein.

Auch Spec hat in den Nutzungslizenzen seiner kostenlosen Benchmarks einige Mindestanforderungen formuliert, die der Tester beim Veröffentlichen der Ergebnisse einhalten muss. Sie betreffen überwiegend die Dokumentation der Testbedingungen sowie die Pflicht, einige der Test- und Konfigurationsdateien auf Anfrage herauszugeben, damit Spec oder ein dem Non-Profit-Unternehmen angeschlossener Partner die Messungen überprüfen kann. Damit diese Überprüfungen unabhängig stattfinden können, verlangt Spec sogar, dass die getestete Hardware in gewissen Fristen öffentlich verfügbar sein muss, bei Prototypen muss zumindest die voraussichtliche Verfügbarkeit angegeben sein.

Beim Interpretieren der Ergebnisse, egal welcher Benchmark sie geliefert hat, ist generell Vorsicht geboten: Wer etwa dem Mainboard eine schlechte Datentransferrate zum RAM zuschreibt, sollte sich vergewissern, dass die CPU nicht zufällig im Stromsparmodus mit verringerter Taktfrequenz arbeitet, weil der Power-Save-Daemon falsch konfiguriert ist. Auch muss das Equipment insgesamt richtig dimensioniert sein: Ein Rechner, der kaum 60 MByte Testdaten pro Sekunde bereitstellen kann, ist zum Beispiel ungeeignet die maximale Datentransferrate von Raid-Systemen zu ermitteln. Solche Messwerte gehören nicht auf eine Website, sondern in den Papierkorb.

Nachprüfung

Einige Hersteller akzeptieren schlechte Platzierungen in einem Test nämlich nicht einfach, sondern hinterfragen sie. Nach Tests in der Presse und auch in Unternehmen, wenn etwa ein größerer Auftrag auf dem Spiel steht, kommt es durchaus vor, dass einzelne Hersteller die Testkriterien und Testverfahren überprüfen. So forderte Lexmark beim Druckertest [10], den die Redaktion kürzlich zusammen mit dem Flughafen München durchführte, die verwendeten Testdokumente und Einstellungen der Geräte an, um die attestierte geringe Reichweite der Tonerkartuschen zu überprüfen.

Wer in einem solchen Fall keine detaillierte Dokumentation der Testbedingungen, die Konfigurationsdateien und die verwendeten Testdaten vorweisen kann, steht im Zweifel auch vor Gericht dumm da, wenn er seine Behauptungen belegen muss. Diese Pflicht zur Dokumentation betrifft durchaus auch private Anwender, die auf ihrer Homepage Benchmark-Ergebnisse ihrer Rechner veröffentlichen. Bescheinigen sie etwa einem Multifunktionsgerät, besonders langsam zu scannen, sollten sie dieses Ergebnis auch sicher reproduzieren können. Andernfalls könnte der Hersteller wegen Rufschädigung klagen oder eine Richtigstellung fordern.

Die im praktischen Test ermittelten Reichweiten von Toner und Tinte weichen durchaus um bis zu 50 Prozent von den Herstellerangaben ab, selbst bei Geräten für den professionellen Einsatz. Beim Druckertest aus [10] erreichten zum Beispiel drei Lexmark-Laserdrucker und Multifunktionsgeräte nur rund 24000 statt der angegebenen 32000 Seiten mit einer Tonerfüllung. Gerade in Unternehmen sind jedoch die Verbrauchskosten von entscheidender Bedeutung, da sie über die Jahre oft höher als der Anschaffungspreis sind.

Selbst solch banale Angaben wie das Fassungsvermögen der Papierkassetten darf man den Herstellern nicht unbesehen glauben. So passen in praktisch alle 500-Blatt-Fächer von Lexmark nur 480 bis 490 Blatt Standard-Kopierpapier mit einem Gewicht von 80 Gramm pro Quadratmeter, da die Fächer auf das in Amerika gebräuchliche und etwas dünnere Letter-Papier ausgelegt sind. Lexmark empfiehlt daher, 75-Gramm-Papier zu verwenden, das jedoch deutlich teurer als das Standardpapier ist.

Wer misst, misst Mist

Selbst bei aller Sorgfalt darf ein Tester nie vergessen, dass die Ergebnisse niemals die ganze Wahrheit erzählen. Bei Computern gibt es während einer Messung so viele Variablen, dass sich ein Messfehler praktisch nicht exakt beziffern lässt. Der Teufel steckt auch hier im Detail: So fällt es während eines Festplattentests kaum auf, wenn ein Cronjob zwischenzeitlich »updatedb« startet. Die gemessene Datentransferrate von Bonnie ist dann aber nicht verwertbar und die Messung muss wiederholt werden – was der Tester aber erst einmal bemerken muss.

Daher gehören das Abschalten aller nicht benötigten Dienste und die Überwachung der Prozesstabelle während des Tests zu den absolut notwendigen Voraussetzungen für faire Tests. Denn nur wer fair testet, kann letztlich die richtige Kaufentscheidung treffen und bekommt im Benchmark-Mienenfeld keinen Ärger mit den Herstellern.