AMD Athlon 64 Overclocking Basics

Nachdem ich bereits einige Athlon64 Overclocking Guides gelesen habe, war ich von inhaltlichen Fehlern recht unangenehm berührt, da diese unberechtigte Vorurteile gegenüber der Athlon64 Plattform bezüglich der OC'barkeit erneuerten. Trotz einigem Stöbern im P3D-Forum konnte ich auch hier keinen umfassenden & wahrheitsgetreuen Guide finden, der tatsächlich die kompletten Sachverhalte erklärt. Da ich in letzter Zeit einige S754 und S939 Kombinationen durchgetestet habe, will ich in einem Bericht meine Erfahrungen für andere zusammenfassen.

Für alle A64-Einsteiger zum Übertakten sehr lesenswert! Meiner Meinung nach beruhen die allermeisten Probleme einfach nur auf dem Unwissen über das Funktionieren der A64-Takte und A64-Teiler/Multiplikatoren. Hat man die Sache mit den Teilern verstanden, ist das Übertakten eines A64 ein Kinderspiel.

Es sei angemerkt, daß sich die meisten Angaben auf VIA K8T800, VIA K8T800 Pro und nVidia nForce4 Chipsätze beziehen. Inwiefern es Abweichungen zu nForce3 150, 250 und 250GB Lösungen sowie Chipsätzen von ULI, SiS oder ATI gibt, kann gern von Besitzern dieser Chipsätze nachgetragen werden.

Ich hoffe, daß ich mit diesem Thema vielen Neulingen den Einstieg in die A64 OC-Welt erleichtern kann. Der durch eigenes Ausprobieren der beschriebenen Verhaltensweisen hervorgerufene Lernprozeß ist allerdings die beste Methode, um sich nach der theoretischen Lektüre tatsächlich zum "Advanced OC" ernennen zu können.



SYNCHRONER/ASYNCHRONER TAKT


Eins gleich vorweg: Es gibt beim Athlon64 keinen synchronen/asynchronen Takt.

Mit "asynchron" kann somit maximal der Sachverhalt beschrieben werden, daß der Referenztakt nicht gleichzeitig dem Speichertakt entspricht. Wie im zweiten Abschnitt "RAM/CPU/HTT/Referenztakt" zu lesen, darf dies aber nicht als "asynchron" bezeichnet werden. Doch dazu später mehr. Vorab ein einführendes Beispiel.

Im einem Artikel im Internet konnte ich folgende Benchmarkergebnisse finden:



Es wird argumentiert, daß beispielsweise die Kombination "2000/200/200" (CPU-Takt / Hypertransport-Takt / Speichertakt) deshalb der "2000/200/166" Konfiguration überlegen ist, da im zweiten Fall eine asynchrone Taktung vorliegen würde. Man liest: "Die asynchron getaktete CPU verliert hier sichtlich an Boden."

Das ist nicht schlüssig. Hier ist die gemessene Leistung einzig und ausschließlich vom tatsächlich resultierenden RAM-Takt abhängig und NICHT von der Tatsache einer synchronen oder asynchronen Taktung. Ebenso kann die Kombination "2200/275/275" nur deshalb mit "2400/240/200" gleichziehen (trotz 200 MHz weniger CPU-Takt), da der Speichertakt um 75 MHz höher liegt, was im 3DMark01 noch sehr starken Einfluß hat. Dies hat also überhaupt nichts mit einer angeblichen "asynchronen" Taktung der "2400/240/200" Konfiguration zu tun.

Es galt (und gilt) beim Sockel A, daß der synchrone dem asynchronen Betrieb vorzuziehen ist, da der asynchrone Betrieb Performance-Verluste bringt. Dies ist beim Athlon64 nicht mehr korrekt und Begriffsvermischungen stiften unnötig Verwirrung. Die Ursache liegt darin, daß beim Sockel A der Speicher noch indirekt über den Front-Side-Bus (FSB) gekoppelt war. Beim Athlon64 existiert ein solcher leistungshemmender Fronst-Side-Bus nicht mehr, da der Memory-Controller direkt in der CPU sitzt. Somit ist der Speicherzugriff beim Athlon64 vollkommen unabhängig von der Anbindung zum Chipsatz über Hypertransport. Der Hypertransport-Link ist neben dem Speicherinterface also ein eigenständiges, schnelles Chipsatz-Interface. Es handelt sich beim Speicher- und Peripheriezugriff des K8 somit um zwei vollständig unabhängige und separate "Datenautobahnen" zur/von der CPU.

Das "Tunen" am Speichertakt wirkt sich somit gänzlich anders aus (z.B. in speicherlastigen Programmen) als eine Veränderung des Hypertransport-Taktes (z.B. in stark peripherielastigen Szenarien).

Sicherlich sind in gezeigten Benchmarks bei 240/240 die Ergebnisse teilweise höher als bei 240/200 - aber eben nur weil bei letzterer Taktung der Speicherdurchsatz niedriger ist, eine Aussage über synchrones/asynchrones Taktverhalten kann nicht gefolgert werden! Tatsächlich zeigt der A64 die beste "asynchrone" Speicherperformance überhaupt - sprich verzeichnet keinerlei zusätzliche Einbrüche, wenn der Speichertakt nicht identisch zum Referenztakt gewählt wird. Einzig die erwarteten Verluste durch niedrigeren Speichertakt entstehen, keine zusätzlichen Verzögerungen. Anders ist dies wie erwähnt auf nForce2 oder VIA KT333-880 Chipsätzen für Sockel A, wo teilweise dramatische Performanceverluste auftreten, wenn der Speichertakt nicht identisch zum FSB gewählt wird. Die Ursache liegt darin begründet, daß der A64 stets feste, ganzzahlige Teiler verwendet für CPU-, Speicher- und HTT-Takt. Man darf faktisch nicht von asynchroner Taktung reden, da ohnehin jeder Takt unabhängig ist. Bei 2400 MHz und DDR333 wird eben ein /12 Teiler und bei DDR400 ein /10 Teiler verwendet für den RAM.

In diesem Sinne "teilt" der A64 immer.

