Welche Festplatte für Raid0?

[SilverWizard]

gab es hier nicht 2 leute die mal mit 2 platten die performance im raid0 testen wollten ?

 

[Dekal]

Ja, einer davon bin ich... Bin mitten dabei.

 

[SilverWizard]

ok sehr schön, ein kleiner zwischenbericht wäre wünschenswert, sofern du zeit hast
also jetzt keine ergebnisse verraten, aber wie du vorgehst, welches setup usw.

 

[kimble]

Diese Platten im Verbund gehen bestimmt sehr gut ab

Klick mich

 

[SilverWizard]

ja sicher, die sind aber auch sehr preiswert

 

[Dekal]

ok sehr schön, ein kleiner zwischenbericht wäre wünschenswert, sofern du zeit hast
also jetzt keine ergebnisse verraten, aber wie du vorgehst, welches setup usw.

Abwarten und Tee trinken. Hier gibts doch noch garnix zu sagen.

 

[Dekal]

Ich habe da gleich (eigentlich noch einmal) die Frage, warum der Silicon Image Controller mit dem ich getestet habe, ca. bei 28 GB auf 112 MB/s ausbremst. Ich habe gedacht der Controller sei ziemlich gut? Soll hier schon der PCI-Bus als limitierender Faktor in Erscheinung treten?

Man sieht das sehr schön hieran:

http://www.forumdeluxx.de/forum/attachment.php?attachmentid=6210

Auch das Ändern der Stripe-Size oder ein anderes Dateisystem ändert nichts.

 

[SilverWizard]

ja so siehts aus, der pci-bus is da schon am ende

 

[Radical_53]

Hab übrigens mal ne Mail von Maxtor bekommen.

Laut denen ist keine Inkompatibilität mit den DM10 zum NForce 3 bekannt. Kann man jetzt von halten, was man will.

 

[Madnex]

@Dekal
So ist es, der PCI-Bus blockiert hier bereits. Theoretisch können über den PCI-Bus maximal 133 MB/s übertragen werden. Hier muss man allerdings noch einen gewissen Protokoll-Overhead abziehen. Weshalb nicht viel mehr als ca. 110 MB/s übrig bleiben, was sich je nach Güte des Mainboardchipsatzes auch nach unten hin korrigieren kann.

 

[Dekal]

@Dekal
So ist es, der PCI-Bus blockiert hier bereits. Theoretisch können über den PCI-Bus maximal 133 MB/s übertragen werden. Hier muss man allerdings noch einen gewissen Protokoll-Overhead abziehen. Weshalb nicht viel mehr als ca. 110 MB/s übrig bleiben, was sich je nach Güte des Mainboardchipsatzes auch nach unten hin korrigieren kann.

Meines Wissens nach sind es theoretische 132 MB/s.
Aber ich dachte der Silicon Image sei so gut dass er mehr schaffe... Wenn man genau überlegt, dann fragt man sich nur wie.

 

[Dekal]

32bit / 8 = 4 Bytes * 33 MHz = 132 MB/s grrrrrrrrrrrrrrrrrrrrrrr kommt nicht mehr bei raus *aufreg*

Edit: Wieso kann man eigentlich nicht mit dem Übertakten des PCI-Buses von 33 MHz auf sagen wir 40 MHz eine erhöhte Bandbreite beim Übertragen von Daten von und zum IDE/SATA-Controller erlangen?! Das ist mir bis zum jetzigen Zeitpunkt ein Rätsel!

 

[Jammer]

Meines Wissens nach sind es theoretische 132 MB/s.
Aber ich dachte der Silicon Image sei so gut dass er mehr schaffe... Wenn man genau überlegt, dann fragt man sich nur wie.

der si ist ja auch gut nur wie soll er mehr bringen wenn ned nehr geht ! wenn er durch den pci bus ned beschrängt wäre würde er bestimmt mehr liefern können

spz

 

[Dekal]

der si ist ja auch gut nur wie soll er mehr bringen wenn ned nehr geht ! wenn er durch den pci bus ned beschrängt wäre würde er bestimmt mehr liefern können

spz

Richtig!! 100 Punkte

 

[Madnex]

Du hast bei der Taktfrequenz die Nachkommastellen vergessen. Ersetze 33 MHz durch 33,33~ (Periode) und du kommst auf 133,33~ MB/s.

Es sollte durchaus durch Übertakten des PCI-Busses eine höhere Bandbreite drin sein. Eine Übertaktung des PCI-Busses ist allerdings im Grunde nur durch Erhöhung des FSB möglich. Und dadurch werden eine Reihe andere Busse mitübertaktet. Unter anderem auch die ATA-Schnittstelle und damit auch die in den Festplatten integrierten Controller, was zu Datenverlust oder zum Verlust des gesamten Laufwerks führen kann. Daher ist diese Übertaktung nicht gerade ungefährlich.

 

