Frage zu Asus K8V & S-ATA

[QuickBiker]

Hallo Leutz,

zur Zeit habe ich ein A7N8X mit 2 Maxtor 120GB im Raid 0 am laufen. Bei diesem Board ist ja der S-ATA Controller über der PCI-Bus angebunden. Ein bisserl wie Porsche mit Reifen vom Lupo. Aber besser als normale P-ATA Laufwerke. Nun zur Frage. Beim K8V ist ja der S-ATA Controller in der Southbridge integriert. Hängt also nicht mehr am PCI-Flaschenhals. Wer hat hier bereits Erfahrungen gesammelt? Kommt man beim K8V zumindest in den Bereich der theoretischen 150 MB/s Datendurchsatz?

Vielen Dank. :)

[rubinho]

Ich kann Dir leider keine angaben über die Perfomance des Via Raid-Controller geben aber ich habe mit jenem schlechte erfahrungen gemacht.

Nachdem ich nämlich im Bios was änderte (Von Auto-Mode in Turbo-Mode) schoss ich mir meine Raid-Array und meine Daten waren Futsch.

Dieser Fehler ließ sich beliebig reproduzieren und nur mit den Turbo Standart Auto Modis.

Deshalb bin ich auf den Promise umgestiegen, der ist zwar vermutlich langsamer aber er zerschießt mir meine Daten nicht.

Gruß Rubinho

[Schutzfaktor12]

@rubinho:
Mit welcher Biosversion ist dir das denn passiert? Ich wollte nämlich heute eigentlich auch mal anfangen, meine Benchmarks per Bios zu optimieren ;D

[Accuphase]

Original geschrieben von QuickBiker
Kommt man beim K8V zumindest in den Bereich der theoretischen 150 MB/s Datendurchsatz?


Ja 8) (gebencht mit ATTO Benchmark):

http://www.forum-3dcenter.org/vbulletin/attachment.php?postid=1567253
http://www.forum-3dcenter.org/vbulletin/attachment.php?postid=1567254
http://www.forum-3dcenter.org/vbulletin/attachment.php?postid=1567259


Original geschrieben von rubinho
Nachdem ich nämlich im Bios was änderte (Von Auto-Mode in Turbo-Mode) schoss ich mir meine Raid-Array und meine Daten waren Futsch.

Das ist mir auch passiert, als ich probiert habe FSB von 233 MHz zu fahren ;D , Raid Array war aber nicht wirklich zerschoßen, nach dem ich FSB zurückgesetzt und ein paar mal rebottet habe, war alles wieder ok

[cumulus]

Dazu braucht es keinen RAID: meine single-SATAT Platte hats auch zerschossen bei 235FSB :-)

Na ja... musste eh noch mal sauber installiert werden.... :D

[Woerns]

@Accuphase
Interessant sind deine Benchmarks. Wie muss man die interpretieren?
Du hast Datenpakete mit 4MB, 8MB und 32MB verwendet, wenn ich das richtig sehe.
Die zwei S-ATA Platten im Raid0 haben 2 x 8MB = 16MB Cache, nehme ich an, so dass die beiden ersten Pakete komplett in den Cache passen und der Raidcontroller in der Via SB das begrenzende Elemt ist. Der unterstützt also eine maximale Lese-Bandbreite von 187 MB/s. Beim dritten Benchmark mit 32MB reicht der Cache nicht und die Daten müssen auf die Platte und von dort wieder gelesen werden. Da sieht man die maximale "Hardware-Bandbreite" mit ca. 115MB/s.

Stimmt meine Interpretation in etwa so?

Ich will diese Woche auch ein Raid0 am K8V mit zwei Barracuda S-ATA Platten aufsetzen und habe mir obige Frage auch schon gestellt. Also möglichst nicht im BIOS rumpfuschen...
MfG

[CTN]

Hmmm, wenn ich mir die Ergebnisse von ATTO so ansehe, gibt es da ja ziemliche Unterschiede.
Mich würde mal interessieren, wie die zustande kommen.

A7V600 - AthlonXP 2500@3200 - 2x 512MB orig. Samsung

siehe http://www.ctn-systeme.de/test/iviewcapture1.gif
siehe http://www.ctn-systeme.de/test/iviewcapture2.gif
siehe http://www.ctn-systeme.de/test/iviewcapture3.gif

[Woerns]

Der Unterschied liegt in der Stripesize von 16kB bei Accuphase und 64kB bei CTN, von den verschiedenen Platten mal abgesehen, aber die können nicht für diese Größenordnung verantwortlich sein.