Wenn man wirklich bewerten will, wie gut oder schlecht eine synchrone/asynchrone Taktung ist, hätte man 240/200 bei 10x240 mit LDT x4 gegen 200/200 bei 12x200 (mit einem 3800+ für 12er Multi) mit LDTx5 antreten lassen müssen. Sprich konstanter CPU-Takt (2400 MHz), konstanter Speichertakt (200 MHz) und (nahezu) konstanter HTT-Takt (960 bzw 1000 MHz). Da hätte man gesehen, was wirklich Fakt ist: nämlich daß der Referenztakt ein reiner Referenztakt ist, der ABSOLUT GAR NICHTS zur Performance beiträgt. Die tatsächliche Leistung hängt nur vom jeweiligen "ausmultiplizierten/geteilten" Speicher-, Prozessor- und HTT-Takt ab. Diese Tatsache wird oft nicht deutlich. (Wem die Zahlen jetzt zu schnell durcheinander gewirbelt sind, der lese zuerst bis ans Ende und dann den einführenden Abschnitt erneut.)

Die im obigen Benchmark verzeichneten Performanceunterschiede sind ausschließlich auf verschiedene RAM-Taktungen zurückzuführen und haben in keinster Weise etwas mit asynchronen/synchronen Leistungsunterschieden zu tun.




RAM-/CPU-/HTT-/REFERENZTAKT


Beim A64 gibt es im wesentlichen 4 Takte:

Referenztakt (i.A. 200-400 MHz)
CPU-Takt (i.A. 1800-2600 MHz)
RAM-Takt (i.A. 133-300 MHz)
HTT-Takt (i.A. 600-1000 MHz)

Dabei hat der Referenztakt keinerlei Auswirkung auf die Performance. Man kann ihn sich lediglich als Taktgeber vorstellen.


------------------------------------------------------------------------------------------------

Der CPU-Takt ergibt sich aus CPU-Multiplikator * Referenztakt.

Der RAM-Takt ergibt sich aus CPU-Takt / RAM-Teiler.

Der HTT-Takt ergibt sich aus LDT-Multiplikator * Referenztakt.

------------------------------------------------------------------------------------------------



Auf nahezu allen A64 Boards kann man den RAM-Teiler nur indirekt und nicht umfassend wählen. So wird oft "DDR400", "DDR333", "DDR266" und "DDR200" im Bios angeboten. Tatsächlich ist dies aber nur ein kleiner Teil der jeweiligen Speicherteiler. Der aktuelle Speicherteiler ist immer abhängig vom jeweilig eingestellten CPU-Multiplikator des Prozessors.

Bestes Beispiel ist eine 2000 MHz CPU (3000+ NC S754, 3200+ CH S754, 90nm 3200+ Winchester S939). Diese CPU's besitzen von Haus aus einen 10x Multiplikator.

Stelle ich DDR400 ein, wählt das Board einen /10 Multiplikator für den RAM, sprich 2000 MHz / 10 = 200 MHz.
Stelle ich DDR333 ein, wählt das Board einen /12 Multiplikator für den RAM, sprich 2000 MHz / 12 = 166 MHz.
Stelle ich DDR266 ein, wählt das Board einen /15 Multiplikator für den RAM, sprich 2000 MHz / 15 = 133 MHz.
Stelle ich DDR200 ein, wählt das Board einen /20 Multiplikator für den RAM, sprich 2000 MHz / 20 = 100 MHz.

Im Vergleich eine 2200 MHz CPU (3200+ NC S754 / 3400+ CH S754 / 3500+ NC/WC S939).
Stelle ich DDR400 ein, wählt das Board einen /11 Multiplikator für den RAM, sprich 2200 MHz / 11 = 200 MHz.
Stelle ich DDR333 ein, wählt das Board einen /14 Multiplikator für den RAM, sprich 2200 MHz / 14 = 157 MHz.
Stelle ich DDR266 ein, wählt das Board einen /17 Multiplikator für den RAM, sprich 2200 MHz / 17 = 129 MHz.
Stelle ich DDR200 ein, wählt das Board einen /22 Multiplikator für den RAM, sprich 2200 MHz / 22 = 100 MHz.

Man sieht leicht, daß "DDR400", "DDR333", etc. nur symbolisch für verschiedene RAM-Teiler stehen. Diese hängen vom CPU-Takt ab und werden im Ernstfall lieber zu groß gewählt, da eine 'werkseitige Übertaktung' des Speichers ausgeschlossen wird, so daß teilweise der RAM unter Spezifikation läuft.

Das heißt, man muß den gewünschten CPU-Multiplikator mit 200 MHz multiplizieren und dann die jeweiligen Teiler finden, die bei diesem CPU-Takt 133, 166 oder 200 MHz Speichertakt generieren würden. Diese errechneten Teiler sind dann die tatsächlich anliegenden RAM-Teiler. Diese bleiben nun bei gleichem CPU-Multiplikator bei jeder veränderten Referenztakt-Einstellung konstant. Die gewonnen CPU-Takte müssen nun lediglich immer nur durch diesen ermittelten RAM-Teiler dividiert werden, um den real anliegenden Speichertakt zu ermitteln.

Fazit: der Speichertakt hängt direkt vom CPU-Takt ab und nur indirekt vom Referenztakt. Es besteht keine direkte Abhängigkeit von Referenztakt und Speichertakt.

Von daher wäre es sinnvoller, im Bios Teiler von /1, /2, /3 ... /30, /31, ... usw. anzubieten, um den Speichertakt wirklich 100% individuell setzen zu können. Ich denke, in Zukunft könnte es hier Tweaker-Bios-Files bzw. neue Bios-Versionen der Mainboard-Hersteller geben. So könnte man bei enstprechendem CPU-Takt vollkommen individuell seinen Speichertakt generieren. Theoretisch möglich wäre dies in jedem Fall problemlos, die technische Realisierung scheint hier allerdings andere Richtlinien vorzugeben.

Ein sinnvolles Einsatzgebiet wäre z.B. die Unterstützung von DDR600 Speicher (300 MHz). Hier müßte man z.B. bei einer 2400 MHz CPU (3700+, 3800+) einfach nur bei 12x200 MHz statt dem /12 einen /8 Divider auswählen für den Speicher und hätte bei ansonsten unveränderter Systemeinstellung den RAM bei 2400/8 = 300 MHz betrieben. Leider wird es im Moment von keinem mir bekannten Board/Bios unterstützt, den RAM-Divider auch niedriger als den CPU-Multiplikator zu wählen.

Fakt ist also, daß ein Athlon64-Board beim Übertakten (Erhöhen des Referenztaktes) diese vom CPU-Multiplikator abhängigen Speicherteiler nicht verändert. Takte ich dementsprechend bei 10er CPU-Multi auf 10x240 MHz, so bleibt bei DDR333 Einstellung der /12 Teiler für den RAM erhalten, es liegen also weiterhin 2400/12 = saubere 200 MHz für DDR400 RAM an.