[Dekal]

Du hast bei der Taktfrequenz die Nachkommastellen vergessen. Ersetze 33 MHz durch 33,33~ (Periode) und du kommst auf 133,33~ MB/s.

Es sollte durchaus durch Übertakten des PCI-Busses eine höhere Bandbreite drin sein. Eine Übertaktung des PCI-Busses ist allerdings im Grunde nur durch Erhöhung des FSB möglich. Und dadurch werden eine Reihe andere Busse mitübertaktet. Unter anderem auch die ATA-Schnittstelle und damit auch die in den Festplatten integrierten Controller, was zu Datenverlust oder zum Verlust des gesamten Laufwerks führen kann. Daher ist diese Übertaktung nicht gerade ungefährlich.

Ok, aber wenn man vom realistichen Normalfall ausgeht, dann sind normalerweise keine glatten 33,33~ MHz mehr drin, sondern an die 34 MHz. Und dann sind es schon wieder mehr MB/s an Bandbreite.
Zu der Aussage dass das Übertakten des PCI-Buses für mehr Bandbreite sorgen soll, kann ich nur sagen, es ist vollkommen egal wieviele MHz ich bei dem PCI-Takt einstelle, die Bandbreite des Festplattencontrollers bleibt haargenau gleich. Das habe ich alles schon einmal getestet. Ich wüsste nur zu gerne einen Grund dafür. Meine Theorie ist, dass der SATA-Controller nicht gleichgeschaltet ist mit dem Clock-Generator des PCI-Buses. Eine andere Erklärung finde ich nicht.... Diese Theorie & Testergebnisse betreffen allerdings NUR den nForce2 Ultra 400 auf dem Abit AN7. Vielleicht verhält es sich ja bei einem MainboPCI-Taktrate ard mit VIA-Chipsatz anders.

Edit: Die höhere kommt natürlich auch nur bei Mainboards zustande, die nicht asynchron zum FSB getaktet werden können, sprich VIA ist wohl das bekannteste Beispiel. Bei Mainboards mit nForce-Chipsatz ist das wieder anders. Da weiß ich nicht Bescheid ob es 33,00 MHz oder 33,33~ MHz sind.

 

[Madnex]

Glatte 33,33 oder 33 MHz sind es nie. Aber die Berechnungsgrundlage zur Bandbreite basiert auf 33,33~ MHz.

es ist vollkommen egal wieviele MHz ich bei dem PCI-Takt einstelle

Kannst du im BIOS den PCI-Takt direkt beeinflussen? Wenn dem so ist, könnte es möglich sein, dass es sich um ein BIOS-Bug handelt. Denn nicht jede Einstellung die man dort vornimmt wird auch so umgesetzt. Möglich also, dass das Board diese Takterhöhung einfach ignoriert.

Edit: Die höhere kommt natürlich auch nur bei Mainboards zustande, die nicht asynchron zum FSB getaktet werden können, sprich VIA ist wohl das bekannteste Beispiel. Bei Mainboards mit nForce-Chipsatz ist das wieder anders. Da weiß ich nicht Bescheid ob es 33,00 MHz oder 33,33~ MHz sind.

Du meinst wohl Board bzw. Chipsätze, die über keinen PCI/AGP-Fix verfügen. Das hat erst mal nichts mit asynchroner oder synchroner Taktung zu tun. Der PCI-Bus ist immer asynchron zum FSB getaktet.

 

[Dekal]

Glatte 33,33 oder 33 MHz sind es nie. Aber die Berechnungsgrundlage zur Bandbreite basiert auf 33,33~ MHz.

Da habe ich vor einiger Zeit aber was anderes gelesen. Es wurde immer von 132 MB/s für die maximale Übertragungsrate des PCI-Buses geschrieben. Das habe ich mir nicht erfunden. Nur für den IDE-Controller galt 133 MB/s.

Kannst du im BIOS den PCI-Takt direkt beeinflussen? Wenn dem so ist, könnte es möglich sein, dass es sich um ein BIOS-Bug handelt. Denn nicht jede Einstellung die man dort vornimmt wird auch so umgesetzt. Möglich also, dass das Board diese Takterhöhung einfach ignoriert.

Natürlich kann ich das. Kennst du etwa nicht die schönen Mainboards die ideal zum Übertakten geeignet sind (Abit AN7 und die Abit NF7-Reihe)? Das ist kein Bug. Man kann in deren BIOS fast sämtliche auf dem Markt verfügbare Einstellungen vornehmen, die die Performance eines PC-Systems beeinflussen. Deshalb habe ich mir dieses Board doch gekauft.

Du meinst wohl Board bzw. Chipsätze, die über keinen PCI/AGP-Fix verfügen.

