LSI MegaRaid und Dell Perc5/i SAS/SATA PCIe [2|1]

Status
Für weitere Antworten geschlossen.
Tach =)

...ich melde mich mal wieder mit einem Problem.
Wollte gestern mein GA-X48-DS5 Mainboard mit weiteren 2x2GB Ram auf 8GB bestücken, doch leider startet danach windows nicht mehr (Bluescreen)

Kann hier vielleicht jemand sagen woran man erkennt ob das nun ein Problem mit den Speichermodulen oder mit dem Perc5/i ist?

Der Bluescreen geht leider extrem schnell wieder weg, sodass ich nicht lesen kann was da steht :-(
(bis zum Windows-Start habe ich nichts auffälliges am boot-vorgang festgestellt - der Perc initialisiert die Platten usw.)

Und eine weitere Festplatte habe ich auch nicht um einen Windows-Boot ohne Perc testen zu können :-/
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
@Schlingel_INV: danke für die schnelle Antwort

...du würdest also eher auf den Speicher tippen?
Und wegen V-MCH(Northbridge), da ist eigentlich alles auf "auto". Ging bisher davon aus, dass das Board so "schlau" ist und das ganze selber anpasst...

Nunja, ich eröffne mal nen neuen Thread im Speicher-Forum :)

MfG
 
Fertig, gebastelt.
Der Perc läuft jetzt mit 8 Platten, ohne Probleme.
Seit dem ich die DELL FW drauf gespielt habe, gibt es auch keinen "Reboot-Bug" mehr.
1,5TB RAID5 System + 320GB RAID10 VMWare Testbüchsen :bigok:

 
knick im schlauch.... :d

hateiner eigentlich nen waküler auf den5/i gepackt? hab vorhin mal mit BBu aber ohne platten roundabout 15W gemessen. fingerfühlen war schmerzhaft.


gibts da nun nen treiber für win2000?

danke


edit: waküler: http://www.abload.de/image.php?img=perc29gm.jpg
 
Zuletzt bearbeitet:
Ja den Knick habe ich auch grade gesehen, blöde sata kabel.... mal schauen was sich machen lässt. :)
 
so hab mal meine Ultradrive 64 SSD mit an den Perc gehängt. Aber die Ergebnisse entäuschen mich schon...
Keine Ahnung ob ich Einstellungen irgendwie total falsch getroffen habe, hab einfach die von Tekkno_Frank ausm Startpost genommen. Gibts irgendwelche Vorschläge für bessere Einstellungen wenn man ne SSD verwendet?

Zum Vergleich hab ich die SSD ans MB gehangen (SB750) mit aktiviertem AHCI.
Die Benches wurden mit Win7 druchgeführt, welches auf der SSD installiert ist.

Die ATTO-Schreibwerte sind ja ganz in Ordnung, aber auch nur weil man nicht mehr als 256MB Testgröße anwählen kann, der dann ziemlich komplett in den Cache wandert.
Die IOPS gehen am Perc aber total flöten, auch die Zugriffszeiten schießen nach oben.

Bei den Screens ist links immer der Perc und rechts die SB 750.
 

Anhänge

  • ATTO UD64 Vergleich.jpg
    ATTO UD64 Vergleich.jpg
    121,9 KB · Aufrufe: 105
  • UD 64 Crystal VERGLEICH Perc - SB750.jpg
    UD 64 Crystal VERGLEICH Perc - SB750.jpg
    68,4 KB · Aufrufe: 103
  • HDTune_Random_Access_DELL VERGLEICH PERC - SB750.jpg
    HDTune_Random_Access_DELL VERGLEICH PERC - SB750.jpg
    111,4 KB · Aufrufe: 107
Zuletzt bearbeitet:
hmm (adaptive) Read Ahead hab ich nun deaktiviert, Iops sind leicht verbessert, aber die Readwerte sind fast durchgängig schlechter als an der SB750. Das gibts doch nich, entweder lügen die benchmarks oder da läuft nen Rädle im Dreck...
 

Anhänge

  • SSD Test ohne Read ahead.jpg
    SSD Test ohne Read ahead.jpg
    188,5 KB · Aufrufe: 98
Bei meiner UD sehen die Einstellungen bis auf Disk Cache Policy = Unchanged identisch aus.

Werte im HD tune dafür aber "deutlich besser"
udwsf2.png
 