Anders wäre dies bei 11x220 MHz (2420 MHz). Dort würde der Prozessor bei Default-Takt (11x200) und DDR333 Teiler einen /14 Teiler wählen (~157 MHz), da laut Spezifikation zwar /13 mit ~169 MHz zwar näher dran sind, aber eben zu hoch = verboten. Dieser /14 Teiler bliebe dann auch bei 11x220 MHz erhalten, so daß am Speicher 2420/14 = ~173 MHz anliegen.

Von daher darf in keinem Fall von synchron und asynchron geredet werden.

Denn selbst bei "ganz normalem" "DDR400" - sprich "1:1" - Betrieb werden ja die oben genannten Teiler verwendet, um aus dem CPU-Multiplikator den Speichertakt zu generieren.


[UPDATE]
"Krumme" .5 Speicherteiler wie z.B. 8.5, 9.5, 10.5, etc. sollten stets vermieden werden.

Zum einen kann es hierbei tatsächlich zu Performanceverlusten kommen. Entscheidender ist aber die Tatsache, daß die Speicherteiler beim Athlon64 immer ganzzahlig sind. Selbst aktuelle Tools können diesen Sachverhalt nicht in jedem Fall korrekt auslesen und wiegen den Nutzer in falschem Glauben.

Takte ich einen Prozessor z.B. auf 8.5*250=2125 MHz, so ist bei DDR400 Teiler anzunehmen, daß auch ein /8.5 Teiler für den Speicher verwendet wird, um z.B. DDR500 Speicher mit 2125/8.5=250 MHz anzusprechen. Da es aber wie gesagt nur ganze Speicherteiler gibt, wird bei krummen Multiplikatoren stets aufgerundet. Tatsächlich liegen also nur 2125/9=236 MHz am Speicher an, dieser läuft somit deutlich unter seiner Spezifikation.
[/UPDATE]


Der HTT-Takt ist von alldem sowieso unabhängig, da er eigene Multiplikatoren (x1, x2, x3, x4, x5) besitzt (i.A. als LDT-Multiplikator bezeichnet, dabei kann anstatt x1, x2, x3 ... auch symbolisch 200 MHz, 400 MHz, 600 MHz ... im Bios angegeben sein), um aus dem Referenztakt generiert zu werden. Wie im Abschnitt weiter unten aufgeführt, trägt der HTT-Takt nur unwesentlich zur Gesamtleistung bei. Ein Übertakten ist im allgemeinen erst recht nicht sinnvoll.

Hat man die Geschichte mit den Teilern verstanden, ist das korrekte A64-Übertakten keine unlösbare Aufgabe mehr, da sich alle Takte stets sauber errechnen / herleiten lassen.

Die oft gehörte Aussage eine "hoher Referenztakt bringt Zusatzperformance" ist 100% unsinnig.


Beispiel:

Denn wenn ich einen 3800+ von 12x200 MHz mit LDTx5 und DDR400 (d.h. /12 Teiler) einsetze, erhalte ich 2400 MHz CPU-Takt, 200 MHz RAM-Takt und 1000 MHz HTT-Takt (LDT x5).

Verwende ich nun die Einstellung 8x300 MHz mit LDTx3 und DDR266 Teiler (8*200 MHz = 1600 MHz; 1600 MHz / 12 = 133.3 MHz) wird also bei DDR266 Einstellung und einem CPU-Multiplikator von 8 ein /12 Teiler für den RAM verwendet. Sprich auch bei 8x300 MHz = 2400 MHz liegt der /12 RAM-Divider an und liefert 2400 / 12 = 200 MHz für den RAM. Mit LDT x3 ergeben sich 3x300 MHz = 900 MHz HTT-Takt.

=> Die Performance ist in allen Fällen nahezu 100% identisch (außer in Anwendungen, die einen Unterschied zwischen 900 MHz und 1000 MHz HTT-Takt bewerten).


Daraus läßt sich schlußfolgern, daß die Behauptung, ein hoher Referenztakt bringe zusätzliche Performance, absolut haltlos ist.


Dieser Beitrag von blander enthält im übrigen eine schöne Übersicht über alle verfügbaren RAM-Divider bei entsprechenden CPU-Multiplikatoren und DDRxxx Einstellungen. Alternativ (und ohne Anspruch auf absolute Korrektheit) ist natürlich auch mein kleiner OC-Calculator zu verwenden.



Wie es sich gehört, zum Abschluß noch ein anschauliches "buntes" Beispiel. Für die Kontrolle von CPU- und Referenztakt ist das Tool CPU-z in der jeweils neusten Version sehr zu empfehlen. Einzig der Hypertransport-Takt läßt sich hiermit nicht auslesen (man verwende dafür SiSoft Sandra oder Everest).

Dies Bild wurde automatisch verkleinert. Bitte diese Zeile anklicken, um das Bild in Originalgröße (845x670) zu betrachten.

Als CPU-Multiplikator wurde 11.0 gewählt und als Refernztakt 255 MHz. Für den LDT-Multiplikator wäre x4 wohl noch im Rahmen der Toleranz, als erzkonservative Person ( ) habe ich mich aber für x3 entschieden, um den Hypertransport-Takt nicht über 1000 MHz schnellen zu lassen. SiSoft Sandra bestätigt den Hypertransport-Takt von 3*255 = 765 MHz, was effektiven 1530 MHz entspricht. Bei standardmäßiger 16bit/16bit Bandbreite gibt das etwa 6.1 GB/s bidirektionale Bandbreite (das spezifizierte Maximum bei 5*200 MHz sind 8 GB/s).

Als Speicherteiler habe ich beispielhaft im Bios "DDR366 (183 MHz)" gewählt. Bei 11*200 MHz = 2200 MHz würde ein /12 Teiler 183.3 MHz liefern, was minimal über den gewünschten 183 MHz liegt. Da dies aber ausgeschlossen werden muß, wird der nächstgrößere Teiler /13 verwendet. Wie in CPU-z zu sehen, liegen am Speicher dann exakt 2805 / 13 = 216 MHz an. Somit läuft die CPU stark übertaktet, der Speichertakt und Hypertransport-Takt bleiben im Rahmen.




HTT-LINK


Zur Frage der Nützlichkeit einer hohen Bandbreite des Hypertransport-Links sei folgende Berechnung erwähnt. Der HTT-Link dient auf Single-CPU Systemen zur Kommunikation der CPU mit dem Restsystem (exklusive dem Speicher, da dieser direkt an die CPU angebunden ist) und wird im DDR Verfahren genutzt. Ein Referenztakt von 1000 MHz ergibt bei 16/16 Bit eine Bandbreite von 8 GB/s bidirektional, d.h. 4 GB/s vom System zur CPU und gleichzeitig 4 GB/s von der CPU zum System. 1000 MHz * 16 bit * DDR = 32.000 Mbit/s = 4.000 MB/s.