Ja das meine ich.

Das hat erst mal nichts mit asynchroner oder synchroner Taktung zu tun. Der PCI-Bus ist immer asynchron zum FSB getaktet.

Das stimmt nicht ganz. Der PCI/AGP-Takt bei einem VIA-Chipsatz ist immer abhängig vom FSB und ist deshalb synchronisiert im Teiler von 1/2 für den AGP-Takt bzw. 1/4 für den PCI-Takt.

 

[wuggu@work]

Hallo,

ein Paar Facts vorweg: das Laden von Programmen etc. hängt hauptsächlich von der realen Zugriffszeit der Festplatte ab (siehe C'T Benchmarks), und hier bringt U/Min deutlich mehr als MB/s, sprich: Ein Raid0 bringt zwischen 5% (meßbar) und 20% (kleiner Unterschied spürbar) je nachdem wie hoch der Ladeaufwand ist.
Anders sieht es beim Laden, Kopieren und Verarbeiten von Daten aus: Je größer die Dateien sind, desto größer ist der Vorteil von Raid0. Deswegen sollten vor allem Daten mit einer Größe >10MB auf Raidlaufwerken abgelegt werden. Sobald größere Daten am Stück gelesen werden sinkt der Einfluss der Zugriffszeiten. Jedes Laufwerk kann aber nur so schnell arbeiten wie der Empfänger die Daten entgegen nimmt. Ein "copy" richtung "/dev/null" geht sehr schnell, ebenso wie das Laden von Daten in den Speicher, bei nem Raid0 aus 2 Festplatten muss der Empfänger schon deutlich schneller sein um die Geschwindigkeit optimal ausnutzen zu können.
Eine optimale Umgebung wäre Windows + Programme in einer Ram-Disk (4 GB SSD z.b.) und alle aktuellen Daten auf einem Raid0. Die Daten sollten in 3 voneinander unabhängigen Generationen gesichert werden, denn damit steigt die Datensicherheit stark an.

Soviel zum theoretischen Teil. Viel hängt beim PC von der persönlichen Einstellung ab. Ein Kumpel von mir arbeitet seit fast 5 Jahren mit einem Duron 800 und einer IBM 8 GB Festplatte und macht mit seinem PC alles was jeder andere auch machen würde (ausser zocken). Sein Bekannter wartet ungeduldig auf die Verfügbarkeit des Athlon FX-55, weil ihm sein FX-51 zu langsam geworden ist und seiner Meinung nach nicht mehr zeitgemäss ist. Die Diskussion über Sinn und Unsinn solcher Haltungen lohnt sich nicht. Ich persönlich finde beide Haltungen extrem, denn der Duron schneckt bei größeren Dokumenten vor sich hin (auch mit 512MB Speicher) und der FX51 ist immer noch einer der schnellsten Prozessoren die es am Markt gibt. Wenn wir aber danach gehen würden was wir brauchen würde jeder von uns das gleiche Auto fahren und jeder mit einem 2 GHz Athlon / P4 arbeiten, denn der ist nicht zu schnell und nicht zu langsam. Aber dann wären die Computerfirmen die den Home-Bereich versorgen schnell arbeitslos und die Preise würden extrem steigen. Deswegen: Jeder soll seinen PC so sehr hochrüsten bis er glücklich ist und sich keine Gedanken darüber machen ob irgendwer glaubt dass die Investition sich nicht gelohnt hat => wenn man selbst zufrieden ist, hat man doch gewonnen.

Zu der eingangs gestellten Frage, welche Platten sich für Raid0 eignen: es ist die gleiche Frage ob sich der blaue Audi besser zum überholen eignet als der grüne => du kannst jede Festplatte in ein Raid0 packen, keine Festplatte wird durch ein Raid0 im Datendurchsatz langsamer. Die 7k250 ist eine aktuelle Festplatte und eignet sich genau so gut wie die Samsung SP1604N und die Seagate Barracuda 7 - Serie für Raid0. Denk aber wie oben geschrieben an die Datensicherung, denn jede Festplatte fällt irgendwann aus, und das hat nichts mit Qualität zu tun sondern einfach damit dass mechanische Teile einfach kaputt gehen, erst recht wenn sie wartungsfrei sind.

Gruß
w@w

 

[Madnex]

Da habe ich vor einiger Zeit aber was anderes gelesen. Es wurde immer von 132 MB/s für die maximale Übertragungsrate des PCI-Buses geschrieben. Das habe ich mir nicht erfunden. Nur für den IDE-Controller galt 133 MB/s.

Es ist doch absolut egal ob nun 132 MB/s oder 133 MB/s. Das ist gehüpft wie gesprungen. Beide Angaben zur maximalen Bandbreite des PCI-Busses sind im Umlauf. Was soll also diese Haarspalterei?

Natürlich kann ich das. Kennst du etwa nicht die schönen Mainboards die ideal zum Übertakten geeignet sind (Abit AN7 und die Abit NF7-Reihe)? Das ist kein Bug. Man kann in deren BIOS fast sämtliche auf dem Markt verfügbare Einstellungen vornehmen, die die Performance eines PC-Systems beeinflussen. Deshalb habe ich mir dieses Board doch gekauft.

Du hast mich nicht richtig verstanden. Ich meinte, dass diese Funktion zwar vorhanden aber fehlerhaft implementiert wurde. Sodass die Einstellung nicht übernommen wird, auch wenn das BIOS dir was anderes sagt (kommt gar nicht so selten vor). Das habe ich als Bug bezeichnet und nicht die Einstellungsmöglichkeit ansich.

Das stimmt nicht ganz. Der PCI/AGP-Takt bei einem VIA-Chipsatz ist immer abhängig vom FSB und ist deshalb synchronisiert im Teiler von 1/2 für den AGP-Takt bzw. 1/4 für den PCI-Takt.

Beispielsweise arbeiten Speicherbus und FSB synchron, wenn sie mit der selben Taktfrequenz (also 1:1) betrieben werden. Wenn der Speicher mit z.B. 140 MHz und der FSB mit 133 MHz läuft, so ist das ein asynchroner Betrieb. Wird hingegen der Speicher mit 66 MHz betrieben (Achtung: Beispiel!) und der FSB mit 133 MHz (es kommt also ein Teiler ins Spiel), so spricht man von einer pseudosynchronen Taktung. PCI-Bus und FSB arbeiten also NICHT synchron. Allerdings hatte ich es auch falsche. Die richtige Bezeichnung dafür ist pseudosynchron.

 

[Dekal]

Es ist doch absolut egal ob nun 132 MB/s oder 133 MB/s. Das ist gehüpft wie gesprungen. Beide Angaben zur maximalen Bandbreite des PCI-Busses sind im Umlauf. Was soll also diese Haarspalterei?

Gegenfrage: Wieso regst du dich so auf?

Du hast mich nicht richtig verstanden. Ich meinte, dass diese Funktion zwar vorhanden aber fehlerhaft implementiert wurde. Sodass die Einstellung nicht übernommen wird, auch wenn das BIOS dir was anderes sagt (kommt gar nicht so selten vor). Das habe ich als Bug bezeichnet und nicht die Einstellungsmöglichkeit ansich.

Stimmt nicht. Hieran stelle ich fest, dass du auch immer schnell dabei bist dir irgendwas "einzubilden", so wie ich . Ich habe einen erfahrenen Menschen zu dieser Angelegenheit befragt, der eine eigene sehr beliebte Webseite betreibt. Er hat meine Annahme bestätigt. Der SATA-Controller wird also mit einem eignen Clock-Generator betrieben.

Beispielsweise arbeiten Speicherbus und FSB synchron, wenn sie mit der selben Taktfrequenz (also 1:1) betrieben werden. Wenn der Speicher mit z.B. 140 MHz und der FSB mit 133 MHz läuft, so ist das ein asynchroner Betrieb. Wird hingegen der Speicher mit 66 MHz betrieben (Achtung: Beispiel!) und der FSB mit 133 MHz (es kommt also ein Teiler ins Spiel), so spricht man von einer pseudosynchronen Taktung. PCI-Bus und FSB arbeiten also NICHT synchron. Allerdings hatte ich es auch falsche. Die richtige Bezeichnung dafür ist pseudosynchron.

Wollen wir hierbei also weiterhin Haarspalterei betreiben? Nennen wir es wie wir es wollen. Wir wissen aber beide was wir meinen. Also lassen wir das Thema doch einfach. Der eine mag es "synchron im Teiler zu" nennen der andere eben pseudosynchron. Der fachmänniche Ausdruck hierfür ist pseudosynchron, das habe ich nun auch nicht das erste mal gehört. Darum sollte es uns beiden aber auch nicht gehen.

Und nur so nebenbei bemerkt ist deine Sichtweise, wuggu@work, garnicht schlecht. Aber da wir Menschen sind, die schnell dabei sind die Vergangenheit und die Zukunft eindeutig hinter die Gegenwart zu stellen, kommt diese eigentlich soooooooo sinnlose Diskussion zustande. Da bestätigt sich wieder einmal die Annahme eines Wissenschaftlers, dass nur das JETZT existiert und wir im JETZT leben und nicht in der Vergangenheit oder Zukunft.

 

[loores]

@Dekal

(...) Zu der Aussage dass das Übertakten des PCI-Buses für mehr Bandbreite sorgen soll, kann ich nur sagen, es ist vollkommen egal wieviele MHz ich bei dem PCI-Takt einstelle, die Bandbreite des Festplattencontrollers bleibt haargenau gleich. Das habe ich alles schon einmal getestet. (...)

1. Nur weil der SATA-IC (i.d.F. mit PCI-Anbindung) übertaktet wird, heisst nicht, dass er mehr Leistung bringt. Du hast den Chip übertaktet, was aber an seinem internen Timing nichts verändert. Es wurde schon vor Jahren versucht, die Bandbreite von PCI, AGP, IDE etc. durch übertakten zu verbesseren. Die Ergebnisse waren selten befriedigend.

2. Wie hast du die "Bandbreite des Festplattenkontrollers" gemessen?

cu
loores

 

[Dekal]

@Dekal


1. Nur weil der SATA-IC (i.d.F. mit PCI-Anbindung) übertaktet wird, heisst nicht, dass er mehr Leistung bringt. Du hast den Chip übertaktet, was aber an seinem internen Timing nichts verändert. Es wurde schon vor Jahren versucht, die Bandbreite von PCI, AGP, IDE etc. durch übertakten zu verbesseren. Die Ergebnisse waren selten befriedigend.

Doch, genau das erreicht man dadurch, auch wenn die Ergebnisse nicht gerade befriedigend sind. Das schwächste Glied in dieser Konstellation ist nämlich der PCI-Bus (Vergleiche einfach Intel ICH mit Silicon Image SATA). Die internen Timings haben hier zwar ihre Bedeutung, können aber auf keinen Fall das Übertakten des PCI-Buses und die dadurch verbundene schnellere Abarbeitung von Befehlen Ignorieren. Das beste Beispiel hierbei ist der Arbeitsspeicher. Übertaktet man ihn nur um wenige MHz, dann bringt dies mit 100%iger Gewissheit wesentlich mehr als wenn man ein wenig an den Timings schraubt, um es mal von der anderen Seite zu betrachten. Beim AGP-Bus hingegen verhält es sich ganz anders. Hier ist zwar theoretisch bei Übertaktung des Gleichen ein Performance-Boost möglich, kann aber in fast allen Anwendungen/Spielen nicht genutzt werden, da die heutigen modernsten und schnellsten auf dem Markt befindlichen Grafikkarten das volle Potential der zur Verfügung stehenden Bandbreite des AGP-Buses bei weitem nicht ausnutzen können. Das beste Beispiel hierbei ist der AGP-Modus. War damals kaum bis gar kein Geschwindigkeitszuwachs festzustellen wenn man den Modus von 2x auf 4x angehoben hat, so verhält es sich heutzutage genauso mit dem Modus 4x im Vergleich zu 8x.

2. Wie hast du die "Bandbreite des Festplattenkontrollers" gemessen?

Wenn 2 Festplatten, die im Raid 0 arbeiten, den SATA-Controller an sein Limit bringen und somit in der Lage wären mehr zu leisten, was man mit Leichtigkeit mit HDTach 3.0.1.0 feststellen kann, dann ist es auch eine Leuchtigkeit, herauszufinden mit welchen Mitteln man den Datendurchsatz des Controllers erhöhen kann. Dazu zählt in meinem Falle einfach nicht das Anheben der PCI-Taktfrequenz!

 

[loores]

@Dekal

Doch, genau das erreicht man dadurch, auch wenn die Ergebnisse nicht gerade befriedigend sind. Das schwächste Glied in dieser Konstellation ist nämlich der PCI-Bus (Vergleiche einfach Intel ICH mit Silicon Image SATA). Die internen Timings haben hier zwar ihre Bedeutung, können aber auf keinen Fall das Übertakten des PCI-Buses und die dadurch verbundene schnellere Abarbeitung von Befehlen Ignorieren. (...)

1.) Mir ist die Problematik der Performance des PCI durchwegs bewusst. Nicht zuletzt deshalb fordere ich bereits seit 1997 einen Nachfolger für PCI. Die letzten drei bis vier Jahre stand ich mit dieser Forderung ziemlich alleine da. Nun ist der Nachfolger endlich da und alle sagen ja.1

