Als Client nutzt Network Computing einen Acer Altos R520 unter Ubuntu-8.04.1-64-Bit-Server mit einem Quad-Core-Xeon-5310, 2 GByte RAM und dem Emulex-HBA. Beide HBA-Ports sind direkt mit dem Datacore-Server verbunden.
Die Performance-Tests schieben einen 16 GByte Datenblock mit Null-Bytes per dd von der Linux-Maschine auf das Speichersystem.
Im ersten Test schiebt das Testteam die Daten am Cache des Datacore-Servers vorbei auf das SAS-Array. Die ersten Messungen fallen dabei überraschend niedrig aus. Lediglich 200 MByte/s gehen über die Glasfaser - das schaffen auch die 2-GBit/s-FC-System des Labors.
Laut Datacore darf der Anwender aber auch nicht viel mehr von einem Raid-5-Array mit nur fünf Spindeln erwarten, selbst wenn die Platten bis zu 150 MByte/s interne Transferrate liefern sollten.
Um die Geschwindigkeit der 8-GBit/s-Leitungen auszureizen, richtet das Laborteam so genannte »Network Managed Volumes« auf der Datacore-Maschine ein. Diese virtuellen LUNs mit Thin-Provisioning nutzen den Cache des Speicherservers voll aus.
Im zweiten Anlauf schafft es Network Computing damit, beim Schreiben Transferraten von 580 MByte/s zu erzielen. Verglichen mit den schnellsten 4-GBit/s-Messungen, die im Bereich 380 MByte/s liegen, ist das ein spürbarer Fortschritt. Rein rechnerisch liegt das Ergebnis im Bereich 6 GBit/s und lässt damit noch etwas Luft nach oben.
Startet Network Computing parallel Transfers auf beiden 8-GBit/s-Kanälen, beträgt die Performance rund 490 MByte/s pro Kanal.
Stand heute sind die bestehenden Open-Systems-Rechner noch gar nicht in der Lage, die volle Bandbreite der 8-GBit/s-FC-Technik auszuschöpfen. Daher sind 8-GBit/s-Kanäle vorerst nur für die Anbindung großer Speichersysteme mit vielen SAN-Clients von Interesse.
Später sollten Vmware-Server folgen, aber nur dann, wenn sie speicherintensive VMs mit N-Port-Virtualisierung verwenden.