Datendurchsatz bei A7V133?

[BARON]

hi leutz,<br>seit einigen tagen bin ich nu auch stolzer besitzer eines A7V133. als ich dann aber von meiner alten platte (am via controller) auf den promise mit 2 ibm ata100 platten im raid0 kopieren wollte kam der schock: die schlappen 8GB haben nach dem update auf bios 1004 über eine halbe stunde gebraucht... auf einen datenvergleich hab ich dann lieber gleich verzichtet...<br>irgendwie kriechen bei mir die daten durch den rechner. es dabei vollkommen egal, ob sie von einer scsi platte, einer ide platte oder auf der gleichen platte kopiert werden sollen.<br>um also nich schon wieder auf der arbeit nach den dunklen augenringen gefragt zu werden: hat jemand ne idee? mein nero gibt auf jeden fall werte zwischen 40.000 und 55.000 KB/s für den promise an. nur die praxis :(<br>btw: ist eine prozessorlast von 100% bei kopiervorgängen wirklich normal?<br><br>In diesem Sinne<br>BARON

[Nero24]

Hi,<br><br>hast Du nach dem Flashen die Setup-Defaults geladen und abgespeichert? Ist extrem wichtig, vor allem wenn Du Platten am Promise hängen hast, da sonst das neue Promise-BIOS nicht richtig initialisiert wird!

[BARON]

hi,<br>ich hab lediglich die ESCD gelöscht. ich hab mir die f/w vom promise vor dem flashen nicht wirklich gemerkt, bin aber der meinung da hat sich nix in der revision getan. werde die sache gleich mal probieren ;)<br><br>thx schonmal für die prompte antwort<br><br>in diesem sinne<br>BARON

[Asclepias]

Hallo!<br><br>Das gleiche hab ich auch festgestellt. Kopieren dauert ewig.<br>Gemessen mit dem W2K Systemmonitor: zwischen 4 und 8 MB/s.<br><br>Benchmarks in SiSoft Sandra 2001 zw. 34000 und 40000 Punkte und hdtach im Mittel 45000.<br><br>Ach ja, verschiedene Promise Fasttrack Treiber getestet. Das einzige was ich festgestellt habe ist, dass die alten beim Kopieren innerhalb des Arrays wirklich 100% Prozessorlast verursachten. Mit der Version 2.00 b6 habe ich dann &lt; 8% CPU Last.<br><br>Einzeln lesen oder schreiben vom Raid Array geht auch sehr viel schneller, aber sobald in dem Array sowohl gelesen als auch geschrieben wird (wie beim kopieren), dann ist das langsamer als zwei getrennte Festplatten ohne Raid (wenn von einer auf die andere HDD kopiert wird).<br><br>Ist ja auch logisch, denn bei 2 einzelnen HDDs muss dann eine nur lesen und die andere nur schreiben !!<br>Im Raid Array müssen beim Kopieren beide HDDs sowohl lesen als auch schreiben, was so viel Performance (im Vergleich) kostet !!<br><br>Fazit: wer viel Daten hin und her schaufelt, ist mit 2 einzelnen Festplatten besser dran als mit Raid, egal was sysnthetische Benchmarks sagen !!<br><br>Aber wie gesagt, bei der täglichen Arbeit ist es etwas schneller mit Raid (aber nicht das Kopieren).<br><br>Aber macht nix, wer gern große Zahlen in Benchmarks ließt, der ist bei IDE Raid genau richtig.<br><br>Hmmm, es hat wohl einen Grund, weshalb SCSI Raid Systeme bei &gt;1000,-DM anfangen.<br>Und, die Lese-/Schreibleistung (im wechsel) ist bei neuen SCSI Festplatten doch um einiges höher als bei IDE HDDs (aber leider auch der Preis und die Lautstärke).<br><br>Hat überhaupt schonmal jemand HDDs beim &quot;gleichzeitigen&quot; Lesen und Schreiben getestet?<br>Dann gehen nämlich die Raten ganz schön in den Keller (im Vergleich zum random read oder random write).<br><br>mfg<br>Tom<br>

[BARON]

@Nero24:<br>da das system nach dem via patch (warte trotzdem sehnsüchtig auf das bios von asus) stabil läuft warte ich erst mal ab. das laden der defaults mit speichern im anschluß hat auf jeden fall keine neuerung für den promise gebracht (1.31 b22).ka, ob das aktuell ist...<br><br>wie ist deine meinung zu der 100% prozessorlast? es ist dabei egal, ob ich von einer anderen platte (ide oder scsi) kopiere oder nicht.<br><br>bleibe dennoch am ball<br>thx BARON