2.) Dass der PCI das schwächste Glied ist, stimmt soweit. Ich vermute, du willst mir damit sagen, dass du darum versucht hast den PCI zu tunen, weil damit am meisten erreicht werden kann.

3.) Die Problematik betr. wie bereits gesagt die internen Timings des SATA-Kontrollers. Ein solcher Kontroller ist eine komplexe Angelegenheit und der Glauben einfach den Takt zu verändern um die Performance zu verbessern zeugt nicht von grossem Verständnis für die Technik.

Um auf die Analogie mit dem Speicher zurückzukommen: Wenn man den Speicher ja so einfach übertakten kann, warum hat es dann solange gedauert, bis zuerst PC133, dann PC266 und zuletzt PC400 stabil liefen? Das alles war ein langwieriger Prozess. Mit einem simplen Anheben des Taktes ist es nicht getan. Die Terminierung muss stimmen, der Spannung etc. Ich bin nach wie vor der Meinung, dass du deinen SATA-IC zwar übertaktet hast, es aber so gut wie nichts gebracht hat.

4.) Wenn also der SATA-Chip auf deinem nForce2 einen eigenen Clock-Gen hat, kannst du mir dann bitte den entsprechenden Baustein zeigen? Ich weiss nicht, wo der auf dem Board verbaut ist. Es macht in meinen Augen schon betriebswirtschaftlich keinen Sinn, einen zusätzlichen Clock-Gen einzubauen. Mit unterschiedlichen Clock-Gens handelt man sich auch immer wieder Probleme ein. Aus diesem Grund wird normalerweise nur einer verbaut und es wird mit Teilern gearbeitet. Das zeigt die ganze Geschichte mit dem AGP/PCI-Fix.

