Bereits seit der Version 2.1 ist OSL Storage Cluster in der Lage, bei der Migration von Applikationen zwischen verschiedenen Rechnern die Auslastung der Rechner zu berücksichtigen. Diese Fähigkeiten haben in der Version 3.0 eine erhebliche Erweiterung erfahren, so dass mittlerweile ein leistungsfähiges aber einfach zu bedienendes Framework zum ressourcenbasierten Selbstmanagement eines Rechnerverbundes vorliegt.

Vor allem für betriebswirtschaftliche Anwendungen und Datenbanken spielt die Integer-Performance eines Systems eine entscheidende Rolle. OSL Storage Cluster stützt seine Managementfunktionen in diesem Zusammenhang auf einen eigenen Benchmark, um auch in Clustern mit heterogenen CPU-Implementierungen zu brauchbaren Aussagen zu kommen. Der Administrator ordnet nach diesem System Anwendungen einfach einen hardwareabstrakten Bedarf an Integer-Performance zu; OSL Storage Cluster identifiziert entsprechende Systeme mit ausreichend freien CPU-Ressourcen. Diese hardwareabstrakte Größe zur Beurteilung der Rechenleistung für Ganzzahl-Operationen nennen wir "Relative Integer Performance" - RIP.

Der Benchmark im Detail

Die meisten existierenden Benchmarks sind eine Mischung aus verschiedensten Lastprofilen. Im günstigsten Fall erlaubt dies Rückschlüsse auf die Performance von Anwendungen mit ähnlichen Lastanforderungen. Oft werden allerdings auch unerwünschte Größen miterfasst (etwa Float- oder IO-Anteile in einem Integer-Benchmark) oder es ist schwer zu ermitteln, welche Faktoren zu einem guten bzw. schlechten Ergebnis beitragen.

Der RIP-Benchmark ist daraufhin ausgelegt worden, eine möglichst unverfälschte Aussage zur Performance eines Systems bei bestimmten Integeroperationen zu erhalten. Dabei spielen die Leistungsfähigkeit der CPU, der Speicheranbindung und die Multitasking-Fähigkeiten des Systems eine Rolle. Der Benchmark liefert sowohl Werte für die Geschwindigkeit eines einzelnen Prozesses/Threads als auch für die parallele Ausführung. Dabei ist er so gestaltet, dass sich bei paralleler Ausführung ein deutliches Maximum bei der optimalen Parallelität ergibt. Der RIP-Benchmark enthält ausschließlich Integeroperationen und Anweisungen zur Speicherverwaltung. Disk-IO-Anteile sind ausgeschlossen, der Zugriff auf den Hauptspeicher hat im Vergleich zu Caches (1st/2nd-level) einen stärkeren Einfluß, der Einfluß anderer Programme und des OS-Schedulers wird minimiert.

Da Integeroperationen üblicherweise 32Bit-Datentypen betreffen, in modernen Anwendungen aber auch zunehmend 64 Bit breite Integertypen verwendet werden, liefert der Benchmark für beide Typen entsprechende Werte. Je nach verwendetem Datentyp lassen sich damit gut vergleichbare Aussagen über die Leistungsfähigkeit eines Systems bei Operationen mit dem jeweiligen klar definierten Datentyp gewinnen und brauchbare Prognosen für die Performance entsprechender Programme erstellen.
Etliche Anwendungen arbeiten ausschließlich mit 32Bit-Integertypen, eine zunehmende Zahl verwendet daneben auch long bzw. long long Datentypen mit 64 Bit. Eine ausschließliche Verwendung von 64Bit-Integern ist bei Applikationen jedoch die absolute Ausnahme. Um dennoch eine brauchbare Aussage für Anwendungen mit gemischten Typen zu gewinnen, wird neben den gemessen Werten ein abgeleiteter Wert errechnet: RIPmix. Er ist das geometrische Mittel der jeweiligen Meßwerte und umso besser, je dichter 32Bit- und 64Bit-Performance beieinander liegen.
Die Messwerte werden in einen Bezug zu einem Vergleichswert gesetzt und sind damit dimensionslos. Ein Wert von 1 entspricht der angenommenen 32Bit-Integer Performance eines Intel Pentium mit 100MHz Taktung. Für den 64Bit-Benchmark ist der Wert dann gleich groß, wenn die 64Bit-Operationen mit derselben Geschwindigkeit ausgeführt werden, wie die 32Bit-Operationen. Für ein komplett in 32Bit-Technik ausgelegtes System bedeutet das in der Regel die halbe Performance für die 64Bit-Typen (long long).

Damit liefert der RIP-Benchmark folgende 6 Werte:

Ergebnisse

Nachfolgend eine Auswahl getesteter Systeme.
Für die Multi-Process-Meßwerte gibt die Spalte Procs an, mit wievielen Prozessen die maximale Gesamt-Performance erreicht wird.