RAID 5 + Windows Server 2008 = komisches Verhalten

Wahrscheinlich wird (nicht nur wahrscheinlich) wird USB und die Sata Anschlüsse beides vom Southbrige gespiessen, daher entsteht wohl ein Engpass.

Sata-Controller würde da Abhilfe schaffen.

€: (meine Vermutung...)

Ziemlich eindeutig ist die Southbridge das Problem, da diese sowohl den Raidcontr. wie auch den Lan und USB Controller bei Intel enthält wird wohl wirklich ein Engpass bestehen.
Ganz davon ab dass Software-Raid-Lösungen bei Raid 5 sehr viel CPU Power benötigen und sehr wenig Performance liefern.

Lösung:
http://www.3ware.com/products/serial_ata2-9650.asp

http://www.toppreise.ch/prod_127503.html

LG

Schalt mal den Cache auf dem Onboard Controller aus.

schau dir mal die Disk-Queue length bzw. Auslastung mit perfmon an...

Falls sie hoch ist, dann ist die "Disk" zu langsam.. respektive das Raid5. Woran das liegt, das ist dann wieder ne andere Geschichte

Also schon vor x- Jahren mit ner Nforce 350 (oder wie hiess das ding nochmals genau?) hab ich mit nem 4 Platten Raid 0 übers Netzwerk schon locker 85 Mega Bytes pro Sekunde auf die Platten schreiben können. An eine Begrenzung durch SOuthbridge glaube ich daher eher nicht, ausser die Southbridge würde tatsächlich die Raid 5 Parity berechnung machen - was typischerweise bei solchen Lösungen aber die CPU macht.

Ein 2GHZ Core 2 sollte problemlos in der Lage sein 100MB/s Raid 5 zum Schreiben aufzubereiten.

Nunja Raid 0 und Raid 5 sind nicht dasselbe.
Raid 5 ist aufgrund der Paritätsdaten sehr viel aufwändiger zu berechnen und bringt bei einem Software Raid oder eben so ein Pseudo Hardware Raid eine CPU die nicht darauf spezialisiert ist ganz schön ins Schwitzen.
Dashalb haben richtige Raidkarten ja auch einen dafür vorgesehenen XOR "Prozessor".

Ausserdem benötigte ein Nforce 3 einen externen an die SB angebudenen PHY um Netzwerk über die SB zur Verfühgung zu stellen. Hatte also eigentlich einen Zusatzchip welcher nur über die schnelle Verbindung zwischen NB und SB angebunden war, um den PCI Bus nicht zu belasten.

http://www.asus.com/product.as…JlT1ztLMobrSz6&templete=2

Das ist mit dem in der SB integrierten Netzwerkchip von Intel nicht zu vergleichen.

LG

Zitat

Original von kingalive
Nunja Raid 0 und Raid 5 sind nicht dasselbe.
Raid 5 ist aufgrund der Paritätsdaten sehr viel aufwändiger zu berechnen und bringt bei einem Software Raid oder eben so ein Pseudo Hardware Raid eine CPU die nicht darauf spezialisiert ist ganz schön ins Schwitzen.
Dashalb haben richtige Raidkarten ja auch einen dafür vorgesehenen XOR "Prozessor".

Und? Ein 2GHZ Prozessor einer aktuellen Generation schafft 100MB/s Raid 5 XOR locker.

Zitat

Ausserdem benötigte ein Nforce 3 einen externen an die SB angebudenen PHY um Netzwerk über die SB zur Verfühgung zu stellen. Hatte also eigentlich einen Zusatzchip welcher nur über die schnelle Verbindung zwischen NB und SB angebunden war, um den PCI Bus nicht zu belasten.

Richtig - genau desswegen wollte ich das Ding damals ja.. wer will schon Disk Controller und Ethernet über PCI angebunden.. das war damals noch ein riesiger Flaschenhals.

Aber was willst du damit sagen?

Bei nem ICH9,10 wird Ethernet und Disk Controller wohl kaum über PCI angebunden sein.

ICH9:
http://pics.computerbase.de/1/8/0/3/0/8_m.jpg

ICH10:
http://www.pcstats.com/article…08/chipset_IntelP45_3.jpg

Der Link zwischen Northbridge und Southbridge läut mit 2GB/s.

Also natürlich hat diese Architektur einen Nachteil gegenüber dem Jahre alten NF3, aber ich glaube kaum, dass der LInk nicht dazu reicht mit 100MB/s von USB -> Disk oder Netzwerk -> Disk zu kopieren.

EDIT:

Benchmarks ICH10 Raid5:
http://www.hardforum.com/showthread.php?t=1363331
>200MB/s

Das liegt niemals an der Busbandbreite, dass der Durchsatz unter 5 mBit fällt.