cu
loores

 

[Dekal]

3.) Die Problematik betr. wie bereits gesagt die internen Timings des SATA-Kontrollers. Ein solcher Kontroller ist eine komplexe Angelegenheit und der Glauben einfach den Takt zu verändern um die Performance zu verbessern zeugt nicht von grossem Verständnis für die Technik.

Von welchen Timings reden wir denn hier?
Wenn du der Meinung bist, dass ich mit meiner Annahme, die Erhöhung des PCI-Taktes führe zu einer höheren Bandbreite falsch liege, dann würde ich einfach ganz gerne mal eine Begründung von dir hören, wieso dies nicht der Fall sein sollte. Ich bin immer offen für neues Wissen.

Um auf die Analogie mit dem Speicher zurückzukommen: Wenn man den Speicher ja so einfach übertakten kann, warum hat es dann solange gedauert, bis zuerst PC133, dann PC266 und zuletzt PC400 stabil liefen? Das alles war ein langwieriger Prozess. Mit einem simplen Anheben des Taktes ist es nicht getan. Die Terminierung muss stimmen, der Spannung etc. Ich bin nach wie vor der Meinung, dass du deinen SATA-IC zwar übertaktet hast, es aber so gut wie nichts gebracht hat.

Ich habe nie anderes behauptet. Dennoch ist es Fakt, dass eine höhere Taktung mehr bringt als schärfere Timings, sowahr die Hardware mitspielt.