WaDenKraMpF schrieb:
hmm (adaptive) Read Ahead hab ich nun deaktiviert, Iops sind leicht verbessert, aber die Readwerte sind fast durchgängig schlechter als an der SB750. Das gibts doch nich, entweder lügen die benchmarks oder da läuft nen Rädle im Dreck...
Zum Vergrößern anklicken....

Hi Du,

Disk Cache mal ausmachen, doppelter Cache kann hier schädlich sein.

BZW was noch besser sein wird ist write back im PERC.

Hintergrund Write Back ist ohne den Perc cache.

Spiel mal mit den Werten rum.
 
zum einen AHCI zum anderen wirds an der SSD selber liegen. die reaieren nunmal neativ auf komplettes beschrieben. da hilft wenn dann nur trim. wobei: so wie ich das sehe bedeutet dass ne doppelte anzahl an writes im trim-modus. ob das so ut ist auf dauer für MLCs?
 
Die Zellen müssen eh gelöscht werden, bevor sie wieder beschrieben werden können.
TRIM macht diesen Löschzyklus einfach vorher manuell .. also "eigentlich" kein doppelter Löschzyklus.

Die Frage der Lebensdauer finde ich eh übertrieben .. die meisten werden sich in zwei-drei Jahren schon längst andere Laufwerke gekauft haben, und das machen die MLC selbst bei überdurchschnittlicher Belastung dicke mit.
Oder habt ihr alle kein Backup, dass ihr euch solche Sorgen machen müsst :d
 
so mal mit den Einstellungen rumgespielt und alles durchgebencht.
Sobalt der Cache vom Perc aktiviert ist bricht die SSD ein... mit Write Through kommen annähernd die Werte raus wie am SB750.
Bei aktiviertem Write Back und deaktiviertem Disk Cache sind die Werte auch im Keller. Ob das an den Benchmarks liegt oder ob das auch im praktischen Einsatz zutrifft wäre mal interresant zu wissen.
Dachte immer Cache bringt Performance o_0

Habe auch mal IDE anstatt AHCI getestet, wobei da so gut wie kein unterschied zu erkennen ist. Mal ist sie da nen zacken schneller, dort wieder langsamer. Liegt eher im Bereich der Messungenauigkeit.

1.Bild UD64 am Perc mit Write Through
2.Bild UD64 an SB750 @IDE
 

Anhänge

  • SSD @Perc write through.jpg
    SSD @Perc write through.jpg
    196,1 KB · Aufrufe: 106
  • SSD @SB750 @IDE.jpg
    SSD @SB750 @IDE.jpg
    179,2 KB · Aufrufe: 103
Problem ist halt, sobald der Perc im "Datenstrom" arbeiten soll (zwischenspeichern usw.), erhöht sich die latenz, dies zwar nur um "winzige" ms, die aber bei den zugriffszeiten einer SSD sofort ins gewicht fallen.
 
@WaDenKraMpF

ich hatte darauf auch schon mal aufmerksam gemacht vor 3-4Wochen.
Meine Tests ergaben das read-ahead die platte ausbremst.
Schau mal einige Posts von mir vorher an mit den Screenshots...
Probiere mal die Readahead und Readback-Einstellungen durch, du wirst sehen
das macht große Unterschiede aus.
Die Ipos fallen ab, das ist mir auch aufgefallen...von ca. 11000 -> 8000-9000.
Aber mit den richtigen Einstellungen ist die UD am Perc schon schnell genug, gerade wenn Sie aus dem Cache lesen muss.
 
Hallo,

mal ne allgemeine Frage.
ich habe windows Vista 64bit im Einsatz auf einem Perc 5 mit 8x 750 gb hdd (samsung F1) im raid 5
Das Tool hdtune misst immer mur 7mb/s also irgendwie kommt es mit dem OS oder der Kapazität nicht klar.
Bei 5x750 Gb im Raid 5 hatte ich ca 240mb/s laut hdtune.

Naja ich habe nun iozone getestet.
Hier sehen die Werte eher ernüchternd aus. Kann einer von euch vergleichstests machen?

hier die Settings:
http://www.iozone.org/

C:\Program Files (x86)\benchmarks\Iozone 3.321>iozone -R -l 5 -u 5 -r 128k -s 7G
-F d:\iozone\1 d:\iozone\2 d:\iozone\3 d:\iozone\4 d:\iozone\5

Results:
C:\Program Files (x86)\benchmarks\Iozone 3.321>iozone -R -l 5 -u 5 -r 128k -s 7G
-F d:\iozone\1 d:\iozone\2 d:\iozone\3 d:\iozone\4 d:\iozone\5
Iozone: Performance Test of File I/O
Version $Revision: 3.321 $
Compiled for 32 bit mode.
Build: Windows

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
Al Slater, Scott Rhine, Mike Wisner, Ken Goss
Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy,
Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root.