Nun überlege man sich, was so alles mit der CPU kommunizieren muß im Normalfall. Der PCI-Bus kann maximal 133 MB/s beisteuern, ein S-ATA RAID0 aus 2 Platten native über die Southbridge trägt im theoretischen Maximalfall 300 MB/s bei. Die Kommunikation zur Grafikkarte mag auch noch einige hundert MB/s in gewöhnlichen Anwendungen beisteueren, in Games vielleicht im Extremfall um 1-2 GB/s. Dazu noch die sonstigen peripheren Anschlüsse, die nicht über PCI angebunden sind. So kommt man auf maximal vielleicht 1000-1500 MB/s tatsächlich notwendiger Bandbreite. Eine Reduzierung des HT-Links von 1000 MHz auf 800 MHz reduziert die effektive Bandbreite von 8 GB/s auf 6.4 GB/s - ein in Anbetracht der benötigten Leistung leicht zu verschmerzender Verlust bei Zugewinn an Stabilität.

Die häufige Frage, wo denn nun Einbußen zu erwarten sind bei niedrigerem HT-Takt, klärt sich so von selbst. Nur einige hochgradig peripherie- und Grafikkarten-bandbreiten-lastige Benchmarks wie SPECview können hier überhaupt Unterschiede feststellen.

Im Fall des VIA K8T800 / K8T800 Pro begrenzt ohnehin der V-Link zwischen North- und Southbridge die neben der Grafikkarte übertragenden Daten auf 1066 MB/s.

Beim Übertakten kann man den HT-Takt also bedenkenlos in Regionen von 700-900 MHz reduzieren bei 16/16 Bit Anbindung, ohne irgendwelche gravierenden Nachteile in Kauf nehmen zu müssen.

Fazit: die gesamte E/A-Peripherie zuzüglich der CPU-fernen Busse ist mit der HT-Bandbreite hoffnungslos übersättigt. Einzig ein PCI-Express SLi-Grafikkarten-System oder ein großes SCSI-Server-System kann hier einen Teil dieser Bandbreite ausnutzen. Zu beachten ist allerdings, daß AGP-Systeme ohnehin einen stark beschränkten Upstream Grafikkarte -> Chipsatz aufweisen, so daß hier die Upstream Bandbreite System -> CPU selbst schon mit ca. 1 GB/s ausreichend wäre. Einzig sehr CPU-lastige Grafikkartenanwendungen (diverse Games, Rendering, sonstige Anwendungen mit hohem Traffic Grafikkarte -> CPU) können von der hohen HT-Bandbreite CPU->System profitieren. Erst PCI-Express Systeme mit entsprechenden bandbreitenhungrigen Anwendungen werden den HT-Link auch bidirektional auszulasten wissen. Bis aber tatsächlich einmal 4 GB/s down und gleichzeitig 4 GB/s up zu wenig werden, kann ruhigen Gewissens der HT-Link reduziert werden.

Benchmarks, die diese Sachverhalte bestätigen (insbesondere den eingeschränkten AGP-Upstream), finden sich z.B. hier.




COOL AND QUIET


Einige Worte hierzu. Abhängig vom Prozessor kennt der A64 auf S754 und S939 Systemem verschiedene Lastzustände. Als Beispiel soll ein 3500+ mit 11x200 MHz = 2200 MHz dienen.

Dieser besitzt (wie auch der 3200+ NewCastle mit 2.2 GHz für S754) offiziell 4 P-States, von welchen ich im Praxiseinsatz allerdings bisher nur 3 beobachten konnte:

1000 MHz = 5x200 MHz @ 1.100V
2000 MHz = 10x200 MHz @ 1.400V
2200 MHz = 11x200 MHz @ 1.500V

Beim Übertakten mittels Multiplikatoren und Referenztakten, daß ausschließlich der CPU-Multiplikator durch die Cool'n'Quiet-Software verändert wird. Das heißt, lediglich der CPU-Multiplikator und nicht der Referenztakt oder die Speicherteiler werden via Cool'n'Quiet reduziert. Einige der ersten S754 Boards zeigten hier oft Auslesefehler bzw. ein falsch implementiertes Verhalten, wenn Taktraten von 10x80 MHz für den 800 MHz P-State angezeigt wurden, 4x 200 MHz (S754) bzw. 5x 200 MHz (S939) sind in jedem Fall korrekt.

Besondere Beachtung sollte somit der Tatsache gewidmet werden, daß Cool'n'Quiet beim Übertakten ausschließlich mit Standard-Multiplikator sinnvoll weiterzuverwenden ist.
(* Ausnahme: siehe Anmerkung zu DFI nForce4 Mainboards am Ende dieses Abschnitts *)

Takte ich oben genannten 3500+ auf z.B. 11x220 MHz bei 1.500V, so hängt eine erfolgreiche Verwendung von Cool'n'Quiet ausschließlich davon ab, ob auch 10x220 MHz bei 1.400V und 5x220 MHz bei 1.100V stabil laufen (was in den meisten Fällen so ist).

Würde ich allerdings eine Taktung von 10x240 MHz wählen, um 2400 MHz bei 1.500V zu erreichen, ist Cool'n'Quiet arg gefährdet. Denn die Cool'n'Quiet Software holt sich unabhängig vom im Bios eingestellten CPU-Multiplikator in jedem Fall den originalen Multiplikator unter Vollast wieder. Sprich, sobald Last erzeugt wird, taktet Cool'n'Quiet auf 11x240 MHz (=2640 MHz), was bei 1.500V zum sofortigen Freeze/Reboot führt. Gleiches gilt für andere Multiplikatoren.


Im Zusammenhang mit übertaktetem Speicher bei einer RAM-Einstellung ungleich DDR400 ist zu beachten, daß bei veränderten CPU-Multiplikatoren unter Cool'n'Quiet auch andere RAM-Divider erzeugt werden! Diese können ebenfalls zu nicht vorhergesehenen Instabilitäten führen.

Ein Beispiel hierzu:

Besitze ich DDR400 Speicher, der 220 MHz nicht stabil schafft und einen Athlon64 3200+ NewCastle (11x200 MHz), welchen ich gern auf 3400+ Niveau (11x220 MHz) übertakten möchte und weiterhin Cool'n'Quiet aktiv sein soll. Neben der Verringerung des LDT-Multiplikators von 5x auf 4x (um wie oben erwähnt, den HT-Link nicht über die spezifizierten 1000 MHz schnellen zu lassen) muß auch Sorge dafür getragen werden, daß der RAM nicht bei 220 MHz läuft. Also wählt man im Bios den DDR333 Teiler, welcher (wie eingangs vorgerechnet) zu einem /14 RAM-Divider führt. Das heißt bei 2400 MHz liegen nur noch 2400/14 = 171 MHz am Speicher an. Dies ist unterhalb seiner spezifizierten Frequenz, aber die meisten Speicher erlauben bei niedrigeren Taktungen schärfere Timings. In diesem Fall z.B. könnte ich die Timings von 3.0-3-3-8 auf 2.0-2-2-6 ändern, um den verlorenen Takt in Hinblick auf die Performance auszugleichen.

Nun kommt Cool'n'Quiet ins Spiel. Selbst wenn die CPU mit 10x220 MHz = 2200 MHz bei 1.400V und 5x220 MHz = 1100 MHz bei 1.100V stabil läuft, kann der Speicher einen Strich durch die Rechnung machen! Denn taktet die 3200+ CPU von 11x220 MHz auf 10x220 MHz, wird bei DDR333 Teiler und CPU-Multi von 10 ein /12 Divider für den RAM gewählt (anstatt des bisherigen /14), was plötzlich zu 2200/12 = 183 MHz Speichertakt führt! Dies kann mit 2.0-2-2-6 schon wieder nicht mehr möglich sein, es kommt zum Freeze / Bluescreen / Reboot. Bei Herabtaktung auf 5x220 MHz (Idle) würde ein /6 Divider (1000/6 = 166 MHz) bei DDR333 Einstellung gewählt werden. Dies führt in diesem Fall wieder zu 1100/6 = 183 MHz Speichertakt, was mit oben genannten Timings möglicherweise nicht zu schaffen ist.

Fazit: veränderte Speichertakte bei Cool'n'Quiet aufgrund anderer CPU-Multiplikatoren sind ebenfalls zu beachten und entsprechend sollten die Timings des RAM’s auf die höchste zu erwartende Speicher-Taktrate aller P-States abgestimmt werden.


Ein weiteres Problem: die Spannungen. Hier gibt es grundsätzlich zwei Kategorien von Mainboards.
Kategorie (a) behält die beim Übertakten geänderte VCore (CPU-Spannung) für alle P-States bei.
Kategorie (b) verändert die VCore der P-States gleichermaßen zur Veränderung der Default VCore.

Boards der Kategorie (a) gehören oft zur ersten Generation von Sockel 754 Boards, allerdings gibt es auch viele aktuelle günstigere S939 Boards, die in diese Gruppe fallen. Hier ist das Cool'n'Quiet Feature bei veränderter CPU-Spannung (VCore) nicht sinnvoll nutzbar, da die größte Stromeinsparung durch die veränderte VCore und nicht durch den niedrigeren Takt erreicht wird. Benötige ich also z.B. bei einem übertakteten 3000+ NewCastle für 10x240 MHz 1.85V Spannung, so liegen diese 1.85V auch im niedrigsten P-State bei 5x240 MHz an. Der Stromverbrauch sinkt nur unwesentlich.

Boards der Kategorie (b), wie z.B. das Abit KV8 Pro (S754) und Abit AV8 (S939) verändern die CPU-Spannung abhängig von der Original-VCore. Betrachten wir obigen 3000+, welcher für 10x240 = 2400 MHz 1.85V benötigt. Das sind 0.35V mehr als normal (1.50V). Im niedrigsten P-State von 5x240 MHz = 1200 MHz liegen somit 1.45V an (1.10V+0.35V), was im Gegensatz zu 1.85V eine deutliche Senkung ist. Der Stromspareffekt ist entschieden größer, da neben 1200 MHz weniger Takt auch 0.4V weniger Spannung anliegen. Das heißt, es wird die Differenz zwischen im Bios eingestellter VCore und der Default-VCore (z.B. 1.50V für 130nm A64 oder 1.40V für 90nm A64) auf für alle anderen Cool'n'Quiet-Spannungen der P-States dazu addiert.

Außerdem ist es es oft ohnehin wünschenswert, daß auch die VCore in den P-States proportional angehoben wird, da bei Standardmultiplikator und erhöhtem Referenztakt automatisch höhere Taktungen für die P-States entstehen, da Cool’n’Quiet wie oben erwähnt nicht den Referenztakt verändert sondern lediglich den CPU-Multiplikator.

Fazit: Die Mainboards der Kategorie (a) sind zwar in allen Fällen stabil (da für alle Takte maximale VCore), die Boards der Kategorie (b) empfehlen sich aber mehr, da die VCore in den P-States dennoch abgesenkt wird und so weiterhin sinnvolle Stromeinsparungen möglich sind.


Die nForce4 DFI Mainboards (Ultra, SLI-D, SLI-DR) erlauben über drei verschiedene CPU-Voltage Optionen "StartUp", "VID" und prozentuale "over VID" individuell entweder Typ (a) oder Typ (b) zu simulieren. Das ist die beste und nutzerfreundlichste Lösung, die ich bis heute auf Athlon64 Mainboards vorfinden konnte.

Über die zusätzliche Option, den maximalen Cool'n'Quiet Multiplikator unabhängig vom CPU-Multiplikator selbst festlegen zu können, bieten die nForce4 DFI Boards hier die beste bisher gesehene Möglichkeit für Overclocking in Verbindung mit C'n'Q. So kann man zum Übertakten beliebige Multiplikatoren für die CPU wählen, ohne auf ein sauber funktionierendes Cool'n'Quiet verzichten zu müssen.



SPANNUNGEN


VCore / CPU-Voltage
Stabilisierung der CPU bei höheren Taktraten

Ideales Testprogramm für CPU-Stabilität ist Prime95, am besten in der Athlon64 optimierten Version 24.14.

Empfohlene Testmethoden (Torture Test):
"Large FFT" oder
"Custom", 8K ... 4096K, In Place FFT (enabled)

Jede Variante sollte für mindestens 1-2 Stunden fehlerfrei laufen, um von "stabil" sprechen zu können. Um eine CPU bei Takt x mit Spannung y als "rockstable" zu bezeichnen, sollte jedes der beiden Settings mindestens 12-24 Stunden fehlerfrei laufen.


VDimm / VDDR / RAM-Voltage
Stabilisierung des RAM bei höheren Speichertakten

Ideale Testprogramme für Speicherstabilität sind MemTest86, MemTest86+ oder Prime95 v24.14 im Torture Test "Blend".