4.) Wenn also der SATA-Chip auf deinem nForce2 einen eigenen Clock-Gen hat, kannst du mir dann bitte den entsprechenden Baustein zeigen? Ich weiss nicht, wo der auf dem Board verbaut ist. Es macht in meinen Augen schon betriebswirtschaftlich keinen Sinn, einen zusätzlichen Clock-Gen einzubauen. Mit unterschiedlichen Clock-Gens handelt man sich auch immer wieder Probleme ein. Aus diesem Grund wird normalerweise nur einer verbaut und es wird mit Teilern gearbeitet. Das zeigt die ganze Geschichte mit dem AGP/PCI-Fix.

Warum sollte dieser auf dem Mainboard direkt verbaut sein? Vielleicht täusche ich mich, aber ich denke dass es absolut kein Problem darstellen würde, einen solchen mini-pll in den Sil 3112 unterzubringen. Dies wäre betriebswirtschaftlich auch besser.

 

[loores]

@Dekal

Von welchen Timings reden wir denn hier?
Wenn du der Meinung bist, dass ich mit meiner Annahme, die Erhöhung des PCI-Taktes führe zu einer höheren Bandbreite falsch liege, dann würde ich einfach ganz gerne mal eine Begründung von dir hören, wieso dies nicht der Fall sein sollte. Ich bin immer offen für neues Wissen.

Nur hast du ja etwas behauptet und es liegt an dir, dies zu beweisen. Es liegt danach an mir, die Unrichtigkeit deiner These zu beweisen. Du bist an der Reihe.

Warum sollte dieser auf dem Mainboard direkt verbaut sein? Vielleicht täusche ich mich, aber ich denke dass es absolut kein Problem darstellen würde, einen solchen mini-pll in den Sil 3112 unterzubringen. Dies wäre betriebswirtschaftlich auch besser.

Wobei ein PLL kein Clock-Gen ist. Ein PLL ist im Sil drin, von einem Clock-Gen hingegen ist mir nichts bekannt.

cu
loores

 

[Madnex]

Gegenfrage: Wieso regst du dich so auf?

...

Wollen wir hierbei also weiterhin Haarspalterei betreiben? Nennen wir es wie wir es wollen. Wir wissen aber beide was wir meinen. Also lassen wir das Thema doch einfach. Der eine mag es "synchron im Teiler zu" nennen der andere eben pseudosynchron. Der fachmänniche Ausdruck hierfür ist pseudosynchron, das habe ich nun auch nicht das erste mal gehört. Darum sollte es uns beiden aber auch nicht gehen.