Zitat

Original von BLJ

Und? Ein 2GHZ Prozessor einer aktuellen Generation schafft 100MB/s Raid 5 XOR locker.

Kommt auf die Southbridge an.
Die ICH 10R kann da einiges. Bei den aktuellen Lösungen von AMD oder Nvidia ist da bei spätestens 50MB/sek schluss.

http://www.tomshardware.com/de…stberichte-240374-13.html

Zitat

Richtig - genau desswegen wollte ich das Ding damals ja.. wer will schon Disk Controller und Ethernet über PCI angebunden.. das war damals noch ein riesiger Flaschenhals.

Aber was willst du damit sagen?

Bei nem ICH9,10 wird Ethernet und Disk Controller wohl kaum über PCI angebunden sein.

ICH9:
http://pics.computerbase.de/1/8/0/3/0/8_m.jpg

ICH10:
http://www.pcstats.com/article…08/chipset_IntelP45_3.jpg

Der Link zwischen Northbridge und Southbridge läut mit 2GB/s.

Also natürlich hat diese Architektur einen Nachteil gegenüber dem Jahre alten NF3, aber ich glaube kaum, dass der LInk nicht dazu reicht mit 100MB/s von USB -> Disk oder Netzwerk -> Disk zu kopieren.

Alles anzeigen

Eben der PHY war an der Southbridge des NF3 angeschlossen.
Also ein Extrachip, welcher die Netzwerklast übernahm.
Das hat nur den Vorteil, dass man den PCI Bus nicht belastet.

Bei der Intel ICH9 und 10 ist im Prinzip die Southbridge der Netzwerkcontroler und trägt damit die Netzwerklast, wie auch für USB Zugriffe und dazu kommt die Controlerfunktion des Raids.

Beim Daten Kopieren von oder auf dieses Raid 5 muss die ICH nun 2 Aufgaben gleichzeitig erfüllen, aufwendige Raid 5 Funktion + USB Controler oder aufwendige Raid 5 Funktion + Netzwercontroler.
Auxh wenn der Hauptprozessor dann die Rechnerei übernimmt, ist die SB doppelt belastet.
Somit zielt meine Vermutung also auf eine Überlastung dieser SB.

Auf einer Extrakarte wo ein Raid drauf läuft, wie in diesen verlinkten Benchmarks mit Raid 5, wird das Problem somit kaum auftreten.

LG

Ich muss dazu sagen dass ich das selbe Problem auch mit meinem alten Giga Board hatte mit P965. Was für ein ICH es war weiss ich nicht, aber schon damals hatte ich die Vermutung dass die SB der Flaschenhals war.

Eine kleine Raidkarte hatte das Problem gelöst.
Aber wenn es in deinem Fall eine schnellere Serverlösung des Raids sein soll, würde ich gleich eine kaufen mit einer XOR-Einheit.

Greez rovi

Die 35 MByte/sec.am Anfang beim Kopiervorgang sind wohl die Werte die Windows angibt,oder? Das stimmt meist nicht.
Wenn ich von USB kopiere sagt mir Win 7, dass ich mit 60 - 70 MByte/sec. kopiere und erst nach einigen Minuten fällt der Wert auf ca. 29 Mbyte/sec. und bleibt dann konstant.
Haste beim Kopieren per netzwerk auch nur die Windowskopieranzeige angeschaut oder den effektiven Speed (Taskmanager) evtl. sogar auf dem anderen Computer, von welchem du kopierst?

Ansonsten muss ich sagen, dass ich sowas noch nie hatte, mein Server hatte früher auch schon ein Gigabyte Board und da konnte ich normal kopieren.

Beim neuen Board im Server kann ich 2 USB Platten anhängen und von beiden konstant mit Full Speed (30 MByte/sec.) kopieren und dazu noch intern auf den Platten rumschreiben.
Habe aber auch kein Raid sondern 12 Platten einzeln drin.
Netzwerk von Server zu HTPC ging mit konstant 95 MByte/sec.

5 Mbyte/sec. und eine Auslastung von 2 Cores ist heutzutage eigentlich undenkbar. Wer solche Mainboards herstellt würde nicht Lange überleben. Da muss irgendwas sonst komisch sein.

ich würde mal nur 1 Platte einbauen, im BIOS schauen dass sie auf AHCI (SATA) eingestellt ist, neu aufsetzen und dann die neusten Treiber vom Internet runterladen und dasselbe (USB, Netzwerk kopieren) nochmal versuchen. Ist etwas Aufwand halt.

Zitat

ich würde mal nur 1 Platte einbauen, im BIOS schauen dass sie auf AHCI (SATA) eingestellt ist, neu aufsetzen und dann die neusten Treiber vom Internet runterladen und dasselbe (USB, Netzwerk kopieren) nochmal versuchen. Ist etwas Aufwand halt.

