wie einige hier sicherlich mitgekriegt haben, habe ich mir folgendes Board ersteigert: http://cgi2.ebay.de/aw-cgi/eBayISAPI.dl ... rid=segoii
Sinn und Zweck des Boards war natürlich der vorhandene zweite Teiler, genauer gesagt der PLL16, der meine Radeon 9500PRO auch oberhalb der 157MHz FSB am Leben erhalten sollte und so meinen SL6JN richtig ausreizen sollte. Leider erfuhr ich ca. 1 Stunde vor Auktionsschluss dass es sich um ein OXET-C handelt und nicht um ein vollwertiges OXET. Dazu hatte es auch noch das Bios F7 drauf. Da die OXETs aber fast ausgestorben sind, hab ichs trotzdem genommen.
--> Bios-Update ohne DualBios und damits auch so richtig komplett wirkt hab ich das Update von WinXP aus gemacht
zum Glück gings gut. Da ich eh nur 3 Rams habe und nun wohl kein neues Bios mehr kommen wird brauch ich die Features des OXETs nicht mehr 
da reicht auch das OXET-CNach der Ganzen Umbau und Flash-Aktion bin ich erstmal direkt ins BIOS rein, hau den PLL16 rein, stell den RAM auf CL3 und den FSB auf 190. Zu meiner Verwunderung bootete das Sys. problemlos. Jedoch gab es bei der ersten 3DMARK-"Testfahrt" gleich einen Hänger. Zunächst dachte ich, dass ich meinen Infineon doch etwas überschätzt habe . Daher machte ich folgende Testläufe:
157FSB CL3 PLL16 ---> freeze
157FSB CL2 PLL16 ---> freeze
157FSB CL2 --- ---> OK!
160FSB CL2 PLL16 ---> freeze
160FSB CL2 --- ---> OK! *aber hin und wieder Grafikfehler*
162FSB CL2 PLL16 ---> freeze
162FSB CL2 --- ---> BLACK SCREEN
180FSB CL3 PLL16 ---> freeze
Obwohl ich ein OXET-C der Revision 1.02 habe, welches über einen Zusatzteiler ICS 94xxxx verfügt, sprechen die Ergebnisse für sich!
Zwar funktioniert der Zusatzteiler bzw. erfüllt seine Aufgabe, da andernfalls das Starten bei 180 bzw. 190MHz FSB mit einer R300 unmöglich gewesen wäre. Ein stabiler Betrieb ist beim Einsatz des PLLs jedoch nicht möglich.
Als Grund fielen mir zunächst Aussetzer des PLLs ein. Schließlich sind mir Freezes vorrangig als "Grafikkartenfehler" bekannt. Jedoch widerlegt das 157FSB-Ergebnis diese Theorie, da beim kurzzeitigen Ausfall des PLLs die 9500PRO den AGP-Takt verkraftet hätte ...
Um den Ram gänzlich als Fehlerquelle auszuschließen, stellte ich ihn schließlich auf CL3.
Als das System selbst bei diesen Einstellungen "einfrohr" war mir allmählich klar, dass allein der PLL für die Aussetzer verantwortlich war. Welche Komponente allerdings beim Einsatz des PLLs den freeze verursacht (CPU, Ram, GraKa oder sogar die Nb.) blieb unklar!
Ärgerlich war für mich halt, dass ich das Board gekauft hatte um mehr als die 157MHz FSB des ST6 zu erreichen. Und genau dies war nicht möglich. Bis jetzt vermute ich, dass die Aussetzer an einem Designfehler von Gigabyte à la Voodoo 5 6000 liegen.
Obwohl solche Fehler durch Softwarespielereien nicht behoben werden können, fing ich einfach mal an im Bios irgendwelche Einträge zu ändern. Nach vielleicht 25 oder 30 cmos-clears und genau 2 WinXP-Neuinstallationen (die armen HDDs
) gelangte ich zur Option "SDRAM Buffer Strength". Standardmäßig ist diese auf "auto" gestellt und die 17 darunter liegenden Einträge nicht anwählbar. Wählt man "manuell" an kann man bei den 17 Einträgen Zahlen von 0,7 bis 2,7 wählen. Je nach Menüpunkt schwanken die Minimal bzw. Maximalwerte.Zunächst stellte ich alle Werte aufs Maximum. Resultat: cmos-clear
Danach drehte ich die Prozedur um und stellte alle Werte aufs Minimum.
Dies brachte das erstaunliche Ergebnis, dass das System nun mit angewähltem PLL16 stabil lief
. Nach weiterem Herumspielen stellte sich noch heraus, dass es ausreicht die ersten beiden Einträge auf das Minimum von 0,7 (sind übrigens die einzigen Einträge, die man überhaupt auf 0,7 stellen kann ...) zu stellen. Die anderen 15 Einträge darunter haben auf die Systemstabilität unter PLL-Nutzung keinen Einfluss! Allerdings hat diese Methode auch einen Nachteil: Sie scheint den RAM enorm zu belasten. Während meine Infineons am ST6 mit der 8500 bis 168@CL2 bzw. 186@CL3 rockstable gingen, gingen sie mit der o.g. Einstellung nur bis 165@CL2 bzw. 168@CL3. Bei FSBs oberhalb von 168MHz gibt es Bluescreens mit der Meldung:"Fehler in Win32k.sys" - Abbild vom Speicher wird ausgeführt - oder so ähnlich.Desweiteren habe ich bei dieser Methode folgende Kuriosität bemerkt: DIMM-overvoltage hat NEGATIVEN Einfluss auf DIMM-oc! Stellte ich statt "norm" auf 3,4 3,5 oder 3,6V gab es Bluescreens oder stoppte das Sys. schon bei der Speicherkontrolle beim Booten
So richtig zufrieden war ich mit den 165CL2 immer noch nicht. Schließlich wollte ich irgendwas über 180, auch wenns nur auf CL3 gehen würde
Ich fand heraus, dass die Änderung auf 0,7 im ersten Eintrag für diese Kuriosität verantwortlich war. Daher spielte ich diesmal mit beiden Einträgen etwas herum:
Ich nenne den ersten Eintrag (SWE, SCAS, SRAS, SMAA, SBS) einfach mal SBS1 - für SDRAM Buffer Strength 1
Den zweiten Eintrag (SMD 63:0, SDQN 7:0) nenne ich mal SBS2.
SBS1 und SBS2@auto ---> freezes
SBS1 und SBS2@1,7 ---> NIX - cmosclear erforderlich
SBS1 und SBS2@0,7 ---> stabil, aber o.g. Nachteile
SBS1@0,7 SBS2@1,0 ---> freezes und o.g. Nachteile
SBS1@auto SBS2@0,7 ---> freezes
SBS1 und SBS2@1,0 ---> freezes
SBS1@1,0 SBS2@0,7 ---> momentan bestes Ergebnis. Bis jetzt mit
184MHz@CL3 STABIL / keine freezes -
jedoch noch nicht 100% getestet.
Obwohl die Zeit des PIII-clockings so langsam vorüber ist (angemerkt: bei mir nicht!!!), wäre es mal wirklich interessant wenn die Techniker unter euch (insbes. die OXET-Besitzer, die davon ausgegangen sind, defekte Teiler zu besitzen!) sich dem Phänomen nochmal anzunehmen.
Auf jeden Fall muss ich nochmal zum Vergleich OXET / ST6 sagen, dass selbst das OXET-C deutlich mehr bietet als das ST6. Die Bios-Einstellungen sind sinnvoller (was will ich z.B. mit Shadowing-Einstellungen) und umfangreicher (DIMM, AGP-ov., PLLs, SBS, SMART)
Zum instabilen VRM muss ich sagen, das in der Tat Warmstartprobleme ab 1,7V auftreten, mehr geht aber ohne Mod beim ST6 eh nicht. Außerdem startete meine GraKa auf dem ST6 bei 160FSB nicht mehr. Beim Gigabyte startete sie noch, verursachte aber Grafikfehler.
Guten Rutsch
sego
für diese Review! Hast dir viel Mühe beim Testen gegeben! 
Für Leute, die jedoch Teiler besitzen, die Freezes beim Einsatz verursachen, ist dieser Minimaleingriff auf jeden Fall empfehlenswert. Mehr als ein cmos-clear riskiert man ja eh nicht ...