Ich rege mich nicht auf. Ob nun die theoretische, nicht real erreichbare Bandbreites des Busses bei 132 oder 133 MB/s liegt, halte ich für unwichtig. Dadagegen für nicht unwichtig halte ich die richtige Verwendung von Begriffen. Alleine um Missverständnisse zu vermeiden. Aber du hast recht, im Grunde ist es auch Haarspalterei. Also lassen wir es doch einfach .

Stimmt nicht. Hieran stelle ich fest, dass du auch immer schnell dabei bist dir irgendwas "einzubilden", so wie ich . Ich habe einen erfahrenen Menschen zu dieser Angelegenheit befragt, der eine eigene sehr beliebte Webseite betreibt. Er hat meine Annahme bestätigt. Der SATA-Controller wird also mit einem eignen Clock-Generator betrieben.

Wenn man sich so das Blockdiagramm des auf deinem Board verbauten Silicon Image Controllers anschaut, gibt es keinen Hinweis darauf, dass dieser Chip seinen eigenen Takt erzeugen kann und somit unabhängig vom PCI-Bus wäre. Wie du richtig vermutet hast ist eine PLL integriert. Aber eine PLL ist kein eigenständiger Oszillator und braucht immer einen Referenztakt (in unserem Fall wohl die Frequenz des PCI-Busses). Eine PLL kann u.a. ein vielfaches eines Referenztaktes erzeugen, also einen pseudosynchronen Takt. Und genau das ist die Aufgabe der im Chip enthaltenen PLL. Das bedeutet allerdings auch, dass der Controller vom Bustakt abhängig ist und bei Anhebung dessen auch übertaktet wird. Einzige Möglichkeit wäre, dass ein externer Taktgeber verbaut worden ist. Aber das würde, wie es Loores auch schon gesagt hat, rein aus betriebswirtschaftlichen Gründen keinen Sinn machen. Selbst wenn das der Fall wäre, hätte Abit dieses Feature wohl direkt beworben, da es sich dabei um was Besonderes handeln würde. Aber wenn man bedenkt, dass der nForce2 den PCI-Takt fixieren, also vom FSB-Takt abkoppeln kann, ist dies doch gar nicht notwendig (aus Sicht des Herstellers).

Im Übrigen würde mich interessieren wer dieser "erfahrene Mensch" ist und welche Webseite er betreibt.

CU

 

[Dekal]

@Dekal
Nur hast du ja etwas behauptet und es liegt an dir, dies zu beweisen. Es liegt danach an mir, die Unrichtigkeit deiner These zu beweisen. Du bist an der Reihe.

Im Übrigen würde mich interessieren wer dieser "erfahrene Mensch" ist und welche Webseite er betreibt.

Der erfahrene Mensch hat sich wohl etwas dürftig ausgedrückt, was mir gleich ein Glücksgefühl verschafft hat, da ich mich mit seiner Assage bestätigt gefühlt habe. Er behauptet, dass der Clockchip einen eigenen Divider für SATA habe. Ich bin mir hierbei nicht zu Schade meine Annahme als falsch zu bezeichnen, wollte aber auch eigentlich keine Diskussion über die genauen Hintergründe enfackeln, sondern lediglich die Behauptung an den Tag bringen, dass eine Anhebung des PCI-Bustaktes keine Wirkung auf die Leistungsfähigkeit des SATA hat und zugleich von jmd. Erfahrenen eine präzise Antwort auf dieses Verhalten haben. Aber wie es aussieht, war mein erfahrener Freund der Einzige, der hier eine genaue Antwort geben konnte. :maul:
Trotzdem finde ich es gut, dass diese Diskussion zustande gekommen ist, da man nur so Erfahrungen/Wissen austauchen kann und so nur dazulernen kann.

Wobei ein PLL kein Clock-Gen ist. Ein PLL ist im Sil drin, von einem Clock-Gen hingegen ist mir nichts bekannt.

Bei empfindlichen Schaltungen ist ein PLL (Phase-Locked Loop) unabdinglich. Er ist ein sehr wichtiges Teil vom Clock-Generator. Wo ein Clock-Generator vorhanden ist, müsste in fast allen Fällen ein PLL in der Nähe sein. Im Falle des Sil3112 ist es so dass der Mainboard-Clock-Gen einen speziellen Divider für den SATA bereitstellt, der dann (das ist wieder meine Vermutung) wohl mit dem PLL zusammenarbeitet, um einen genauen Takt bereitzustellen.