Hat jemand eine Erklärung?
MfG

[Accuphase]

Original geschrieben von Woerns
@Accuphase
Interessant sind deine Benchmarks. Wie muss man die interpretieren?
Du hast Datenpakete mit 4MB, 8MB und 32MB verwendet, wenn ich das richtig sehe.
Die zwei S-ATA Platten im Raid0 haben 2 x 8MB = 16MB Cache, nehme ich an, so dass die beiden ersten Pakete komplett in den Cache passen und der Raidcontroller in der Via SB das begrenzende Elemt ist. Der unterstützt also eine maximale Lese-Bandbreite von 187 MB/s. Beim dritten Benchmark mit 32MB reicht der Cache nicht und die Daten müssen auf die Platte und von dort wieder gelesen werden. Da sieht man die maximale "Hardware-Bandbreite" mit ca. 115MB/s.

Stimmt meine Interpretation in etwa so?

Hm, klingt plausibel, aber da bin ich leider übergefragt, ich kann dir nicht sagen ob das stimmt

Ich glaube aber das die Festplatten das begrenzende Element sind, und nicht der Raidcontroller in der VIA Southbridge, ich denke der kann noch etwas mehr schaffen, allerdings vielleicht nur mit 2 Raptoren von Western Digital (ich war sogar selber überrascht über den transferwert beim lesen, 187 MB/s sind super (meiner Meinung nach).

Original geschrieben von Woerns
Ich will diese Woche auch ein Raid0 am K8V mit zwei Barracuda S-ATA Platten aufsetzen und habe mir obige Frage auch schon gestellt. Also möglichst nicht im BIOS rumpfuschen...


Hast du schon die Baracudas gekauft? Ich habe oft gelesen das die Baracudas (angeblich) relativ schlechte Werte im Raid Verbund leisten, ich weiss es nicht ob das stimmt...
*noahnung*

Siehe z.B. http://web.zdnet.de/techexpert/artikel/tuning/200207/raid_02-wc.html
http://www.google.de/search?q=seagate+barracuda+im+raid+0+verbund&hl=de&lr=&ie=UTF-8&oe=UTF-8&start=10&sa=N

Original geschrieben von Woerns
Hat jemand eine Erklärung?


Mögliche Erklärung: wenn der Raid Controller beim ASUS A7V600 am PCI Bus hängt, muß der die Bandbreite von ingesamt 133 MB/s mit anderen Geräten teilen, deswegen hat der CTN
weniger Performance, beim ASUS KV8 hat der Controller doppelt so viel Bandbreite zur Verfügung (bzw. andere Festplatten, Stripesizegröße usw.)

[Kingalive]

der raidcontr beim asus a7v600 hängt genausowenig am pci bus wie beim asus k8v. es ist jeweils ein in der VT8237 (southbridge, haben beide die gleiche) integrierter raidcontroller.

du kannst noch versuchen die stripesize zu ändern aber, ich denke das alte fazit gilt immer noch:

seagate barracudas sind unbrauchbar fürs raid und die besten dafür sind nach wie vor ibm/hitachis

gruss king

[CTN]

Also, wenn ich die Daten zwischen mir und Accuphase vergleiche, komme ich zu dem Ergebnis, dass die Seagate Barracuda-Platten wohl nicht so schlecht sein können.
Einzig die Screibwerte sind etwas schlechter - Aber die Lesewerte hauen ja wohl voll rein -.

[Woerns]

@Accuphase
Der Artikel in deinem Link zum Thema schlechte Raid0 Performance der Barracuda ist schon eineinhalb Jahre alt (Juli 2002) und bezieht sich auf die Barracuda IV mit IDE Raid Controllern als PCI Karte. Ich glaube kaum, dass die Barracuda V als S-ATA Version noch dieselben Kinderkrankheiten hat. Vielleicht andere...
Die Platten sind übrigens schon gekauft, mein Hardwarehändler stellt mir das System auf meine Wunschliste hin zusammen.

@CTN
Ich brauche noch etwas Nachhilfe bezüglich deiner Benchmmarks. Wie kommen Lese-Bandbreiten von mehr als 2 x 150 = 300 MB/s zustande? Verwechsele ich hier Bits und Bytes?
MfG

[Kingalive]

lesewerte von bis zu 700mb sind aber nicht wirklich realistisch.

nehmt doch mal den guten alten hd-tach

gruss king

[CTN]

Natürlich halte ich diese Werte nicht wirklich für Realistisch.
Ich wollte ja nur wissen, wie diese großen Unterschiede zustandekommen.
Beide Boards sind ja recht aktuell, -und verwenden die gleiche Southbridge.
Und unter HD-Tach sehen die Werte in der Tat etwas anders aus.

http://www.ctn-systeme.de/test/iviewcapture4.gif

[Woerns]

Sieht so aus, als ob HD-Tach nur echtes schreiben und lesen bencht. Mit welcher Bandbreite Daten aus dem 8MB Plattencache geholt werden können, ist offensichtlich nicht Gegenstand dieses Benchmarks.

Gerade das würde mich aber interessieren, denn im Raid0 haben zwei Platten zusammen immerhin 16MB Cache, der schon einiges aufnehmen kann. Wie gut dieser Cache performt, hängt dann davon ab, welches Glied in der Kette
- CPU
- Hypertransportlink
- Southbridge mit S-ATA Raid Controller
- Festplatten Cache
das begrenzende Element ist.
MfG

[larsbo]

Nach dem was ich so an benches gesehen habe (z.B. auch c´t) und was ich selber mit meinen zwei Maxtor 80GB Sata als Raid0 auf Epox8KRA2+ (auch KT600/VT8237) gebenched habe, scheinen die Hitachis mit ca 105-110 Megabyte/s das schnellste Interface zu haben, dicht gefolgt von Maxtor(auch noch über 100MB/s). Der Rest folgt aber relativ dicht. Das lässt sich z.B. mit h2benchw -core von heise ganz gut durchmessen. Bei einer stripe size von 64kB bringt der coretest übrigens dann bei Raid0 nicht mehr, weil der ja auch nur 64kB hin-und herschaufelt. Daher hab ich noch keine wirklich aussagekräftigen benches zur interface speed im Raid0 gemacht. Wenn man der ct glauben darf, gehen aber 200MB/s bei der 8237 durchaus, und das wäre ja schon das Maximum was aus zwei Platten zu holen ist. Ich denke die Festplatten-caches sind noch limitierend und nicht das Interface oder die SB.

Insgesamt verwurstet die 8237 intern max. ca 250MB/s, wieder laut c´t. Mit Sata Raid0 und noch ein PCI-Raid mit 100MB/s bringt man also auch eine 8237 locker an die Grenzen. Die c´t hat spekuliert, die SB könnte intern als 66MHz PCI-Bus aufgebaut sein. Könnte durchaus Sinn machen, das Design wäre dann sicher recht unkompliziert und der 8xVlink ist ja auch mit 66MHz getaktet. In der Praxis ist das System jedenfalls ausgesprochen flüssig, auch wenn ich z.B. Analog-TV gucke und dabei z.B. das Raid kräftig zu arbeiten hat.

gruß
larsbo

[Accuphase]

Original geschrieben von CTN
Und unter HD-Tach sehen die Werte in der Tat etwas anders aus.

Hier sind meine Werte:

http://home.arcor.de/nachti011/Logos/hdtachbench.gif

[CTN]

Was für eine Umgebung muß man eigentlich schaffen um verlässliche Werte zu bekommen.
Habe vier verschiedene Bench-Programme laufen lassen und kein Wert gleicht dem anderen.
Was soll man da denn glauben ????!!!

[SWL]

Original geschrieben von Woerns
Der Artikel in deinem Link zum Thema schlechte Raid0 Performance der Barracuda ist schon eineinhalb Jahre alt (Juli 2002) und bezieht sich auf die Barracuda IV mit IDE Raid Controllern als PCI Karte. Ich glaube kaum, dass die Barracuda V als S-ATA Version noch dieselben Kinderkrankheiten hat. Vielleicht andere...Seagate liefert selbst noch mit der Barracuda 7200.7 relativ schlechte Performance im RAID. Testen läßt sich dies relativ einfach mit h2benchw von der c't und indem man die Platte beim Benchen nicht im RAID betreibt sondern einzeln. h2benchw bietet einen sogenannten Read Ahead Test. Bei diesem Test wird sequentiell, mit kurzen Pausen dazwischen, Sektor für Sektor gelesen.In den kurzen Pausen kann die Platte bereits vorausschauend den nächsten Sektor in den Plattencache laden. Somit werden bei optimaler Firmware beim Read Ahead die Daten fast so schnell wie beim Burst gelesen. Beim RAID 0 passiert genau das gleiche. Während von Platte 1 gelesen wird, kann Platte 2 bereits vorausschauend Daten in den Cache laden.

Leider ist bei Seagate die Firmware nicht optimal, so daß die Datenrate beim Read Ahead nur wenig über der Datenrate beim sequentiellen Lesen liegt. Bei älteren Modellen lag die Datenrate sogar deutlich niedriger als beim sequentiellen Lesen.

Zum Vergleich die Benchmarkergebnisse von h2benchw meiner Platten (jeweils von der äußersten Spur gelesen):

Seagate 7200.7 120GB SATA
Sequentiell: 52,6 MB/s
Read Ahead: 63,1 MB/s
Aus dem Cache: 85,4 MB/s

Hitachi 7k250 160GB SATA
Sequentiell: 58,3 MB/s
Read Ahead: 110,6 MB/s
Aus dem Cache: 114,9 MB/s

Die Werte passen auch in etwa zu den geposteten HDTach Benches. Das Seagate RAID liegt bei der Burst Rate deutlich unter dem Hitachi RAID.

Interessant ist auch, daß die Seagate trotz angeblich nativem SATA selbst beim Lesen aus dem Cache nur 85 MB/s schafft und die Hitachi trotz SATA Bridge auf 115 MB/s kommt.

[Kingalive]

100 mb lesen im schnitt ist ziemlich fett. :o :o :o

aber 40% cpu auslastung ist auch ziemlich heftig.


meine zwei gxp 180 mit sata-adapter an der ich5r schaffen burst etwa 130mb

max ca. 120 mb
und im schnitt ca 90 mb

an die hitachis kommt eben nach wie vor nix ran.

gruss king

[Woerns]

@SWL
Das heißt also, dass der Cache der Platten unterschiedlich genutzt wird. Ich hätte erwartet, dass der sich einfach nur die letzten geschriebenen Daten merkt. Aber anscheinend machen einige Platten (Hitachi vielleicht) einen Prefetch, mit dem erwartete Seiten schon mal reingeladen werden.

Ich hätte erwartet, dass beim Raid0 quasi ein Bit nach links und das nächste nach rechts geschrieben, respektive von dort gelesen wird und somit immer beide Platten in gleicher Weise beschäftigt sind. Ist es tatsächlich so, dass die Daten seitenweise, also etwa in 64kB Einheiten, nach links und rechts verteilt und bei entsprechender Firmware seitenweise prefetcht werden?

Ich verwende den Rechner zum Kompilieren mit VC++. Da werden im Wesentlichen viele kurze Files gelesen und geschrieben. Source-Files haben selten mehr als 10kB und Object-Files sind dann ca. dreimal so groß. Ich würde schätzen, dass die große Mehrzahl der Festplattenzugriffe, ob lesen oder schreiben, unterhalb von 64kB liegen.

Das Prefetchen von Speicherseiten bringt ja nur was bei größeren Datenströmen, wo absehbar ist, welche Daten als nächstes benötigt werden. Wenn ich eigentlich nur ständig Kleinkram schreibe, dann habe ich vom Prefetchen wenig und verspreche mir dagegen mehr von einem durch das Raid0 verdoppelten Cache und einem schnellen Interface, das möglichst viel aus den theoretischen 150MB/s rausholen kann.
MfG

[Kingalive]

du kannst ja bei meisten raidcontrollern die stripesize zwischen 8 und 256 kb einrichten.

8 sollte sich also auch bei kleinkram bemerkbar machen.

gruss king

[Woerns]

@Kingalive
Ahh, danke sehr! Jetzt verstehe ich endlich, was diese "Stripesize" überhaupt ist. Der Name sagts eigentlich schon, aber ich habe auf dem Schlauch gestanden. Das ist ein Parameter, an dem ich drehen werde. Drüber reden, hilft weiter. ;)

Wahrscheinlich muss man die Stripesize festlegen, wenn man das Raid aufsetzt, und dann ist das fest. Oder kann man das im Nachhinein noch machen?

Bei dem ATTO Benchmark, was ist da eigentlich am Zeilenanfang aufgetragen. Da stehen Zahlen von 0.5 bis 1024, worauf beziehen die sich und in welcher Einheit?
MfG

[Woerns]

Ich habe ein bisschen im Netz gestöbert und dabei herausgefunden, dass es umgekehrt ist, als ich angenommen habe: eine kleine Stripesize ist für Streaming Applikationen, wie Audio- und Video-Bearbeitung, vorteilhaft, während bei Random Access, und dazu zähle ich das Kompilieren, eine größere Stripesize besser ist. MfG