Was ich nicht so recht verstehe ist: Unser Server hat ebenfalls ein Software-Raid5 mit 3x 500GB Platten. Der Netzwerkkopierspeed (auch direkt auf eine USB-Platte (@Workstation) geht absolut schnell. Also ist von mir aus gesehen nicht der Raidverbund der Knackpunkt sondern das MB oder OS. Wobei im Server auch ein Gigabyte Board drin ist, ungefähr mit denselben Werten wie das im Server von Kosh.

Zitat

Original von kingalive
Auf einer Extrakarte wo ein Raid drauf läuft, wie in diesen verlinkten Benchmarks mit Raid 5, wird das Problem somit kaum auftreten.

Ups, du hast recht, im verlinkten Benchmark war es tatsächlich ein Highpoint controller

Hier ICH10R, die R5 Performance ist tatsächlich sehr schlecht:
http://www.extremetech.com/article2/0,2845,2334986,00.asp

Allerdings hier:
http://www.overclockers.com/forums/showthread.php?p=5789768

erreicht er knapp 100MB/s Write und ein paar 100MB/s Read. Prinzipiell schafft der ICH10R damit also 100MB/s write?!

EDIT:
In dem von dir verlinkten Bench:
http://www.tomshardware.com/de…stberichte-240374-13.html

Schafft die ICH10R ja sogar >300MB/s Write im Raid5..

Dazu möchte ich bemerken, dass nicht die CPU das Limit ist. Die kommt auch hier nie auch nur in die Nähe einer totalen Auslastung eines einzelnen Cores. Das XORing für die CPU "zu viel" ist, dass ist ein Ammenmärchen.

Die Wahrheit muss irgendwo bei der Southbridge-Bandbreite, Latenzen und schlechter Integration / Treibern liegen.

Bei UBS -> Disk (ohne RAID) kann ggf. DMA mässig direkt vom USB Channel auf den Controller geschrieben werden resp. umgekehrt. Vermutlich aber wandern die Daten von USB -> RAM -> Controller (müssen mit DMA aber nie auf die CPU!).
Bei Raid 5 müssen die Daten von USB/Network [Southbridge] -> RAM [Northbridge] -> CPU (XOR) -> RAM -> Controller.

RAM & CPU haben mehr als genug Bandbreite und / respektive Processing Power.

Zitat

Eben der PHY war an der Southbridge des NF3 angeschlossen.
Also ein Extrachip, welcher die Netzwerklast übernahm.
Das hat nur den Vorteil, dass man den PCI Bus nicht belastet.

Bei der Intel ICH9 und 10 ist im Prinzip die Southbridge der Netzwerkcontroler und trägt damit die Netzwerklast, wie auch für USB Zugriffe und dazu kommt die Controlerfunktion des Raids.

Dass der NF3 einen externen PHY hat und neue ICH nicht (drüber bin ich mir aber nicht sicher.. deine Behauptung), spielt keine Rolle: Der PHYsical wandelt lediglich die digitalen Signale in Analoge Ethernet Signale um. Wie z.B. ein RS232 PHY für den SPI eines MC.

In beiden Fällen ist ICH resp. NF3 der Netzwerk-Controller und trägt die Netzwerklast. Die läuft in beiden Fällen über die Southbridge...

Zitat

Beim Daten Kopieren von oder auf dieses Raid 5 muss die ICH nun 2 Aufgaben gleichzeitig erfüllen, aufwendige Raid 5 Funktion + USB Controler oder aufwendige Raid 5 Funktion + Netzwercontroler.
Auxh wenn der Hauptprozessor dann die Rechnerei übernimmt, ist die SB doppelt belastet.

Wieso doppelt belastet? Sie muss ja so oder so von 2 Dingen gleichzeitig (Ethernet, USB, Disk Controller) schreiben/lesen. Ist daher in allen Szenarien "doppelt belastet".
Falls sie das XOR übernehmen würde, dann wäre klar, dass sie zu langsam ist.

Ich würde auch sicherstellen, dass die neusten Treiber installiert sind und keine IRQ Konflikte vorliegen... und die IRQs nicht im virtuellen Bereich liegen?

Die Frage ist ob Kosh auch eine ICH10R einsetzt?
Wenn ich mich richtig erinnere, stinken die Vorgäner bei Raid 5 gröber ab....

Falls das weiterhilft:

ich habe folgende installation:
Gigabyte Mainboard (P35-DS4) mit ICH9.
Core2Quad Q6600 CPU
2GB Ram
Onboard Intel LAN

An den Sata-Ports vom ICH9 sind 4 Festplatten angeschlossen, jedoch 'einzeln' (=aus Sicht des ICH9 kein Raid).

Danach unter Linux ein reines Software-RAID-5.

Performance-Werte:
Kopie via NFS von PC zu PC über Gbit-LAN: rund 110 Mbyte/s (vom Raid lesend).
Kopie via FTP von PC zu PC über Gbit-LAN: rund 80 Mbyte/s, lesend und schreibend.

--> Bandbreite vom ICH9 dürfte also nicht das Problem von Kosh sein, da der ICH9 sich auch nicht um die XOR-Berechnungen vom Raid 5 kümmert / kümmern muss. Der ICH9 macht ein FakeRaid (Infos zu FakeRaid).

Btw: CPU-Last des Servers beim schreiben via LAN aufs RAID: ca. 15%
Also sollte die CPU-Last auch nicht das Problem sein.

Was ich mich im Momment grad frage:
Beim FakeRaid werden die XOR Berechnungen im Treiber des Controllers durchgeführt. Wenn nun dieser Treiber übermässig viel CPU-Zeit in Ansprich nimmt, ist das im Taskmanager sichtbar?
Habe leider noch keine Erfahrung mit Windows 2008.

Kosh:
Wenn ich z.B. mal einen Performance-Test über CIFS machen soll, (z.B. kopie von Windows auf Linux via CFIS), oder wenn ein anderer Test dich evtl. weiter bringt, einfach melden.

Zitat

Original von aschi
Was ich mich im Momment grad frage:
Beim FakeRaid werden die XOR Berechnungen im Treiber des Controllers durchgeführt. Wenn nun dieser Treiber übermässig viel CPU-Zeit in Ansprich nimmt, ist das im Taskmanager sichtbar?
Habe leider noch keine Erfahrung mit Windows 2008.

Ja das sieht man im Taskmanager. Allerdings ist es gut möglich, dass ein Windows / LInux / OS X Software Raid 5 schneller ist als ein ICH9 Fakeraid. Vielleicht ist der Treiber einfach so schlecht, dass er die Berechnung nicht optimal durchführt, respektive ohne Buffering etc. Also wenn der "Paket für Paket" liest, XOR'd, schreibt und dann erst das nächste holt etc., kann ich mir gut vorstellen, dass es so lange geht (zusätzliche Latenzen).

Ich hoffe schwer (und nehme es an), dass es ein FakeRaid ist und nicht der ICH_R die XOR Berechnung durchführt.

(ein XOR 32 Bit wird wohl etwa 1 Zyklus brauchen, vielleicht auch 2-3, je nach Architektur. Das wären dann bei 2GHZ max
2*1000*1000*1000 XOR 4Byte pro Sekunde => 8000000000 Bytes / Sekunde
=7629.39453125 GB/s

oder bei 4 Clock-Cycles pro 32Bit XOR (laden der Daten, XOR, speichern) wärens nicht ganz 2GB/s.

allerdings hat die CPU ja sicher genügend 32Bit Register um auch parallel (pipelining!) jeweils laden->XOR->speichern zu machen, also)
- laden->XOR->speichern
---------- laden -> XOR -----> speichern
---------------------- laden ----> XOR -----> speichern

man sieht also, dass die Berechnungsleistung der CPU garantiert nicht der Falschenhals im Raid 5 darstellt. Was mich etwas stresst denn das wird _ständig_ und unablässig als Argument angeführt obwohl es einfach nur kreuzfalsch ist.
Wenn es ein Problem mit dem Berechnen auf der CPU gibt dann sind es wohl eher die Latenzen oder die Bandbreite der Verbindungspfade.

Zitat

Original von BLJ
Was mich etwas stresst denn das wird _ständig_ und unablässig als Argument angeführt obwohl es einfach nur kreuzfalsch ist.

Ja, diese Ewigen Diskusionen kene ich auch
Ich sehe den Vorteil eines Hardware-Raid Controllers im Server-Bereich, wo man die CPU-Ressourcen lieber für etwas anderes nutzen möchte, und die CPU-Last für Raid evtl. noch etwas höher wird, da dort ja meist 15Krpm platten eingebaut werden.
Zudem sind die Teuren Hardware-raid karten einfacher zu monitoren.
...Und haben, wenn sie von LSI sind, ein Besch*****es Web-Bios, das man nur mit Maus bedienen kann, und voll Fehler ist. (Dafür ist der Klicki-Bunti-DAU glücklich damit, wobei ich der Meinung bin, ein Dau soll sich auch kein Server kauffen - aber das ist ein anderes Thema )

Zitat

Original von BLJ
Wenn es ein Problem mit dem Berechnen auf der CPU gibt dann sind es wohl eher die Latenzen oder die Bandbreite der Verbindungspfade.

Oder, wie schon so oft, die schlecht programmierten Treiber