VDD-Voltage/Northbridge/Southbridge
Southbridge-Voltage ist bei VIA Chipsätzen unbedeutend beim Übertakten, da die Southbridge stets mit gleicher Bandbreite (VLink) an die Northbridge angebunden ist und somit beim Erhöhen des Referenztaktes nicht beeinflußt wird. Beim nForce3/nForce4 als SingleChip-Lösung existiert die Southbridge ohnehin nicht.

Northbridge-Voltage ist bei VIA K8T8xx sowie nForce3/nForce4 Chipsätzen ebenso relativ unbedeutend, da die Anbindung der Northbridge / des Chipsatzes an den Prozessor über den HT-Link geregelt ist und selbst nicht übertaktet wird.

Eine leicht erhöhte Spannung der Northbridge bzw. des Chipsatzes kann allerdings in vielen Fällen 3D-Stabilitätsprobleme bei hohen Referenztakten beheben bzw. hohe Referenztakte überhaupt erst stabil ermöglichen.

HT-Voltage
Dient der Stabilisierung bei Übertaktung jenseits der spezifizierten 800 MHz bzw. 1000 MHz des HT-Taktes. Allerdings ist eine Erhöhung des HT-Links wie oben erwähnt nahezu nie sinnvoll, weshalb dieser stets im Rahmen seiner Spezifikation betrieben werden sollte, eine Erhöhung der Spannung (idR über 1.20V) ist nicht notwendig.

AGP-Voltage
Kann den AGP-Bus bei fehlendem PCI/AGP-Fix und hohen Referenztakten stabilisieren. Bringt aber in den meisten Fällen nichts, so daß entweder der Referenztakt zu senken bzw. ein Board mit PCI/AGP-Fix zu beschaffen ist.

PCIe-Voltage
Stabilisiert den PCIe-Bus beim Übertakten jenseits der 100 MHz (default).


PCI/AGP/PCIE BUS, FIX & TEILER

Der PCI-Bus sollte i.A. bei 33.3 MHz, der AGP-Bus bei 66.6 MHz und er PCI-Express-Bus bei 100 MHz betrieben werden, um Probleme mit Grafikkarten, Festplatten und sonstiger Peripherie zu vermeiden. Bei Erhöhung des Referenztaktes berechnet sich

PCI-Bus = Referenztakt / Teiler
AGP-Bus = ( Referenztakt / Teiler ) * 2

Der VIA K8T800 / K8T800 Pro Chipsatz bietet neben dem 1/6 Teiler
(200 MHz / 6 -> 33.3 MHz PCI -> 66.6 MHz AGP)
auch einen 1/7 und 1/8 Teiler an. Diese genügen selbst ohne PCI-AGP-Fix, um Referenztakte bis 266 MHz (und höher) zu erreichen. Denn bei 266 MHz bewirkt der 1/8 Teiler 266 MHz / 8 = 33.3 MHz PCI und 66.6 MHz AGP-Takt, was der Spezifikation entspricht.

Ein Board mit fixer Einstellung für den PCI/AGP/PCIe-Takt generiert unabhängig vom Referenztakt einen korrekten 33 MHz PCI, 66 MHz AGP und 100 MHz PCIe-Takt. Eine manuelle Übertaktung des AGP-Busses bringt selten Performancezuwächse, da die AGP-Bandbreite im 8x Modus für aktuelle Grafikkartenlösungen bereits überdimensioiert ist. Möglicherweise kann eine Erhöhung der PCIe-Express Brandbreite in SLI-Systemen minimale Performancezuwächse bringen.

Für den PCI-Express (PCIe) Takt ist für die entsprechenden Mainboards auf nForce4 sowie K8T890 Chipsätzen ebenfalls die Möglichkeit gegeben, diesen PCIe Takt auf seine originalen 100 MHz zu fixieren und somit vom Referenztakt zu entkoppeln.




Grundsätzlich gibt es also kein Limit, wie hoch der Referenztakt zu wählen ist, solange CPU-Takt, Speichertakt, HT-Takt und PCI/AGP- bzw. PCIe-Takt im Rahmen bleiben. Einzige Grenze ist hierbei die Kombination aus Mainboard und Qualität des Chipsatzes, wie hoch diese es zulassen, die Referenztakte sauber einzustellen und halten zu können. Mit diversen Spannungseinstellungen für Chipsätze und jeweiligen Bus-Systeme lassen sich hier im Grenzfall auch weitere Stabilisierungen bei hohen Referenztakten erreichen.

Von daher sind Screenshots mit 250-400 MHz Referenztakt bei korrekten Teilern/Multiplikatoren relativ leicht zu erreichen und stellen kein Mittel zum Vergleich der Leistungsfähigkeit eines Systems dar. Hier sollte man sich nicht blenden lassen.



---------------
UPDATES
---------------

SPEICHERTEILER DDR433/DDR466/DDR533/DDR566/DDR600

Habe Tests mit einem Asus A8N SLI Deluxe durchgeführt, welches neben der üblichen DDR200/DDR266/DDR333/DDR400 Speicherteiler noch weitere Teiler bis einschließlich DDR600 anbietet. Meine ursprüngliche Vermutung, daß man damit Speicherteiler kleiner als dem CPU-Teiler auswählen kann, wurde allerdings enttäuscht.

So hätte ich mir z.B. vorgestellt, bei einer Taktung von 10*200 MHz = 2000 MHz mit DDR500 Speicherteiler anstatt einem /10 RAM-Teiler einen /8 RAM-Teiler zu erhalten, um den Speicher bei 250 MHz (2000/8=250) zu betreiben, obwohl der Referenztakt unverändert bei 200 MHz läuft. Leider verhält sich das Board nicht so und erhöht bei Einstellung auf DDR500 einfach den Referenztakt auf 250 MHz und wählt intern einen DDR400 Speicherteiler, so daß (bei unverändertem CPU-Multiplikator) dann 10*250 MHz = 2500 MHz mit /10 Speicherteiler (für 250 MHz RAM-Takt) anliegen.

Jemand, der nicht mit diesem Verhalten rechnet, wundert sich dann eventuell warum der Rechner bei 10*200 MHz mit DDR500 Teiler nicht bootet, obwohl der Speicher (vorausgesetzt man besitzt DDR500 oder höher) dies schafft. Das Problem ist, daß die 2500 MHz vermutlich von der CPU nicht mit Standardspannung (wenn überhaupt) verkraftet werden, da das Board den CPU-Multiplikator nicht anpasst, sondern "ungefragt" einfach den Referenztakt erhöht und somit die CPU erheblich übertaktet.

