Welche Festplatte für Raid0?
- Ersteller Dekal
- Erstellt am
Madnex
Urgestein
Nun ja, wahrscheinlich haben seine Tests ergeben, dass es doch nicht so viel bringt 
Carsten1986
Calimero
- Mitglied seit
- 02.12.2003
- Beiträge
- 2.998
k bekomme morgen 2*80gb 7k250 fürs raid0 @ ich5r aufm max3
will einer tests?
die gibst denke ich am weekend
will einer tests?
die gibst denke ich am weekend
Carsten1986 schrieb:
vergleichstests zwischen dem raid0 und einer einzelnen "80gb 7k250" (in deinem fall) - sehr gerne! nur die werte des raid0 helfen leider nicht weiter, da ladezeiten in spielen u.a. stark von der grafikkarte abhängig sind...
Dekal schrieb:
Dekal schrieb:
loores schrieb:
loores schrieb:
Und hier etwas für dich loores, damit du noch einmal 2 wichtige Postings direkt vor Augen hast:
Madnex schrieb:
Dekal schrieb:
loores, aufpassen was du anderen in den Mund legen möchtest. Ich habe nie behauptet, dass durch das Übertakten des PCI-Bustaktes keine erhöhte Bandbreite zustande kommen würde, sondern ich habe zunächst wiederlegen wollen, dass dies:
Madnex schrieb:
und das:
loores schrieb:
zutrifft. Ich komme unweigerlich durch
kurzes Überdenken der von mir gesammelten Erfahrungen auf das Ergebnis, dass diese Annahmen falsch sind. Es liegt kein Bug im BIOS vor, da ich durch Soundfehler oder Ruckler in der 3D-Grafik spüre dass der PCI/AGP-Bustakt wirklich höher geworden ist. Deshalb ist diese Annahme falsch. Mit Timings kann es auch nix zutun haben, da bei noch so lockeren Timings immernoch eine MINIMALE Verbesserung/Änderung der Bandbreite zu messen wäre. Es tut sich aber rein garnichts hinsichtlich der Bandbreite. Also ist diese Annahme auch auszuschließen. Das einzige was mir bei der Datenübertragung aufgefallen ist, das ist ein kurzzeitiges einmaliges Aussetzen bei der Datenübertragung.
Dann habe ich dir, loores oben unterstrichen was an meinen beiden Aussagen entscheidend ist. Es ist kein Widerspruch zu behaupten, dass eine Anhebung des PCI-Bustaktes keine Verbesserung der Bandbreite DES SATA-CONTROLLERS bringt, aber dass eine Anhebung des PCI-Bustaktes eine erhöhte Bandbreite verursacht. Genau das habe ich nämlich getan. Demnächst bitte etwas genauer nachlesen.
Madnex schrieb:
Es ist doch hierbei völlig egal ob es nun so herum:
Clock-Gen-->16 MHz-->PLL-->x2-->Stabilisierung auf 33 MHz-->33 MHz
oder so herum läuft:
Clock-Gen-->33 MHz-->PLL-->Stabilisierung auf 33 MHz-->33 MHz
Dieses Beispiel ist nur ein Gedankenspiel meinerseits und ist deshalb in keinem Falle zwingend mit den realen Bedingungen zu vergleichen. Aber ich denke dass die Funktionsweise so ähnlich aufgebaut ist.
Madnex schrieb:
Wie auch immer das im Detail ist, es kann wohl kaum behauptet werden, dass es nicht einen universellen externen Divider geben kann, der eigens für externe Geräte wie LAN, SOUND oder SATA hergestellt wurde und vielleicht für alle diese Geräte zusammen genutzt wird. Da ich hier wieder anfange zu spekulieren, ist es eh sinnlos eine eindeutige Aussage diesbezüglich zu treffen. Die Schaltung (PLL) im Sil3112 existiert sicherlich nicht umsonst. Ich denke mir folgendes:
Wenn der PCI-Takt auf 40 MHz angehoben werden würde, dann sähe es angelehnt an meinem obigen Beispiel folgendermaßen aus:
Mit einem fixsiven Divider von 1/2 (16 MHz):
Clock-Gen-->20 MHz-->PLL-->x2-->Stabilisierung auf 33 MHz-->33 MHz
ohne Divider:
Clock-Gen-->40 MHz-->PLL-->Stabilisierung auf 33 MHz-->33 MHz
In beiden Fällen wäre ein Übertakten des SATA-Controllers durch das Anheben des PCI-Bustaktes unmöglich.
DoubleJ schrieb:
Double, einfach zuerst einmal genau nachlesen, dann enttäuscht sein.
Dekal schrieb:
Madnex schrieb:
Ich war bisher leider nicht in der Lage soweit durchzutesten, dass ich dies feststellen hätte können. Ich habe immerhin eine 50-60-Stunden Woche in der ich unentwegt arbeite, eingeschlossen ist der Samstag, an dem ich zumeist 5 Stunden arbeite und dann noch lange nicht zu Hause/fertig mit der Arbeit bin. Am Sonntag bin ich dann froh, mal etwas auszuspannen zu können.
DoubleJ schrieb:
Wenn er die gleiche Grafikkarte & andere Hardware wieder zum testen nimmt, dann sind die Ladezeiten für eine Vergleichsbasis verwertbar.
Zuletzt bearbeitet:
Madnex
Urgestein
Ich möchte dich jetzt nur mal an den PCI/AGP-Fix erinnern. Dieses Feature gab es lange Zeit, zumindest bei der AMD-Plattform, nur bei Mainboards mit einem bestimmten Chipsatz. Dem nForce2 von NVIDIA. Bei Boards mit anderen Chipsätzen suchte man dieses Feature vergebens. Und warum? Weil es diese Chipsätze (ob nun von VIA, SIS oder ALI) nicht unterstützt haben. Und was zeigt uns das? Was, wie geteilt, multipliziert oder entkoppelt werden kann, hängt in erster Linie vom verwendeten Chipsatz und dessen Fähigkeiten ab.
Wenn es einen universellen externen Divider gibt, für was ist dann der PCI/AGP-Fix gut? Erkläre mir das bitte mal. Gehen wir mal davon aus, es gibt so einen externen Divider. Wäre es dann nicht auch ein leichtes für jeden einzelnen PCI- und AGP-Slot den Takt festzusetzen? Die Anbindung ist die gleiche. Nur anstelle von fest verlöteten Chips sind dort Steckplätze für Erweiterungskarten. Aber warum wird das nicht getan? Falls du jetzt mit der Argumentation loslegen willst, dass man ja gar nicht weiß ob das nicht vielleicht so ist. Für was ist dann der PCI/AGP-Fix gut?
Denke mal darüber nach
CU
Zuletzt bearbeitet:
Dekal schrieb:Double, einfach zuerst einmal genau nachlesen, dann enttäuscht sein.
Du hast geschrieben: "Ausserdem sehe ich sowieso keinen Grund mehr, dieses Benchmark als Beweiß für den Sinn eines RAID0-Systems hierein zustellen". Gesetzt den Fall du stellst die Ergebnisse tatsächlich nichtmehr hier rein stimmt meine Aussage "es bleiben nur sr und atech als quellen für einen vergleichstest" doch. Oder steht irgendwas zwischen deinen Zeilen, was ich überlesen habe?
Dekal schrieb:
Im Forum wird wohl niemand die gleiche Konfiguration haben wie ich. Selbst wenn dem so wäre halte ich es doch für ein übles Gerücht, dass man die Ladezeiten der beiden Systeme dann vergleichen könnte, da nicht zuletzt wohl auch die Windows-Installation eine entscheidene Rolle spielt und die Ladezeiten beeinflusst.
Zuletzt bearbeitet:
Madnex schrieb:
Das werde ich auch nicht tun. Quellen gibt man nicht weiter, vorallem dann nicht, wenn eine solch flammende Diskussion geführt wird. Ich kann nur eine weitere für dich vielleicht etwas befriedigendere Vermutung ausprechen. Er besitzt ein Intel-System und wird sich daher hauptsächlich mit der Technik in Intel-Mainboards auskennen und hat vermutlich nicht den weitestgehend/oder gar ausschließlich auf AMD-Mainboards verbauten SATA-Controller Sil3112 gemeint. Er gab mir den Tipp, dass diese Infos in den Intel Chipsatz Spezifikationen stehen. Das lässt dann aber immernoch die Frage offen, wieso eine Anhebung des PCI-Bustaktes keine Performance-/Bandbreitenerhöhung verursacht.
Madnex schrieb:
Warum gibt es heutzutage noch einen PCI-Slot, obwohl doch intern eine vielfach höhere Bandbreite genutzt werden könnte? Ich gebe sogar die Antwort: Weil die Hersteller aufgrund von finanziellen Einsparungen es nicht für nötig empfunden haben, eine andere Schnittstelle zu integrieren. Hingegen ist es ein leichtes, eine/nein sogar viele Erweiterung/en in einen kleinen PLL-Chip zu integrieren. Dies wäre finanziell kein solch großer Verlust. Hinzu kommt noch, dass in meinem Falle ein Nvidia nForce2 Chipsatz zum Einsatz kommt, der sowieso von Grund auf erneuerte features zu herkömmlichen Plattformen bietet. Ich könnte jetzt sogar die Behauptung aufstellen, dass der starke Konkurrenzkampf zwischen den Chipsatzherstellern (Nvidia und VIA z.B) dazu geführt hat, dass Nvidia der Konkurrenz mehrere Schritte voraus gehen wollte. Man braucht nur die vielen extra features des Nvidia nForce2 zu betrachten, dann sieht man diese Behauptung schon. Aber unser eigentliches Thema läuft schon wieder auf ein Zwischen-Thema hinaus. Gib du mir lieber mal eine Antwort auf die Frage:
Dekal schrieb:
DoubleJ schrieb:Du hast geschrieben: "Ausserdem sehe ich sowieso keinen Grund mehr, dieses Benchmark als Beweiß für den Sinn eines RAID0-Systems hierein zustellen". Gesetzt den Fall du stellst die Ergebnisse tatsächlich nichtmehr hier rein stimmt meine Aussage "es bleiben nur sr und atech als quellen für einen vergleichstest" doch. Oder steht irgendwas zwischen deinen Zeilen, was ich überlesen habe?
Na dann ließ nochmal genau nach was ich geschrieben habe. Ich erkläre es dir noch einmal:
Der erste Satz den ich geschrieben habe lautet:
Dekal schrieb:
Womit ich sichergestellt habe, dass ich dieses Benchmark irgendwann durchführen und hiereinsetzen werde, sowahr Gott will und ich lebe.
Dann habe geschrieben:
Dekal schrieb:
Die Beweiße sind uns schon um die Ohren geplatzt. Wenn ich dieses Benchmark durchführe, dann nicht mehr wie geplant, um etwas zu beweisen, sondern spaßhalber.
Das war meine genaue Aussage.
DoubleJ schrieb:
Achso. Es war für mich nicht genau ersichtlich, welche Vergleichsbasis du heranziehen wolltest. Dann habe ich da wohl was falsch verstanden.
@Dekal
Eine Diskussion deshalb unter deinen Vorausetzungen zu führen, ist sinnlos. Du hast zuerst eine angebliche Quelle angeführt, willst sie nun aber partout nicht nennen.
Da stellt sich mir die Frage, warum? Hast du uns angelogen, existiert sie gar nicht? Oder ist sie dermassen unseriös und unzuverlässig, dass du sie nicht nennen kannst? So oder so, nicht gerade ehrlich dein Verhalten.
cu
loores
Diese Tatsache ist mir gänzlich neu. Bislang ging ich von der Annahme aus, dass seriöse Quellen benötigt werden, um Aussagen zu untermauern und zu beweisen.
Eine Diskussion deshalb unter deinen Vorausetzungen zu führen, ist sinnlos. Du hast zuerst eine angebliche Quelle angeführt, willst sie nun aber partout nicht nennen.
Da stellt sich mir die Frage, warum? Hast du uns angelogen, existiert sie gar nicht? Oder ist sie dermassen unseriös und unzuverlässig, dass du sie nicht nennen kannst? So oder so, nicht gerade ehrlich dein Verhalten.
cu
loores
Zuletzt bearbeitet:
@Dekal
1.) Mein Abit IC7-G verwendet den selben Sil3112A.
2.) Wieso sollten die Specs eines externen PCI basierten ICs in den Whitepapers des Chipsatzes stehen? Deine Quelle meint nicht per Zufall den SATA-Kontroller des ICH5(R)?
--------------------------------------------------------
1.) Weil der 32Bit/33MHz PCI standardisiert und seine Spezifikationen zugänglich sind?
2.) Oder weil es bislang - also vor PCI-Express - keine Schnittstelle gab, welche schnell genug war? PCI64 scheidet ja schon alleine auf Grund des Platzbedarfs aus.
cu
loores
1.) Mein Abit IC7-G verwendet den selben Sil3112A.
2.) Wieso sollten die Specs eines externen PCI basierten ICs in den Whitepapers des Chipsatzes stehen? Deine Quelle meint nicht per Zufall den SATA-Kontroller des ICH5(R)?
--------------------------------------------------------
1.) Weil der 32Bit/33MHz PCI standardisiert und seine Spezifikationen zugänglich sind?
2.) Oder weil es bislang - also vor PCI-Express - keine Schnittstelle gab, welche schnell genug war? PCI64 scheidet ja schon alleine auf Grund des Platzbedarfs aus.
cu
loores
Guten Abend
Also ich hab 2 Dinos (36 GB) in meinem rechner als Raid 0 (Stripe Size 16KB) und muß sagen es hatt sich nicht wirklich gelohnt zwar schneide ich in den Benchmarks ganz gut ab aber im Altagsbetrieb merke ich nicht sehr viel davon hab eigentlich mehr erwartet für meine Investition (220 Euro).
Aber vieleicht hab ich auch was falsch eingestellt gerade weil ich ja jetzt ein nforce 3 board habe und der S-ATA ja jetzt nicht mehr über den PCI läuft aber davon merke ich kein bisschen.
Vieleicht hatt ja noch jemand ne Idee!
HD Tach: Burst Speed: 201.5
Average read 98.7
Random acces 8.9 ms
CPU 7%
Also ich hab 2 Dinos (36 GB) in meinem rechner als Raid 0 (Stripe Size 16KB) und muß sagen es hatt sich nicht wirklich gelohnt zwar schneide ich in den Benchmarks ganz gut ab aber im Altagsbetrieb merke ich nicht sehr viel davon hab eigentlich mehr erwartet für meine Investition (220 Euro).
Aber vieleicht hab ich auch was falsch eingestellt gerade weil ich ja jetzt ein nforce 3 board habe und der S-ATA ja jetzt nicht mehr über den PCI läuft aber davon merke ich kein bisschen.
Vieleicht hatt ja noch jemand ne Idee!
HD Tach: Burst Speed: 201.5
Average read 98.7
Random acces 8.9 ms
CPU 7%
Madnex
Urgestein
Dem, was loores dazu schreibt, ist nichts hinzu zu fügen. Ich bin der selben Ansicht.
Merkst du nicht, dass genau das meine Vermutung bestärkt, dass die Einstellung im BIOS nicht übernommen wird? Schließlich limitiert nicht der SATA-Adapter die Übertragungsleistung deines RAIDs sondern der PCI-Bus. Durch Übertaktung des Busses muss sich zwangsweise die Bandbreite erhöhen. Tut sie das nicht, kann der Bus auch nicht übertaktet sein. Selbst wenn der Silicon Image Adapter bei Anhebung des PCI-Bus Taktes nicht mitübertaktet wird, würde sich dennoch eine Leistungssteigerung feststellen lassen. Da der limitierende Faktor hier die Bandbreite des PCI-Busses ist und nicht der RAID-Adapter ansich. Erhöht sich die Bandbreite des Busses durch die BIOS-Einstellung nicht, liegt auch keine Übertaktung vor!
Toll, wie du versuchst auf meine Argumentation nicht einzugehen und dich quasi davor drückst. Ich würde aber dennoch gerne von dir hören, wie das deiner Meinung nach möglich ist. Für was ist dann also der PCI/AGP-Fix gut? Wenn sowieso, nach deiner Meinung, jeder PCI-Slot und jedes am PCI-Bus angebundene Gerät einen eigenen Divider hat, also unabhängig vom PCI-Bus Takt ist, für was braucht man dieses Feature also?
CU
loores schrieb:
Gut zu wissen
loores schrieb:
Das weiß ich doch nicht... Such doch lieber mal selbst. Deiner Aussage nach ist meine Quelle ja eh zweifelhaft, obwohl die eigentliche Quelle die Intel Chipsatz specs sind.
loores schrieb:
Intel Chipsatz Spezifikationen.
Ist die Quelle nicht serious genug? Warum sollte ich lügen?loores schrieb:
Die Umstellung wäre sowohl technisch als auch logistisch ohne weiteres schon länger realisierbar gewesen. Die erhöhte interne Bandbreite (Speichertakt und Prozessortakt, die 2 entscheidensten Kriterien) ist schon länger vorhanden... Erfindungen gab es sicherlich auch schon eine Menge. Jedoch müssen nicht alle Erfindungen auch an die Öffentlichkeit gelangt sein.
Meine Meinung hierbei ist, dass es die Hersteller für den Otto-Normalverbraucher nicht für nötig empfunden haben. Doch jetzt, wo Nvidia auch im Mainboard-Chipsatzmarkt mitmischt, sind auf einmal alle aufgewacht und erweitern ihre features am laufenden Bande, und das noch schneller als es zuvor war. Das nennt man Konkurrenzkampf! Und das ist auch gut so!
loores schrieb:
Der Platz existiert ohnehin. Es hätte auch finanziell nicht all zuviel ausgemacht diese Schnittstelle zu integrieren. Es sei denn das Patent (im neusten Falle PCI-Express) ist für seine Leistungsfähigkeit dermassen überteuert gewesen, dass kein Hersteller zugegriffen hat, was bei PCI64 sicherlich nicht der Fall war.
Madnex schrieb:
Hieran merke ich, dass du der Argumentation nicht ganz folgen konntest. Ließ noch einmal alles in Ruhe nach (sowahr du die Zeit dazu hast) und dann weißt du, dass sich meine Vermutungen nicht ganz, aber mit vorbehalt größtenteils bestätigt haben, wenn das Prinzip, welches ich versucht habe darzustellen, greift.
Madnex schrieb:
1. Bin ich auf deine Argumentation eingegangen.
Dekal schrieb:
Hättest du das Zitat in deinem Posting etwas erweitert, so hättest du die Antwort mitzitiert!
2. Habe ich dir ebenfalls versucht zu erklären, wieso die Situation bei einem PLL-Chip etwas anders sein müsste.
Dekal schrieb:
"Sein müsste" ist hier einfach wieder einmal zu vorsichtig ausgedrückt. Nvidia hat es uns bereits gezeigt, wie schnell so eine Integration von neuen Möglichkeiten im Chipsatz möglich ist, ohne dass jetzt die Firma pleite gegangen ist.
Zuletzt bearbeitet:
Madnex
Urgestein
Eben nicht. Lies du lieber noch mal meine Argumentation in Ruhe durch
.Nein, bist du nicht wirklich. Du hast lediglich über das noch vorhandensein des PCI-Busses gerätselt und darüber sinniert warum dieser Bus nicht schon längst durch andere, schnellere abgelöst worden ist. Darüber hinaus hast du wilde Spekualtionen angestellt, dass durch die nForce Chipsätze eine kleine Technik-Revolution entfacht worden ist, womit du versuchst deine Argumentation zu belegen. Was dir so niemals gelingen wird. Das alles erklärt aber immer noch nicht, warum es einen PCI/AGP-Fix gibt bzw. warum dieser Fix nach der Ansicht von NVIDIA notwendig war und immer noch ist. Und genau auf diese Frage bist du nicht eingegangen. Du hast nur um den heißen Brei herumgeschrieben.
Tja, ich wollte nicht den gesamten Text quoten. Dieses Quoting sollte lediglich dazu dienen, damit du weißt um welchen Abschnitt es sich handelt. Ich habe daher nur ein Teil des Textes zitiert und am Ende einige Punkte gemacht (was dir anscheinend nicht aufgefallen ist). Aber wie ich schon geschrieben habe, bist du auf die eigentlich Frage gar nicht eingegangen. Die immer noch lautet: Warum gibt es einen PCI/AGP-Fix, wenn das denn so ist wie du meinst?
Was wiederum wilde Spekulationen sind, die weder Hand noch Fuß haben. Was soll das beweisen? Hingegen hast du bisher erfolgreich mein Gegenargument, das Vorhandensein des PCI/AGP-Fixes, ignoriert. Wäre es so, wie du vermutest, wäre dieser Fix nicht notwendig. Verstehst du das nicht?
Im Übrigen beherrschen die Chipsätze von Intel imho ab dem i845P das fixieren der PCI-und AGP-Bus Frequenz. NVIDIA war da nicht der erste. Die Vermutung liegt daher nahe, dass dein Bekannter genau dieses Feature gemeint hat, welches in den Chipsatz-Spezifikationen von Intel steht. Was aber nichts daran ändert, dass bei Übertaktung des Busses auch alle anderen PCI-Geräte mitübertaktet werden (auch bei Intel basierenden Boards). Lediglich bei der Übertaktung des FSB passiert da logischerweise nichts, da das die Aufgabe von dieser Funktion ist.
Zuletzt bearbeitet:
Das ist jetzt auch wieder eigenartig:Dekal schrieb:
1.) Du sprachst von einer Person als Quelle, nicht von Specs.
2.) Ich muss suchen um DEINE Argumentation zu stützen? Ich weiss nicht recht.
3.) Scheinst mir etwas eingeschnappt zu sein.
1. Weil sie zu teuer sind?
2. Weil es sie nicht braucht?
3. Weil sie zu erhöhter Komplexität (Sprichwort 5 Volt vs. 3.3 Volt) führen?
Durch Grafikkarte an AGP, Hublink/V-Link, IDE@SB, USB@SB etc. Sound@SB, liess sich dieser Schritt lange aufschieben. So lange, bis PCI-e da war.
Dass das irgendetwas mit nVidia zu tun hat, bezweifle ich.
1.) PCI64 war nie als Nachfolger von PCI gedacht sondern nur für WKS und Server so wie der spätere PCI-X.
2.) PCI64 ist zu teuer für ein Desktop-System
cu
loores
Madnex schrieb:
Bin ich in der Tat nicht, da ich irgend etwas durcheinander gewürfelt habe. Deshalb habe ich einen anderen Weg bei der Argumentation eingeschlagen. Das tut aber auch nichts zur Sache. Ich habe nämlich weiter oben 2 verschiedene Skizzen aufgezeigt, die möglicherweise eine Erklärung für das Problem liefern. Dabei spielt das PCI/AGP-Fix keine Rolle.
Madnex schrieb:
Nun mal langsam mit den Ausdrucksformen. Ich habe nicht nur gerätselt und siniert, sondern ich habe mir viel Wissen angeeignet, welches mir diese freie logische Denkweise gestattet. Möge mir einer das Gegenteil von dem beweisen, was ich hier geschrieben habe, dann gestehe ich meine möglicherweise entstandenen Denkfehler auch gerne ein.
Madnex schrieb:
Ist hieran etwas falsch? Das sind keine Spekulationen. Es ist die Wahrheit.
Madnex schrieb:
Du hast bei der ganzen Diskussion wieder einmal etwas vergessen. Ich glaube, ich habe weiter oben schon einmal geschrieben, dass ich mich auf die AMD-Plattformen beziehen würde, da hier das Problem der trotz Übertaktung des PCI-Buses verbleibenden geringen Bandbreite untersucht wird und nichts anderes.
Madnex schrieb:
Ich frage mich manchmal was du dir zurecht spekulierst... Sollte der PCI/AGP-Fix etwas mit dem zutun haben, was ich oben skizzenhaft aufgezeigt habe?! Nein.... Deine Versuche, diese Theorie zu wiederlegen, werden dir mit dieser Art von Untermauerung nicht gelingen.
Madnex schrieb:
Was vermute ich denn? Betrachte dir einmal die 2 Skizzen, dann weißt du was ich vermute. Ich habe 2 verschiedene Möglichkeiten aufgezeigt. Also vermute ich 2erlei.
Madnex schrieb:
Bitte lasst jetzt einfach mal meinen bekannten aus dem Spiel. Ich werde ihn als Quelle nicht entlarven und dabei bleibt es. Ich habe euch beiden sogar die Quelle von der Quelle genannt, die viel präzisere reichhaltigere Informationsvielfalt hergibt. Wir wollen doch Ursachenforschung betreiben oder?!
Ausserdem sei nochmals erwähnt, dass hier die Methoden von Intel völlig anders zu sein scheinen, was uns nicht weiterhilft bei der Diskussion. Da hilft auch keine Dummstellerei @ loores.
Ach nochwas an dich loores:
loores schrieb:
1. Alles ist anfänglich teuer, bis es in Mengen vermarktbar ist.
2. Alles was zu einem enormen Leistungsschub führt kann als "zu gebrauchen" bezeichnet werden.
3. Diese Art von Umstellung gab es aber schon bei vielen Geräten des PC's. Ein Beispiel ist der AGP-Bus selbst.
Ein Empfehlung an euch beide:
Dekal schrieb:
Das war meine eingeschobene Vermutung, die zugleich eine Fragestellung in sich birgt. Bis jetzt habe ich ohne Zweifel viele Wege bei der Ursachenfindung eingeschlagen, bin jedoch immer von einem vom PCI-Takt enkoppelten SATA-Controller ausgegangen. Bis jetzt war ich derjenige, der versucht hat eine Erklärung zu finden. Ihr wart es, die meine Erklärungen zunichte machen wollten. Nun drehen wir doch einfach mal den Spieß um und ihr stellt Theorien auf, oder besser noch, kommt mit harten Fakten, die durch diverse anschauliche Quellen belegt werden können. Ich habe nämlich einfach keine Lust mehr auf das "Katze jagt die Maus Spiel".
Zuletzt bearbeitet:
Z
Zidane
Guest
DoubleJ schrieb:
Nur wenn das Spiel z.b Doom 3 ein paar GB Textures Files dekomprimiert das bringt es auf jedenfall, dies geht in der Regel im Raid-0 schneller als mit nur 1 HD Da eben die Schreib/Leseraten hier höher sind, aber würde glaube auch schon oft genug ausdisskutiert.
@All,
Manchmal frage ich mich ob diese Raid-0 Diskussion wirklich Sinn macht, ich denke nicht, solange jeder auf seinen Standpunkt bleibt, und keiner sich vom Gegenteil sofern es auch richtig ist überzeugen lassen kann.
Aber währe vielleicht mal interessant gewesen wenn dieses Thema schon 2001 gewesen währe, dann hätte ich euch sagen können ob eine erhöhte PCI-Frequenz die Bandbreite des Controller erhöhen könnte oder nicht.
Anhand eines Epox EP-8K7A+ AMD-761+686B mit Highpoint 370A On-Board per PCI. Mit dabei 2x 60GB IBM iC-35 AVER-07. Und einen PCI-Bus der mit 33 und fast 40 Mhz läuft bei einer FSB Anhebung von 133-157Mhz soweit ich mich noch entsinnen kann. Das interessante dabei war noch das ich grad mit diesem Board und den Platten eine Transferrate von 125 !!! MB/Sec hatte dies ist heute mit keinem PCI-Bus angebundenen Controller möglich. Weder mit N-Force 2 noch mit den VIA-Chipsätzen. Aber ob dies im OC-Zustand war kann ich nicht mehr sagen ist schon lange her.
Des letzteren bringt aber die Diskussion nichts, für mich macht es kein Sinn ein Raid bassierendes System an einem PCI-Controller zu betreiben, aufgrund der hohen Belastung des Busses, da ja nicht nur die PCI-Slots und deren Karten versorgt werden müssen, sodern auch meist viele On-Board Komponenten wie Lan etc mit versorgt werden.
Das wie weiter oben erwähnt ein neuer PCI-Bus (PCI-E) was bringt, wobei es ja schon den PCI-66 Mhz Bus vorher gab mit 266MB/Sec das mal nebenbei in Form eines AMD-76x Chipsatzes, bringt es immo gar nichts wenn Hersteller die Anbindung nicht für On-Board Sachen nutzen, z.b ABIT und 2 GB-Lan Anschlüsse an den alten PCI hängt, oder der PCI-E Takt beim ocen nicht fixiert wird, die selben Fehler werden gemacht wie vorher aus, neue Technik ok, aber die Umsetzung ist einfach mangelhaft, nur zu dumm das man sowas erst später in Reviews ließt, oder selbst die Erfahrungen macht, sozusagen das Versuchskaninchen spielt. Würde daher erstmal den ganzen neuen Kram solange ablehnen bis die Hersteller es begriffen haben.
Madnex
Urgestein
@Dekal
Gut, gehen wir es mal anders an. Ein RAID-0 Array wird normalerweise durch die Bandbreite des PCI-Busses mittlerweile limitiert. Auch wenn die Platten schneller die Daten liefern können, geht es nicht schneller. Durch die Anhebung der PCI-Bus Frequenz wird normalerweise die Bandbreite des Busses erhöht (in der Theorie sowie in der Praxis) und somit sollte auch die Übertragungsrate der Platten automatisch höher sein (wegen der höheren Bandbreite des Busses und der überschüssigen Leistung des Arrays). Das hat erst mal nichts damit zu tun, ob der Controller dabei übertaktet wird oder nicht. Wenn die Bandbreite erhöht wird und der Plattenverbund schneller könnte als der PCI-Bus im Stande ist Daten zu liefern, MUSS auch die Transferrate des RAID-0 dabei ansteigen (wohl gemerkt, mit Annahme, dass der Controller nicht übertaktet ist)! Geschieht dies nicht, bleibt als einzige logische Schlussfolgerung die Tatsache, dass der PCI-Bus gar nicht übertaktet ist (auch wenn im BIOS die jeweiligen Einstellungen vorgenommen wurden), was wiederum meine Vermutung bezüglich des BIOS-Bugs bekräftigt.
Andernfalls, wenn das Array nicht am Limit des PCI-Busses kratzt und du den Takt des Busses anhebst und angenommen der SATA-Controller wird dabei auch übertaktet, bedeutet das ja noch lange nicht, dass die Festplattenleistung auch ansteigen wird. Die Leistung von Festplatten wird immer noch von ihrer Mechanik bestimmt. Nur durch die Anhebung einer Bandbreite (ob nun die des PCI-Busses oder die der SATA-Scnittstelle ist dabei egal) werden Festplatten nicht schneller. Dadurch drehen sie nicht schneller. Haben also keine höhere mechanische Transferrate und auch die Zugriffszeit wird nicht besser. Die mechanische Leistung bleibt also in jedem Fall gleich.
Edit:
Und bedenke, PRO KANAL steht denn Platten eine Bandbreite, je nach Übertragungsprotokoll, von 100, 133 oder 150 MB/s (abzüglich Overhead) zur Verfügung. Hängen die Platten an verschiedenen Kabeln stehen dem Array von Seiten des Controllers also 200, 266 oder 300 MB/s Bandbreite (bei zwei Platten) zur Verfügung. Die jeweiligen Bandbreitenangaben beziehen sich immer nur auf einen Kanal. Werden diese, wie es bei einem RAID-0 geschieht, gekoppelt, verdoppelt sich die theoretische Bandbreite (bei zwei Kanälen) der Schnittstelle. Da die beiden Platten in unserem Beispiel zur Datenübertragung voneinander unabhängige Kanäle benutzen.
Gut, gehen wir es mal anders an. Ein RAID-0 Array wird normalerweise durch die Bandbreite des PCI-Busses mittlerweile limitiert. Auch wenn die Platten schneller die Daten liefern können, geht es nicht schneller. Durch die Anhebung der PCI-Bus Frequenz wird normalerweise die Bandbreite des Busses erhöht (in der Theorie sowie in der Praxis) und somit sollte auch die Übertragungsrate der Platten automatisch höher sein (wegen der höheren Bandbreite des Busses und der überschüssigen Leistung des Arrays). Das hat erst mal nichts damit zu tun, ob der Controller dabei übertaktet wird oder nicht. Wenn die Bandbreite erhöht wird und der Plattenverbund schneller könnte als der PCI-Bus im Stande ist Daten zu liefern, MUSS auch die Transferrate des RAID-0 dabei ansteigen (wohl gemerkt, mit Annahme, dass der Controller nicht übertaktet ist)! Geschieht dies nicht, bleibt als einzige logische Schlussfolgerung die Tatsache, dass der PCI-Bus gar nicht übertaktet ist (auch wenn im BIOS die jeweiligen Einstellungen vorgenommen wurden), was wiederum meine Vermutung bezüglich des BIOS-Bugs bekräftigt.
Andernfalls, wenn das Array nicht am Limit des PCI-Busses kratzt und du den Takt des Busses anhebst und angenommen der SATA-Controller wird dabei auch übertaktet, bedeutet das ja noch lange nicht, dass die Festplattenleistung auch ansteigen wird. Die Leistung von Festplatten wird immer noch von ihrer Mechanik bestimmt. Nur durch die Anhebung einer Bandbreite (ob nun die des PCI-Busses oder die der SATA-Scnittstelle ist dabei egal) werden Festplatten nicht schneller. Dadurch drehen sie nicht schneller. Haben also keine höhere mechanische Transferrate und auch die Zugriffszeit wird nicht besser. Die mechanische Leistung bleibt also in jedem Fall gleich.
Edit:
Und bedenke, PRO KANAL steht denn Platten eine Bandbreite, je nach Übertragungsprotokoll, von 100, 133 oder 150 MB/s (abzüglich Overhead) zur Verfügung. Hängen die Platten an verschiedenen Kabeln stehen dem Array von Seiten des Controllers also 200, 266 oder 300 MB/s Bandbreite (bei zwei Platten) zur Verfügung. Die jeweiligen Bandbreitenangaben beziehen sich immer nur auf einen Kanal. Werden diese, wie es bei einem RAID-0 geschieht, gekoppelt, verdoppelt sich die theoretische Bandbreite (bei zwei Kanälen) der Schnittstelle. Da die beiden Platten in unserem Beispiel zur Datenübertragung voneinander unabhängige Kanäle benutzen.
Zuletzt bearbeitet:
Zidane schrieb:
Die Belastung des PCI-Busses durch RAID0 habe ich jetzt, wo ich eine SAT-Karte in mein System eingebaut habe, bitterbös gespürt. In zusammenhang mit RAID0, ist es bald unmöglich die SAT-Karte einwandfrei einzusetzen. Ständige Rückler in Bild und Ton (zumindest mit HDTV) verderben einem den Spaß vollkommen. Die Aufnahme gelingt überhaupt nicht... Erst als ich die Auslagerungsdatei vom RAID0 auf eine andere Festplatte gelegt habe, hat sich der Zustand dramatisch verbessert.
Madnex schrieb:
loores hat es ganz oben im Thread mal ähnlich ausgedrückt wie ich, dass die internen Timings dafür zuständig sind, dass sich der SATA-Controller so verhält. Jedoch kann dies nicht zutreffen, da die Timings im höchsten Falle die Bandbreite stark limitieren könnten, aber nicht vollkommen senken auf ein immer gleichbleibendes Niveau. Wenn aber die interne Taktrate immer 33 MHz behalten würde, dann würde die Bandbreite immer gleich bleiben, egal ob außen ein erhöhter PCI-Takt herrschen würde. Denn wie sollte sich die Bandbreite ändern, wenn der eigentliche Baustein (in diesem Falle der SATA-Controller) die Erhöhung der Bandbreite nicht wahrnehmen könnte?
Madnex schrieb:
Oben habe ich es schon mal anhand eines eigenen Tests bewiesen dass die Änderung der MHz-Zahl im BIOS von 33 MHz auf einen höheren Wert sehr wohl etwas bewirkt. Also kann hier kein BIOS-bug vorliegen...
Dekal schrieb:
Madnex schrieb:
Also werde ich dann in Zukunft meine SATA-Festplatte einfach direkt an den PCI-Bus stöpseln. Ich werde mir eine entsprechende Steckverbindung dafür zusammenbasteln... Ne das ist Unsinn. Es geht nicht ohne SATA-Controller. Ohne diesen wäre die Festplatte zu rein garnichts in der Lage. Sie ist vollkommen abhängig von ihm und seiner Bandbreite. Deshalb ist es unbedingt erforderlich, dass der SATA-Controller für eine höhere Bandbreite vorbereitet werden muss, damit die Platten mehr Daten pro Sekunde übertragen können. Mit anderen Worten: Ohne dass der SATA-Controller übertaktet wird, kann garnicht mehr Bandbreite verfügbar gemacht werden, es sei denn man könnte den SATA-Controller mit anderen Mitteln als mit der Erhöhung seiner Taktrate dazu bewegen, was uns normalsterblichen Usern infolge von fehlenden Informationen über die Ansteuerung dessen nicht gelingen wird. Oder gibt es irgendwo umfangreiche Datenblätter über diesen Controller?
Madnex schrieb:
Ich gebe dir 2 Erklärungen und einen Beweis, dass es in meinem Falle sehr wohl möglich sein müsste:
Betrachte dir diesen Bild vom Festplatten Sammelthread:
http://www.forumdeluxx.de/gallery/data/500/65282x_Hitachi_Deskstar7K250_HDS722580VLAS80_11_SATA-Raid-0_16k_Sil3112_PCI_SATA-150_Riverna.jpg
Und dann betrachte dir mein Bild:
http://www.forumdeluxx.de/forum/attachment.php?attachmentid=6210&stc=1
Hier sieht man schön, dass mit dem gleichen RAID0-Verbund eine höhere Bandbreite möglich wäre. Die 2 Erklärung hängt mit der ersten zusammen, und sie erkennt man, wenn man die 2 Bilder vergleicht. Guckt man sich die Übertragungsrate (Burst Read Speed) von beiden Konstellationen an, so erkennt man, dass die des anderen Systems meiner überlegen ist. Wäre dieser Test mit der Funktion "long bench" gemacht worden, so würde man zudem erkennen, dass die Übertragungsrate im Vergleich zu meiner, ab ca. 30GB abwärts höher ist. Zudem ist die Mittlere Übertragungsrate höher. Auch wenn dies nur geringe Unterschiede sind, aber es sind welche, die sich ausschließlich auf unterschiedliche Systeme zurückführen lassen, nicht aber auf eine Optimierung an den Einstellungen. Die Einstellungen (sprich Stripe Size oder das verwendete Dateisystem) verändern an der durch HDTach gemessenen Übertragungsrate rein garnichts. Hier spielt nur die reine Hardwarebandbreite eine Rolle. Die Festplatten hingegen sind die gleichen. Hieran sieht man, dass die Festplatten im RAID0-Verbund in meinem Sytem sehr wohl dazu in der Lage wären, eine höhere Übertragungsrate zu erzeugen, vermutlich eine enorm höhere. Da die Festplatten des folgenden Systems ähnlich sind, schätze ich die maximale Datenrate so ein wie auf diesem Bild:
http://www.forumdeluxx.de/gallery/data/500/65282x_Hitachi_Deskstar7K250_HDS722580VLSA80_10_SATA-Raid-0_128k_IntelICH5R_SATA-150_SpookyTW.jpg
Hier wäre die mittlere Übertragungsrate auch höher gewesen, wenn im unteren Festplattenbereich die Daten einwandfrei transferiert worden wären.
Z
Zidane
Guest
Der Test ist doch simpel,
man nehme eine Platine wo ein S-ATA-Controller in Form eines Sil-3112 vorhanden ist, muß aber am PCI angebunden sein. Dann nehme man als Gegentest eine PCI-Steckkarte mit dem gleichen Chipsatz und mißt dann halt einfach direkt am Slot nach, und dann den On-Board Chip vom Board. Übertakte den Rechner und mißt nochmal. Als Zusatz kann man noch eine Karte verbauen, wo man weiß das diese so bei mehr als 33 Mhz abkackt, z.b eine Tekram DC 310 SCSI-Controller. Oder man hast das Glück das die PCI-Sil Karte recht schnell schlapp macht, wenn ja und es On-Board laufen wurde, bestätigt dies das der Sil-Chip On-Board nicht übertaktet wird. Käme man sicherlich noch nen Stück weiter.
man nehme eine Platine wo ein S-ATA-Controller in Form eines Sil-3112 vorhanden ist, muß aber am PCI angebunden sein. Dann nehme man als Gegentest eine PCI-Steckkarte mit dem gleichen Chipsatz und mißt dann halt einfach direkt am Slot nach, und dann den On-Board Chip vom Board. Übertakte den Rechner und mißt nochmal. Als Zusatz kann man noch eine Karte verbauen, wo man weiß das diese so bei mehr als 33 Mhz abkackt, z.b eine Tekram DC 310 SCSI-Controller. Oder man hast das Glück das die PCI-Sil Karte recht schnell schlapp macht, wenn ja und es On-Board laufen wurde, bestätigt dies das der Sil-Chip On-Board nicht übertaktet wird. Käme man sicherlich noch nen Stück weiter.
Radical_53
[printed]-Redakteur
Schade irgendwie daß hier nix mehr zum Thema an sich kommt...
"Welche Platte für Raid 0"...
Wäre halt echt nochmal interessant, da ein paar aktuelle Modelle mit ihren Zuwachsraten im Raid 0 zu sehen...
"Welche Platte für Raid 0"...
Wäre halt echt nochmal interessant, da ein paar aktuelle Modelle mit ihren Zuwachsraten im Raid 0 zu sehen...
Zidane, den Test kann ich leider nicht machen, da mir die nötigen Mittel (Sil3112 in Form einer PCI-Steckkarte) fehlen. Aber vielleicht hat ja jmd anderes die Möglichkeit dazu dies zu testen.
Ich muss allerdings darauf hinweisen, dass wenn der Controller auf der Steckkarte genauso aufgebaut ist wie der Onboard-Controller, dass dann auch mit der PCI-Steckkarte keine Erhöhung der Bandbreite möglich wäre. Dies ist hoffentlich jedem einleuchtend.
Radical_53, es ist glaube ich sowieso ziemlich egal, welche Festplatte man einsetzt für den RAID0-Betrieb. Das hat oben in diesem Thread schonmal jmd. versucht zu erklären. Jedoch errinnere ich mich daran, dass damals bestimmte Festplattenmodelle nicht geeignet waren für einen RAID-Betrieb. Bei den Modellen lag die Datenrate dann nicht bei fast 100% im RAID0-Betrieb. Ich glaube es waren ein paar Modelle der älteren Maxtor-Generation. Aber warum das so war, das ist mir bis heute auch ein Rätsel...
Ich muss allerdings darauf hinweisen, dass wenn der Controller auf der Steckkarte genauso aufgebaut ist wie der Onboard-Controller, dass dann auch mit der PCI-Steckkarte keine Erhöhung der Bandbreite möglich wäre. Dies ist hoffentlich jedem einleuchtend.
Radical_53, es ist glaube ich sowieso ziemlich egal, welche Festplatte man einsetzt für den RAID0-Betrieb. Das hat oben in diesem Thread schonmal jmd. versucht zu erklären. Jedoch errinnere ich mich daran, dass damals bestimmte Festplattenmodelle nicht geeignet waren für einen RAID-Betrieb. Bei den Modellen lag die Datenrate dann nicht bei fast 100% im RAID0-Betrieb. Ich glaube es waren ein paar Modelle der älteren Maxtor-Generation. Aber warum das so war, das ist mir bis heute auch ein Rätsel...
Z
Zidane
Guest
Die Karte währe aber direkt mit dem PCI-Slot verbunden, mag sein das zwischen dem PCI-BUS und den Chip-On-Board was zwischenhängt, oder sind die direkt miteinander verbunden, ohne Brücken etc.
@Zidane, Dekal
1.) Ein Sil3112A kann nur über den PCI angeschlossen werden.
2.) Ob der IC direkt auf dem Mainboard oder auf einer Steckkarte sitzt, ist nicht entscheidend, da beide letzlich am PCI hängen. Da hängt nichts "dazwischen".
cu
loores
1.) Ein Sil3112A kann nur über den PCI angeschlossen werden.
2.) Ob der IC direkt auf dem Mainboard oder auf einer Steckkarte sitzt, ist nicht entscheidend, da beide letzlich am PCI hängen. Da hängt nichts "dazwischen".
cu
loores
Radical_53
[printed]-Redakteur
@dekal: Ich hab leider schon genug Modelle gehabt, wo's im Raid eben bescheiden lief.
Maxtor war's nicht, sondern Seagate. IBM/Hitachi laufen immer gut, aber was genau war mit WD, Samsung? Keine Idee...
Ich such halt grad wieder neue Platten, drum wär's so interessant.
Maxtor war's nicht, sondern Seagate. IBM/Hitachi laufen immer gut, aber was genau war mit WD, Samsung? Keine Idee...
Ich such halt grad wieder neue Platten, drum wär's so interessant.
loores schrieb:
Es stellt sich hierbei nicht die Frage, ob etwas zwischen dem PCI-Bus und dem Sil3112 hängt, sondern ob die PCI-Steckkarte genauso aufgebaut ist wie der Onboard-Device Sil3112. Wenn dem so ist, und wenn meine Vermutung, dass der PLL-Chip eine frequenzstabilisierende Wirkung auf den Sil3112 hat (was bisher noch keiner dementieren konnte), dann ist eine PCI-Karte mit Sil3112 genauso wenig in der Lage Übertaktungen wirkungsvoll auszunutzen wie der Onboard-Device.
Das wollte ich damit sagen. Und das zwischen Sil3112 und PCI-Bus etwas dazwischen hängt, habe ich so nie behauptet.
@Radical_53: Du wirst es ja am besten wissen wenn du dich schon länger mit RAID beschäftigt hast.