Edit: Das umfangreiche Benchmarking, welches ich durchführen möchte, wird noch eine Weile andauern. Dieses verlängerte Wochenende (weil Feiertag) war ich vollends damit beschäftigt meinem Freund seine Festplatte samt Daten wieder herzurichten und war nicht in der Lage weitere Maßnahmen für das Benchmark zu ergreifen. Ausserdem sehe ich sowieso keinen Grund mehr, dieses Benchmark als Beweiß für den Sinn eines RAID0-Systems hierein zustellen, da wir alle (die immer schön mitgelesen haben) bereits verschiedene Quellen zu diesem Thema nahegelegt bekommen und erfahren haben wie sinnvoll/sinnlos RAID0 ist. Für mich ist es nach wie vor eine sinnvolle Investition.

 

[Madnex]

Er behauptet, dass der Clockchip einen eigenen Divider für SATA habe.

Das kann alleine aus dem Grund gar nicht sein, da der SATA-Adapter, der ja ein PCI-Device ist, zum einen mit der PCI-Bus Frequenz angesprochen wird (33,33 MHz) und zum anderen den SATA-Takt (1,5 GHz) erzeugen muss. Und dafür ist die PLL integriert. Eine PLL kann auch eine taktstabilisierende Funktion übernehmen, das ist richtig. Es spricht aber nichts dafür, dass das hier der Fall ist. Es wird wohl kaum ein externer Multipier benötigt um den SATA Takt zu erzeugen. Das sollte der Adapter selbst übernehmen.

Im Falle des Sil3112 ist es so dass der Mainboard-Clock-Gen einen speziellen Divider für den SATA bereitstellt

Ich möchte nur darauf hinweisen, dass der auf dem Board verbaute Mainboardchipsatz gar kein SATA vorsieht und somit gar nicht SATA berücksichtigen kann. Der Sil3112 ist ein PCI-Device und somit optional durch den Mainboardhersteller eingesetzt. Genau wie jedes andere PCI-Device (z.B. LAN, Sound, Firewire) integriert werden kann, bedeutet das aber noch lange nicht, dass jedes dieser Geräte einen eigenen Taktgeber oder Divider zur Seite gestellt bekommt. Alle diese Komponenten, genau wie richtige PCI-Steckkarten, sind abhängig vom PCI-Bus Takt. Aus diesem Grund ist im Sil die PLL-Schaltung integriert, da sie den Takt des PCI übernimmt, stabilisiert und daraus die 1.5 GHz für SATA generiert.

Aber wie es aussieht, war mein erfahrener Freund der Einzige, der hier eine genaue Antwort geben konnte.

Tatsächlich? Da bin ich irgendwie anderer Meinung. Dumm nur, dass du uns seine genaue Antwort vorenthälst. Schade ist auch, dass du uns immer noch nicht seinen Namen bzw. seine Webseite verraten hast.

 

[loores]

@Dekal

(...) Wenn du der Meinung bist, dass ich mit meiner Annahme, die Erhöhung des PCI-Taktes führe zu einer höheren Bandbreite falsch liege, dann würde ich einfach ganz gerne mal eine Begründung von dir hören, wieso dies nicht der Fall sein sollte. Ich bin immer offen für neues Wissen. (...)

Quelle: http://www.forumdeluxx.de/forum/showpost.php?p=1199272&postcount=205


ABER:

(...) sondern lediglich die Behauptung an den Tag bringen, dass eine Anhebung des PCI-Bustaktes keine Wirkung auf die Leistungsfähigkeit des SATA hat und zugleich von jmd. Erfahrenen eine präzise Antwort auf dieses Verhalten haben. Aber wie es aussieht, war mein erfahrener Freund der Einzige, der hier eine genaue Antwort geben konnte. (...)

Quelle: http://www.forumdeluxx.de/forum/showpost.php?p=1226263&postcount=208


Das überrascht mich doch etwas. Zuerst behauptest du, eine Erhöhung des Taktes würde zu einer höheren Bandbreite führen. Dazu hatte ich weiter oben geschrieben:

1. Nur weil der SATA-IC (i.d.F. mit PCI-Anbindung) übertaktet wird, heisst nicht, dass er mehr Leistung bringt. Du hast den Chip übertaktet, was aber an seinem internen Timing nichts verändert. Es wurde schon vor Jahren versucht, die Bandbreite von PCI, AGP, IDE etc. durch übertakten zu verbesseren. Die Ergebnisse waren selten befriedigend.

Quelle:
http://www.forumdeluxx.de/forum/showpost.php?p=1193787&postcount=202


Nun drehst du die ganze Argumentation plötzlich um und sprichst vom Gegenteil.

(...) Aber wie es aussieht, war mein erfahrener Freund der Einzige, der hier eine genaue Antwort geben konnte. (...)

Dieses Zitat ist ein übler Scherz, vom unpassenden Emokey mal abgesehen.

cu
loores