WD 1200 JB = Schnecke???

[Lennier]

Jo was soll i sagen ... das Teil ist ur langsam ... Klar, dass das Raid 1 immer etwas langsamer ist als eine einzelne Platte, aber auf dem Level (i kann nievo ned schreiben *lol*) einer ATA 66 ist doch etwas lahm. Dazu kommt, dass die Extrem lange brauchen bis der RAID Controller sie erkennt. So neben bei ... der Write Cache ist auch ned aktiv .
Also hat irgendwer Erfahrung mit dem HPT Raid Controller bzw. mit dessen Tuning?
Was bewirken die 2 Prameter, die i bei den LW Eigenschaften einstellen kann (tagged Queuing; synchronous transfer).

PS.: Latency Patch 1.05 ist beser als 1.09

[auma]

Kenn zwar die HDD nicht, aber mit dam Raid Kontroller habe ich überhaupt keine Prob. Ich habe den HPT 372 onboard auf meinem Shuttle AK35-GTR.
Hier noch ein paar Sachen, die mir Google ausgeworfen hat.

Unter der »Queue Depth« versteht man die Anzahl von SCSI-Kommandos, die gleichzeitig als auszuführend angegeben werden dürfen. Fehlt eine Angabe, wird standardmäßig 0 verwendet, d.h. es wird ein automatisch bestimmter Wert verwendet, basierend auf der maximalen »Queue Depth« des Host-Adapters und der Anzahl, dem Typ, der Geschwindigkeit und den Fähigkeiten der erkannten Zielgeräte. Bei Host-Adaptern, die »ISA Bounce Buffer« benötigen, wird die »Tagged Queue Depth« automatisch auf BusLogic_TaggedQueueDepth_BB gesetzt, um ausschweifendes Allokieren von »DMA Bounce Buffer«-Speicher im voraus zu vermeiden. Zielgeräte, die »Tagged Queuing« nicht unterstützen, verwenden eine »Queue Depth« von BusLogic_UntaggedQueueDepth.
Ähnlich wie bei der WDTR-Message, geht es bei der SYNCHRONOUS DATA TRANSFER REQUEST (SDTR) Message um das Aushandeln maximaler synchroner Transferraten.


Dabei handeln die Geräte eben aus, mit welcher synchronen Rate die Daten übertragen werden können.

Genauso wie bei WDTR gilt diese Aushandlung solange, bis einer der genannten Fälle die Absprache ungültig macht.

[Loewe]

Bei einem Gespräch in der Firmenzentrale gab VIAs Leiter des Chipsatz-Marketing nach monatelangen Erklärungsversuchen den Grund für die anhaltenden PCI-Probleme zu. VIAs Chipsätze haben tatsächlich den Datenfluss auf dem Bus nach Belieben unterbrochen.
Che-Wei Lin ist bei VIA "Senior Director of Product Marketing" und wie bei Chipfirmen üblich Ingenieur. Die Ende 2001 von tecCHANNEL aufgedeckten Probleme mit dem PCI-Bus hatte VIA bisher nie wirklich aufgeklärt. Lediglich ein Patch sorgte für bessere Performance beiIDE-RAIDs und höherer Kompatibilität mit Soundkarten.
In Taipei gab Che-Wei am vergangenen Mittwoch Einblick in das, was die Chiphersteller "root cause" nennen. Damit wird ein grundlegendes Problem bezeichnet, das zu Inkompatibilitäten, Datenfehlern oder instabilen Systemen führen kann. Dieser "root cause" ist meist schwer zu finden, da die Probleme erst durch eine lange Kausalkette auftreten.
Laut Che-Wei arbeiteten alle Southbridges bis zum Baustein 8233A mit einen höchst unüblichen Verfahren. Wenn zwei Busmaster-Geräte den Bus zur gleichen Zeit nutzen wollten, zählte ein Timer in der Southbridge die Takte mit. Nach einer bestimmten Anzahl von Takten wurde der Transfer unterbrochen, und das nächste Gerät konnte Daten übertragen. Dieses Spiel beginnt dann von vorne.
Damit hat VIA, so Che-Wei, die aufwendige Arbitrierung des Busses umgangen. Dieses Verfahren sei jedoch mit der Southbridge 8235 abgeschafft. Wie berichtet , soll die neue 8235 bei allen noch 2002 erscheinenden VIA-Chipsätzen zum Einsatz kommen.
Damit ist auch das Versprechen eingelöst, das VIAs CEO Wenchi Chen auf der CeBIT in einem Interview mit tecCHANNEL gab. Eine der neuen Southbridges befindet sich derzeit in unserem Testlabor. Sobald die Versuche abgeschlossen sind, erscheint dazu eine ausführliche Analyse. (nie)

VIA eben.

[Lennier]

Tja, dazu kann i nur sagen Via Latency Patch 1.05 verwenden, weil 1.09 ist a sch***.
Das ändert aber nix an dem Problem, dass i zum Booten 7min brauch, weil 4 min der Raidkontroller wartet, bis die HD´s sich melden *argl* ... mit den GXP 60 ging das ruckzuck.

[Loewe]

Naja

Schnell wird dein System nie werden, weil der Controller die Daten nicht Simultan sondern nur abwechselnd schaufeln wird.

[Lennier]

Ähm .. ist ein Highpoint, und kein Promise. Der schaufelt nämlich umständlich.

[Loewe]

Stimmt eigentlich

[Lennier]

Na toll ... erst dachte ich das Kabel ist defekt und habe die 2. platte als slave angeschlossen. Nu erkennt er Sie recht schnell. Dann hab i das kabel getauscht (das vermeintlich defekte) und es ging genauso schnell. Hmmm jetzt muss i mich doch fragen was das für ein mieses Interface ist auf der WD.
Kann mal jemand mit HPT RAID Onboard und mirror RAID mir infos geben?? Habt ihr die 2 Platten an einem Strang??? Könnt ihr unterschiede zwischen 2 und 1 Strang Betrieb feststellen??

[Karl]

@Lennier!
Habe mal gelesen das sich bestimmte Platten für den Raidbetrieb nicht eignen. Kann mich aber leider nicht mehr erinnern welche das waren.

Sicher keine grosse Hilfe für dein Prob aber vielleicht forscht in diese Richtung weiter oder es weiss jemand anderer was genauer.

[valo]

seagate barracuda 4 taugen ned für raid... hat seagate auch zugegeben...