Das selbe Verhalten tritt mit allen anderen Speicherteilern bis einschließlich DDR600 auf.

Fazit: es gilt nach wie vor, daß es nicht möglich ist, einen Speicherteiler kleiner als den CPU-Multiplikator zu wählen.

Update: Bei neueren Sockel 939 Boards in Kombination mit einer E-Stepping CPU (E3, E4, E6) und bei allen Sockel AM2 Boards ist es nun möglich, auch kleinere RAM-Teiler als den CPU-Multiplikator zu wählen. Beim Sockel AM2 mit DDR2 ginge es auch gar nicht anders, beim Sockel 939 mit DDR ist es nun ein nettes Feature.




SPEICHEREFFIZIENZ SISOFT SANDRA IM DUALCHANNEL

Bei Tests mit meinem Gigabyte K8NXP SLi Mainboard (nForce4 SLi Chipsatz) sind folgende Resultate entstanden.

Bekanntermaßen besitzt der A64 den Memory-Controller auf der CPU und dieser arbeitet hochgradig effizient. Im DualChannel Betrieb mit gut 6-8 GB/s Speicherbandbreite habe ich ein Verhalten in SiSoft Sandra festgestellt, welches klar zeigt, daß in diesen gigantischen Bandbreiten-Regionen der Speicher kein Flaschenhals mehr ist, sondern dessen Nutzung alleinig von der Leistung der CPU abhängt.

Wovon rede ich? Hier drei Screenshots:
200 MHz 2.0-2-2-5 1T mit /11 Teiler
200 MHz 2.0-2-2-5 1T mit /10 Teiler
200 MHz 2.0-2-2-5 1T mit /9 Teiler

Trotz 100% identischer Systemeinstellung von Timings (2.0-2-2-5 1T), LDT-Multi (x5), CPU (2200 MHz) und Referenztakt (200 MHz) unterscheidet sich die Effizienz erheblich! Erreicht man mit 11er Multi noch 93% Speichereffizienz, so sind es bei 10er Multi 88% und bei 9er Multi nur noch 83%. Dieses Verhalten besteht auch bei höheren Speichertakten.

Die Ursache hierfür ist, daß die CPU bei 1800 MHz (9x200) einfach viel zu langsam ist, um die gebotene Speicherbandbreite im DualChannel effizient auszunutzen. Selbst bei 2200 MHz ist man noch 7% vom Optimum entfernt. Ich schätze, erst mit 12.0 oder gar 13.0 Multi erreicht man hier vermutlich eine Traum-Effizienz von 97-98% (100% ist bekanntermaßen nur theoretischer Maximalfall).

Im Single-Channel Modus (ca. 3000 MB/s) tritt dieses Verhalten nur in viel schwächerem Maße auf (schwankt nur zwischen 90-94% bei Multi /9 /10 /11). Hier ist die CPU in allen Fällen schnell genug, um den Speicher effizient auszulasten. Im DualChannel ändert sich die Lage wie erwähnt erheblich.

Bei der Verwendung eines Speicherteilers größer als dem CPU-Multiplikator sieht die Sache natürlich wieder anders aus: hier wird der Speicher ja "eingebremst", so daß man auch bei kleineren Multiplikatoren eine hohe Speichereffizienz erreichen kann. (Also z.B. 10x240 MHz mit DDR333 Teiler gibt bekanntlich einen /12 Teiler für den Speicher, so daß bei 2400 MHz dann 200 MHz am Speicher anliegen. Mit 2400 MHz ist die CPU aber so schnell, daß sie die 200 MHz Speichertakt sicherlich mit ~95% Effizienz nutzen kann.)

Fazit: DualChannel ist also in der Lage, deutlich mehr Daten zu liefern, als die CPU bei niedrigen Taktfrequenzen überhaupt verarbeiten kann. Taktet man Speicher und Referenztakt identisch, entscheidet der CPU-Multiplikator über Bandbreite und Speichereffizienz. Das heißt, mit kleinen CPU's �* la 3000+ und nur 9.0 Multiplikator wird man wohl im 1:1 Betrieb (d.h. CPU-Multiplikator=RAM-Teiler) nie Effizienzen von 85% oder mehr erreichen.

Insbesondere bei den vielen OC-Screenshots von SiSoft Sandra sollte also in Zukunft immer der CPU-Multiplikator mitbeachtet werden, um Bandbreiten von 8000 MB/s und mehr sinnvoll einordnen zu können. Ein 1:1 Vergleich kann nur bei gleichem CPU-Multiplikator und gleichem DDRxxx Speicherteiler erfolgen.


Weiterhin ist anzumerken, daß bei Venice und SanDiego Cores (E-Stepping) der von SiSoft Sandra als auch Everest gemessene Speicherdurchsatz um 200-300 MB/s geringer ausfällt als bei NewCastle und Winchester. Wenn man die Möglichkeit zum direkten Vergleich mit zwei CPU's hat (d.h. ein CG oder D0 Stepping, sowie ein E-Stepping zur Hand), läßt sich dieser minimale Unterschied bei ansonsten identischen Settings auch im 3DMark2001, Aquamark und SuperPI32M messen.



PRIME95 RICHTIG BENUTZEN

Um einen Prozessor bei Takt X und Spannung Y auf Herz und Nieren zu überprüfen, sollte diese Einstellung von Prime95 mindestens 12-24 Stunden fehlerfrei laufen. Meist genügen zwar schon 4-8 Stunden als Stabilitätstest, aber je länger, umso sicherer (eine kurze Erläuterung zu den FFT-Laufzeiten findet sich hier sowie den im Topic folgenden Postings).



Für den Test von Prozessor und Hauptspeicher ist "Blend" zu wählen.



PRIME95 MIT DUAL-CORE PROZESSOREN

Zum Test von Athlon64 X2 DualCore Prozessoren müssen 2 Instanzen parallel laufen, um beide Cores voll auszulasten. Dafür ist es notwendig, zwei Prime95 Ordner anzulegen (entweder das Prime95 Zip-Archiv in verschiedene Ordner extrahieren oder eine Kopie des bisherigen Prime95 Ordners erstellen). Nachdem man aus beiden Ordner heraus je eine Instanz Prime95 gestartet hat, legt man einmalig über "Advanced -> Affinity" für jede Instanz die zu nutzende CPU fest (also z.B. CPU 0 für die erste und CPU 1 für die zweite Instanz). Der Stabilitätstest erfolgt wie bei einem SingleCore Athlon64 für beide Instanzen am besten mit Custom 8K-4096K und InPlaceFFT enabled.