Run began: Mon Apr 27 20:14:07 2009

Excel chart generation enabled
Record Size 128 KB
File size set to 7340032 KB
Command line used: iozone -R -l 5 -u 5 -r 128k -s 7G -F d:\iozone\1 d:\i
ozone\2 d:\iozone\3 d:\iozone\4 d:\iozone\5
Output is in Kbytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 5
Max process = 5
Throughput test with 5 processes
Each process writes a 7340032 Kbyte file in 128 Kbyte records

Children see throughput for 5 initial writers = 117636.70 KB/sec
Parent sees throughput for 5 initial writers = 103480.44 KB/sec
Min throughput per process = 21157.38 KB/sec
Max throughput per process = 26738.43 KB/sec
Avg throughput per process = 23527.34 KB/sec
Min xfer = 5808000.00 KB

Children see throughput for 5 rewriters = 102303.36 KB/sec
Parent sees throughput for 5 rewriters = 100476.99 KB/sec
Min throughput per process = 16579.29 KB/sec
Max throughput per process = 26121.71 KB/sec
Avg throughput per process = 20460.67 KB/sec
Min xfer = 4658688.00 KB

Children see throughput for 5 readers = 65931.36 KB/sec
Parent sees throughput for 5 readers = 65928.81 KB/sec
Min throughput per process = 11750.87 KB/sec
Max throughput per process = 15146.80 KB/sec
Avg throughput per process = 13186.27 KB/sec
Min xfer = 5694464.00 KB

Children see throughput for 5 re-readers = 57294.24 KB/sec
Parent sees throughput for 5 re-readers = 57289.75 KB/sec
Min throughput per process = 11171.26 KB/sec
Max throughput per process = 12235.75 KB/sec
Avg throughput per process = 11458.85 KB/sec
Min xfer = 6701568.00 KB

Children see throughput for 5 reverse readers = 26390.71 KB/sec
Parent sees throughput for 5 reverse readers = 26260.47 KB/sec
Min throughput per process = 3484.68 KB/sec
Max throughput per process = 5795.06 KB/sec
Avg throughput per process = 5278.14 KB/sec
Min xfer = 4414080.00 KB

Children see throughput for 5 stride readers = 14579.85 KB/sec
Parent sees throughput for 5 stride readers = 14536.57 KB/sec
Min throughput per process = 2104.85 KB/sec
Max throughput per process = 3242.98 KB/sec
Avg throughput per process = 2915.97 KB/sec
Min xfer = 4764672.00 KB


Grüße,
 
Wie sehen deine Settings aus? (Im LSI Storage Manager)
BBU vorhanden?

Grüße
 
toppas:-) schrieb:
@WaDenKraMpF

ich hatte darauf auch schon mal aufmerksam gemacht vor 3-4Wochen.
Meine Tests ergaben das read-ahead die platte ausbremst.
Schau mal einige Posts von mir vorher an mit den Screenshots...
Probiere mal die Readahead und Readback-Einstellungen durch, du wirst sehen
das macht große Unterschiede aus.
Die Ipos fallen ab, das ist mir auch aufgefallen...von ca. 11000 -> 8000-9000.
Aber mit den richtigen Einstellungen ist die UD am Perc schon schnell genug, gerade wenn Sie aus dem Cache lesen muss.
Zum Vergrößern anklicken....

mit Adaptive Read Ahead bin ich bei 1500 IOPS, No Read Ahead + Write Back sind schon 3000 und wenn ich Write Through mache sinds 6500. Direkt am Onboard Controller im IDE Modus sind bis zu 9500 IOPS (jeweils der erste wert =512 bei HD Tune Pro, Rnd Access Test).
Dachte Write Back bringt immer mehr Leistung, und je nach Platten bis zu 50% mehr... Ist aber Anscheinend mit der SSD nicht der Fall. (zumindest bei mir)
Aber da es so relativ gut läuft, nutz ich halt Write Through ;)

toppas, mit welchen Settings fährst du zur zeit? immernoch mit denen, die bei den benchmarks dabei stehen? Weil sobalt ich Write Back einschalte bricht die Leistung ein...

thx an alle die hier immer die tips raushauen, ohne tappt man häufig im dunkeln...
 
