Hilfe, mein RAID 0 ist lahm...

  • Hallo,

    im festen Glauben, endlich mal vernünftige Transferraten in den Rechner zu bekommen, habe ich mir jetzt ein RAID 0 gebaut.

    Das ganze besteht aus folgenden Komponenten:

    - 3ware 9650-2LP-Controller (PCIe x1)
    - 2 x Samsung HE502IJ
    - das ganze auf einem Gigabyte EP45-DS3-Board


    Toll, jetzt wird alles mächtig beschleunigt, wahnwitzige Transferraten...
    ... denkste!

    Die beiden Platten im RAID 0 (laut CHIP-"Bestenliste" durchschnittliche Leserate pro Stück ca. 70,9 MB/s) liefern bei mir gerade mal durchschnittlich 105,9 MB/s (siehe Screenshot 1). Erwartet hätte ich mindestens 130 MB/s...

    Das ganze ist gerade mal knapp 10 MB/s schneller als eine einzelne Samsung HD103UJ im gleichen Rechner am Intel-Onboard-Controller im AHCI-Modus (siehe Screenshot 3).

    Besonders wundert mich die niedrige "Burst Speed". Screenshot 2 stammt von unserem Server - gleiche RAID-Karte, hier allerdings zwei Samsung HE103UJ im RAID 1. Auch hier ist die Burst Speed sehr niedrig.


    Ist das normal und hat dafür jemand eine Erklärung?


    Nur falls es jemanden interessieren sollte und zum Vergleich noch Screenshot 4, auch bei uns aus dem Server. DAS nenne ich mal Transferrate... sowas ist leider in entsprechenden "Desktop-Kapazitäten" viel zu teuer. Momentan ist eine einzelne SAS-Platte am Dell-PERC-Controller also knapp 30% schneller als zwei SATA-Platten im RAID 0...


    /EDIT:

    Mit Partitionierung (ca. 200 / 800 GB) kann es nicht zusammenhängen, oder?

  • Moin Christian,

    die Grafik sachts ja deutlich - Controller oder Bus ist der limitierende Faktor. Hast Du evtl einen anderen Steckplatz frei? Chipsatz/Controller-Treiber aktuell? Irgendwelche Raid-Beschleuniger auf der Karte nicht aktiv?
    Ich würde da 140-150 MByte/Sek erwarten.

    Gruß Karl

  • Hallo Karl,

    Zitat von Karl

    Hast Du evtl einen anderen Steckplatz frei?


    Leider nicht. Ein PCIe x1 ganz oben wäre noch frei, direkt dahinter kommt aber leider ein dicker Chipsatzkühler und die Board-Designer rechnen offenbar nicht mit langen x1-Karten. Mit dem aktuellen Steckplatz ist es schon eng - dahinter kommt auch ein Chipsatzkühler, allerdings ein flacher - da "schwebt" das Ende der Karte auch nur ein paar Millimeter drüber. Thermisch nicht sonderlich vorteilhaft...

    Im zweiten PCIe x16-Slot steckt eine zweite Grafikkarte, auf die ich auch nicht verzichten möchte (nein, keine Monsterkarten im SLI/Crossfire für's Zocken, sondern zwei weil ich zwei LUTs (Lookup Tables für Farben) für zwei kalibrierte und profilierte Monitore brauche).

    Auf jeden Fall werde ich die Karte aber mal testweise in den zweiten x16-Slot stecken.

    /EDIT: Gerade probiert, keine Änderung.

    Zitat von Karl

    Chipsatz/Controller-Treiber aktuell?


    Jupp, aktuelles MB-BIOS, aktuelle Karten-Firmware, aktueller Karten-Treiber und aktuelle Intel-Treiber für den P45-Chipsatz.

    Zitat von Karl

    Irgendwelche Raid-Beschleuniger auf der Karte nicht aktiv?


    Habe ich schon nachgeschaut - es gibt nur einen Punkt, in dem man in drei Schritten zwischen "Security" und "Performance" auswählen kann (muss ich nochmal nachgucken was das genau war, auf jeden Fall steht es auf "Performance"). Ebenso habe ich den SATA-Modus überall manuell von "Auto" auf "3.0 Gbps" gestellt, was der Controller aber an sich auch selbst erkennen sollte.


    Ansonsten hat das Teil eigentlich nur diverse allgemeine Settings - RAID-Modus, Verify, Rebuild etc.
    Background-Verify lief übrigens während der Messung nicht, darauf habe ich geachtet.

    /EDIT:
    Folgende Settings dürften Einfluss auf die Performance haben:

    Drive Queing Mode: Enabled
    StorSave Profile: Performance
    Auto-Verify: Disabled
    Auto Carving: Disabled
    Auto-Rebuild: Disabled (sollte bei einem RAID 0 auch keine Rolle spielen, oder?)
    Write Cache: Enabled
    Link Speed Control: 3.0 Gbps


    Das ganze läuft übrigens auf einem frischen Windows XP SP2 mit abgeschaltetem Indexdienst.

    Momentan ist das ganze ein 64k Stripe - die Auswirkungen einer kleineren oder größeren Stripesize dürften für die Durchschnittsgeschwindigkeit aber nicht so extrem entscheidend sein, oder? Auf der ersten Partition des Arrays läuft übrigens das OS.


    Und ich merke gerade, dass ich entweder ein kaputtes Board oder eine schlechte Board-RAM-Kombination (Kingston DDR2-1066) erwischt habe... Gigabyte "An-Aus-Bug" und plötzliche Reboots.....*AAAARGGGGHHHHHH*

    Gruß, Christian

    3 Mal editiert, zuletzt von illCP (27. April 2009 um 23:34)

  • Was mir noch einfällt: Hast Du noch andere SATA-Anschlüsse auf dem Controller frei? Am besten zwei, die "weiter auseinanderliegen" - evtl. sind die beiden aktuell benutzten ja gemeinsam angebunden und kommen sich gegenseitig ins Gehege...

  • Auf dem Gigabyte-Board habe ich alle potentiellen PCIe-"Verstopfer" im BIOS deaktiviert (z.B. LAN- und Sound-Chip) - ungefähr 105 MB/s.

    Test in meinem momentanen Hauptrechner (Asus P5K-Mainboard im zweiten PCIe x16-Slot) - ungefähr 105 MB/s.

    Stripe Size 16, 64 und 256 probiert - ungefähr 105 MB/s.

    Kürzere SATA-Kabel verwendet (halb so lang wie die 3ware-Kit-Kabel) - ungefähr 105 MB/s.


    Und immer Burst-Rates von 130 bis maximal 150 MB/s - meine recht alte 500 GB Samsung HD501LJ (im IDE-Legacy-Modus am onboard-Controller in meinem Hauptrechner) schafft 228 MB/s...

    Die zweite 9560SE-2LP im Server ist im Burst auch sehr langsam, was für mich langsam nur noch einen Schluss zulässt:
    Mein toller 190€ Hardware-RAID-Controller mag für RAID 1 geeignet sein, ist aber für RAID 0 offenbar absoluter Sch****dreck!
    Für gerade mal 10 bis 15 MB/s mehr im Gegensatz zur dritten Single-SATA-Platte am onboard-Controller werde ich wohl kaum ein Stripe-RAID mit doppelter Ausfallwahrscheinlichkeit verwenden.


    /EDIT:

    Die Platten schaffen einzeln am onboard-Controller Burst ~235 MB/s und Average Read ~75,5 MB/s. Ergo sollten theoretisch Average 140 - 150 MB/ drin sein; PCIe x1 sollte ca. 250 MB/s packen.

    Ich schreib' mal eine nette Anfrage an 3ware/AMCC...

    Gruß, Christian

    Einmal editiert, zuletzt von illCP (28. April 2009 um 22:32)

  • Der PCIe-x1 schafft das locker. Da sollten nach overheadabzug für V1.0 um die 200 MB/s oder mehr drin sein. Könnte evtl. auch die Meßmethode falsch sein? Ich nehme für überschlägige transfereischätzungen das "Auxsetup" älterer VD-Versionen (Windows-buffer aus) und lasse mal 2GB schreiben und lesen...
    ...nur um Dein "Testprogramm" als pot. Fehlerquelle auszuschließen.

    Hier: http://www.hardwareluxx.de/community/showthread.php?t=350664 gips 'ne Menge zu lesen.

    Gruß Karl

  • Zitat von Karl


    ...nur um Dein "Testprogramm" als pot. Fehlerquelle auszuschließen.

    Hier: http://www.hardwareluxx.de/community...d.php?t=350664 gips 'ne Menge zu lesen.


    Stimmt - HDTach und HDTune scheinen insbesondere für Hardware-RAIDs nicht geeignet zu sein. Beim Stöbern habe ich noch das hier gefunden (direkt aus der 3ware KB):

    I am using HDTach and HDTune to measure performance on my 3ware RAID array, and the numbers are lower than I expect.

    Gehe ich exakt nach der gegebenen Anleitung für IOMeter vor, erhalte auch wieder ganz tolle Werte...:nein: (siehe Anhang).

    Interessanterweise habe ich eine durchgängig exorbitante Rate im 64k sequential write, 64k sequential read pendelt sich ungefähr auf der Performance einer Platte im Array ein. Bei einem 64k sequential read auf einem 64k Stripe (also quasi "Laborbedingungen") sollte ziemlich exakt die doppelte Leserate einer einzelnen Platte herauskommen, oder?

    Ich habe das ganze wieder in zwei Rechnern gemessen; Die Ergebnisse weichen kaum voneinander ab.

    Interessant wirds allerdings wenn ich "Results Since" von "Start of test" auf "Last update" (also quasi Ansicht des aktuellen Werts) umschalte - hier pendelt die Leserate zwischen ~160 und ~0,5 MB/s, und zwar in regelmäßigen Intervallen von ungefähr einer Sekunde. Man hörts auch in den Platten: Eine Sekunde "Gerumpel", eine Sekunde Stille - entsprechend schwankt die Leserate zwischen voll und fast nix, wobei dann im Schnitt offenbar ziemlich genau die Hälfte herauskommt.

    Ein sequential read mit 128k führt zu nahezu identischen Resultaten.


    /EDIT:

    Mal schauen...

  • Problem gelöst - NCQ (Native Command Queing) ist schuld. Mit deaktiviertem NCQ bekomme ich endlich einen anständigen 64k sequential read-Durchsatz (siehe Anhang) :ja:

    Entweder ist das ein generelles RAID0-Problem oder ein spezifisches mit Samsung-Platten oder diesem speziellen Modell. Auf jeden Fall "stottert" der Transfer ohne NCQ nicht mehr in Abständen von einer Sekunde.


    Trotzdem natürlich vielen Dank an Karl für die Tips!


    P.S.:
    Der 3ware-Support ist ziemlich schnell - ein paar Stunden nach meiner Anfrage hatte ich schon eine Antwort. Da stand die Lösung zwar nicht unmittelbar drin, aber etliche Links zu entsprechenden Themen in deren Knowledge Base. Da habe ich dann zufällig Muster-Benchmarks entdeckt, bei denen in der Test-Konfiguration deaktiviertes NCQ angegeben war.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!