Bei weiteren Testreihen hat sich allerdings gezeigt, daß es sogar besser ist, die Prime95 Instanzen ohne jegliche Zuordnung laufen zu lassen. Dadurch daß der Scheduler selbst bereits eine sehr gute Lastverteilungsentscheidung trifft und "unsichtbar im Hintergrund" die beiden Instanzen sogar physikalisch zwischen beiden Cores hin- und herspringen läßt, erreicht man ein deutlich besseres Empfindlichkeitsverhalten von Prime95 verglichen mit einer statischen Core-Zuordnung. Diese Variante ist somit für kompromißlose Stabilitätstests zu bevorzugen.

Da es häufig bei Usern zu Problemen kommt, Prime95 korrekt auf beiden Cores zu instanziieren, habe ich mich entschlossen, ein kleines Demo-Video "zu drehen".

DOWNLOAD - VIDEO​

[ requires FM Screen Capture Codec ]​

Falls es Codec-Probleme gibt, habe ich hier alternativ eine mit XViD kodierte Version bereitgestellt. Die Qualität ist allerdings nicht ganz so toll wie im Original, aber man erkennt genug.


Anmerkung: in einem sauberen Szenario müssen beide Prime95 Instanzen mit 50% CPU-Auslastung laufen. Im Video sind es allerdings nur etwa 33% je Instanz, da nebenbei noch mein Recording-Tool mit 30-40% Auslastung läuft (Aufnahme und realtime Encoding). Davon aber bitte nicht irritieren lassen.



MEMTEST86 / MEMTEST86+

Ist man sich nicht sicher, ob Fehler bei Prime95 bzw. sonstige System-Instabilitäten vom übertakteten Prozessor oder Speicher verursacht werden, empfiehlt sich MemTest86 bzw. MemTest86+ als Testprogramm.

MemTest ist (wie der Name vermuten läßt ...) ein Testprogramm, welches nahezu ausschließlich den Hauptspeicher auf Fehler prüft. Um die fast vollständige Unabhängigkeit vom Prozessor sowie die Entkopplung vom Betriebssystem zu ermöglichen, beruht MemTest auf einer sehr simplen Konsolenoberfläche. Nachdem man eine bootfähige Diskette / CD / DVD mit MemTest erstellt hat, wird von dieser gebooted. Die Tests beginnen automatisch.

Sobald ein Fehler entdeckt wird, ist das aktuelle Speichersetting als instabil zu betrachten. Besonders kritisch sind die Tests 5 und 8. Für kurze Checks genügen deshalb häufig bereits wenige Durchläufe von Test 5 und Test 8 (manuell per Menü auswählbar).

Bei Fehlern ist für gewöhnlich eine Abschwächung der RAM-Timings oder Erhöhung der VDimm notwendig. Hilft alles nichts, muß ein anderer Speicherteiler verwendet werden, um den RAM mit niedrigerer Frequenz zu betreiben.

Ist man sich sicher, daß der Speicher mittels MemTest absolut stabil läuft, ist die Ursache für Fehler bei Prime95 nun beim Prozessor bzw. dem Mainboard zu suchen. Allerdings ist MemTest sehr häufig nicht so empfindlich wie der Prime95 "Blend" Test (bzw. ein Custom Test mit deaktiviertem FFT inPlace). Man sollte die Testaussage von MemTest also eher so werten, daß, wenn MemTest schon Fehler findet, die Ursache für Instabilitäten auf jeden Fall mindestens auch beim RAM liegt. Umgekehrt gilt aber nicht, daß der Speicher auch wirklich stabil ist, nur weil MemTest keinen Fehler findet. Prime95 mit hoher Speicherauslastung bzw. Games mit viel Speicherbedarf sind wesentlich zuverlässigere Indikatoren.

Als ultimative Entscheidung, ob der RAM bei gegebenen Takt, Spannung und Timings stabil läuft, ist deshalb Prime95 "Blend"zu wählen. Ein persönlicher Erfahrungswert von mir: vom maximal stabilen Setting in MemTest müssen oft etwa 5 MHz abgezogen werden, um auch Prime95 "Blend" stabil zu bekommen.

MemTest nutze ich hauptsächlich deshalb, da es mit diesem Tool in kurzer Zeit möglich ist, schnell grobe Grenzen für Speichertakt-Timing-Kombinationen zu finden. Zum "Fein-Tuning" des Speichertaktes auf's MHz genau in Abhängigkeit von Timings und Speicherspannung verwenden ich anschließend Prime95. Außerdem lassen sich mit MemTest offensichtliche Speicher-Mißkonfigurationen bezüglich Takt und Spannung in wenigen Minuten finden.



DDR2-SUPPORT

Der Sockel AM2 ist verfügbar und somit auch DDR2 für den Athlon64. Bei der Berechnung der Speicherteiler ändert sich nichts - es wird weiterhin der non-DDR Takt zur Errechnung des RAM-Dividers verwendet (so wie man bei DDR-400 mit 200 MHz rechnet, verwendet man bei DDR2-800 eben 400 MHz, wenngleich das an sich nicht dem wahren Zellentakt entspricht). Aufgrund der höheren Speichertakte und kleineren RAM-Divider sind die Rundungen (d.h. Betrieb des Speichers unter Spezifikation) bei ungünstigen Multiplikator/Teiler-Kombinationen nun teilweise absolut gesehen etwas stärker als es bei DDR noch der Fall war. Da im Gegenzug aber auch die Bandbreiten und Taktraten auf höherem Niveau sind, ändert sich hingegen an den prozentualen Abweichungen fast nichts.

Der DDR2-933 und DDR2-1066 Teiler ist zum Releasezeitpunkt des Sockel AM2 in den Mainboards noch nicht freigeschaltet; allerdings wurde insbesondere der DDR2-1066 Divider dennoch meist schon mit "reserved" im Bios vorgesehen. Zukünftige Bios-Upgrades oder eine zukünftige, offizielle Unterstützung für DDR2-1066 durch AMD werden diese Teiler aber mit hoher Wahrscheinlichkeit verfügbar machen.

DESKTOP PROCESSOR QUICK REFERENCE GUIDE

Alles was man über die zahlreichen Steppings und Core-Versionen des Athlon64 wissen kann.

(Desktop)
http://www.amdcompare.com/us-en/desktop/Default.aspx

(Opteron)
http://www.amdcompare.com/us-en/opteron/Default.aspx


Quelle (xxmartin/Planet 3D Now)http://www.planet3dnow.de/vbulletin/showthread.php?t=182086