Zuletzt bearbeitet:
Leider habe ich keine BBU...mhh...also mache ich das im MegaCLI-Manager.

folgendes habe ich nun:

Write Back (Force wegen fehlender BBU is on)
DirectIO
No Cache Police
No Read Ahead

Dann sind ich iopts so bei ca. 6500...grr...aber der Read bei >150 MB/s.
Kann gerne nochmal einige Tests machen demnächst. Eins ist mir mittlerweile
auch klar, das der Perc nicht mit dem Intel bei der single SSD gerade mitkommt. Aber wenn man aus dem Cache liest dann geht er gut ab.
 
kannst du vielleicht auch mal Write Through probieren? Ob das bei dir noch bessere Werte liefert?
Ich teste heute abend mal mit dem alten Speicherriegel, eftl liegst am RAM. Wenns das nicht is bau ich mal den andern Perc ein den ich hier noch rumliegen habe... ich versteh nich warum er mit Write Back so abkackt...
kann es sein dass der Ram ansich irgendwelche Fehler hat, die dann erst durchs ECC immer wieder korrigiert werden müssen?
 
Das muss nicht sein , das unbedingt der Ram schuld ist. Mit den Cache-Einstellungen habe ich da teils nur 70mb/s bekommen oder/und die Iops brachen ein. Ich würde persönlich vermuten das der Controller für eine single SSD nicht so absolut geeignet ist, mehr für Raid5 und Festplatten. Ich dachte auch das die SSD unter dem Perc besser läuft,dafür hatte ich ihn mir auch zugelegt.
Die SSD liefert schneller Daten als der Perc verarbeiten kann, das würde mir die Iops erklären. Warum das allerdings mit den Leseraten von 70mb/s passiert ist mir auch noch Suspect...beim Read-Ahead ect hats was mit der Cache-Verwaltung zu tun (das braucht ein wenig zeit), aber warum er limitiert...K.A.
 
WaDenKraMpF schrieb:
Habe auch mal IDE anstatt AHCI getestet, wobei da so gut wie kein unterschied zu erkennen ist. Mal ist sie da nen zacken schneller, dort wieder langsamer. Liegt eher im Bereich der Messungenauigkeit.
Zum Vergrößern anklicken....

Ich lese immer etwas von AHCI und Perc5/i. Aber der Perc5 kann lt. Vergleich auf der ersten Seite kein AHCI, nur der Perc6. Viellicht ist er daher schneller?
Aber warum auch die SSD am Perc betreiben? Soll die SSD ins Raid eingebunden werden? Wenn nicht, dann muss sie ja nicht unbedingt dort angeschlossen werden. Der Perc hat ja auch unnötige Latenzen, nciht nur wegen dem Speicher. Von der NB aus geht das als PCIe zu zu dem Intel Chip auf dem Perc, der wandelt das dann in PCI-X um, geht dann zu dem LSI Chip wo das in S-ATA ohne AHCI umgewandelt wird und dann erst zur Platte.
 
AHCI -> IDE war bei mir der Onboardcontroller (SB750), wird eftl nur ersichtlich wenn man meine vorherigen Posts auch mitliest.
Grundgedanke war eben die SSD auch an den Perc zu hängen um den zusätzlichen Cache des Controllers mitnutzen zu können, da die MLC ja eine leichte Schreibschwäche haben. Ich dachte das würden die 512MB Cache gut abpuffern...
Es wundert mich nur dass bei anderen (z.b. bei Blackghost & toppas) die UD auch mit aktiviertem Perc-Cache (Write Back) sehr gut läuft, und bei die IOPS/Transferraten zumindest in den Benchmarks sehr einbrechen.
Kleine positive aspekte wenn die SSD am Perc hängt,ich spar mir noch nen Sata Kabel (das vom Perc läuft direkt vorbei) und kann den Onboard-SATA zeugs alles abschalten, was sich in ein paar sec schnellerer bootzeit zeigt...
 
Eventuell hängt das mit den verschiedenen Perc Revisionen zusammen.
Manche hatten ja eine etwas flottere CPU auf der Karte.

Ich werd gleich mal unter den Tisch krabeln und nachsehen ...
 
@WaDenKraMpF: Hatte schon gelesen dass es bei letzten Posting um die SB750 ging. Aber 1 Seite vorher wurde da auch was von AHCI und Perc geschrieben.

@BlackGhost: Dachte die hätten alle einen IOP333 mit der Nenn-Taktfrequenz drauf.
 
Status
Für weitere Antworten geschlossen.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh