AMD liefert bereits M2 Samples - DDR-II ab Q1'06 im Handel

[rkinet]

sieht nicht ganz so rosig aus

http://www.xtremesystems.org/forums/showpost.php?p=1380543&postcount=5

Nur halbe Zeit für Super Pi = doppelte Performance.

Normalerweise bleibt der zweite Core bei diesem Benchmark ungenutzt, vielleicht nutzt der Conroe Funktionseinheiten des zweiten Cores ?


Zu 65nm:

AMD hat bereits heute 65nm DIEs in der Probefertigung, die dürften aber ähnlich wie bei der 90nm Einführung (Winchester = Stepping D0) nur Shrinks der Vorgängerversion = 'F' sein (nur Dual-Core). Ein wirklich erweiterter Core ist dann für 2007 zu erwarten, da der Core ja noch alle Zertifizierungen bei den OEMs durchlaufen muss. Stepping 'F' hat dies ja schon hinter sich gebracht, für einen reinen Shrink geht alles viel zügiger (s. D0=Winchester / D4=1. 90nm Opteron)
Zudem läßt AMD traditionell erst seine Opterone diese lange Prüfphase durchlaufen, damit wirklich nur perfekte Steppings zum Kunden gelangen.

Außerdem ist 2007 bereits DDR-III zu berücksichtigen, was für einen neuen Kern dann passend wäre.
Daher eher eine Zwischenstufe, wobei AMD sicherlich September 2006 = 3. Geb. A64 als 65nm Starttermin anpeilt. Das ist definitiv zu früh für ein grundsätzlich neues Stepping unter Qualitätsgesichtspunkten.

Wie man unten sieht, ist der Core in vielen Bereichen neu strukturiert. Im Vergleich Stepping E/F = trotz Einführung von Pacifia/Virtualisierung sind diese optischen Veränderungen doch sehr auffällig.

 

[mtb][sledgehammer]

Neues AM2 Preview von Anandtech, sieht schon deutlich besser aus. Aber die Bandbreite ist immernoch nicht da, wo man sie erwarten könnte.

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2738&p=1

 

[Dresdenboy]

Nur halbe Zeit für Super Pi = doppelte Performance.

Normalerweise bleibt der zweite Core bei diesem Benchmark ungenutzt, vielleicht nutzt der Conroe Funktionseinheiten des zweiten Cores ?

Verschwendet bitte nicht zuviel Zeit mit Spekulationen anhand von SuperPi-Werten, wo es für A64/Opt. mit 2700-2800 MHz auch Werte von unter 25s gibt. SuperPi nutzt noch x87-Code und ist sehr vom Speicherzugriffen (also auch Caches) abhängig und die verwendeten Big-Number-Routinen (auf FFT oder NTT basierend) sind nicht an aktuelle Cache-Architekturen angepasst. Da können 4 MB nutzbarer L2-Cache deutliche Unterschiede bewirken.


@65 nm-Core-Bild:
Die FP-Recheneinheiten haben sich nicht auffällig verändert. Aber das FP-Registerfile ist jetzt wohl etwas anders designed, evtl. für schnellere Registeradressierung. Und es wurden ja offensichtlich fast alle SRAM-Bänke und ROMs neu designed.

Ansonsten (schrieb auch schon Hans de Vries auf RWT während meiner Abwesenheit): FPU+Integer Decoder zeigen nichts wirklich Neues (also nicht mehr Decoder oder mehr/breitere FP-Recheneinheiten).

Der L2 ist ja schon auf anderen Bildern deutlich kleiner geworden u. anders strukturiert. Vllt. stößt AMD bei einem Single-Core in 65nm ja schon an Grenzen des Packagings, weshalb es günstiger ist, auf dem Die Platz erst einmal frei zu lassen, damit dort wenigstens die Bumps plaziert werden können.
.
.
Edit:

Neues AM2 Preview von Anandtech, sieht schon deutlich besser aus. Aber die Bandbreite ist immernoch nicht da, wo man sie erwarten könnte.

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2738&p=1

Die Bandbreitenmessung hängt ja auch von den Testalgorithmen ab. Bei Sandra waren sie schon höher, aber auch schon fast an den Werten der Cache-Messung..

 

[rkinet]

Ansonsten (schrieb auch schon Hans de Vries auf RWT während meiner Abwesenheit): FPU+Integer Decoder zeigen nichts wirklich Neues (also nicht mehr Decoder oder mehr/breitere FP-Recheneinheiten).

Der L2 ist ja schon auf anderen Bildern deutlich kleiner geworden u. anders strukturiert. Vllt. stößt AMD bei einem Single-Core in 65nm ja schon an Grenzen des Packagings, weshalb es günstiger ist, auf dem Die Platz erst einmal frei zu lassen, damit dort wenigstens die Bumps plaziert werden können.
.
Die Bandbreitenmessung hängt ja auch von den Testalgorithmen ab. Bei Sandra waren sie schon höher, aber auch schon fast an den Werten der Cache-Messung..

a) Bleibt natürlich die Frage, was AMD bereits vor vielen Jahren als mögliche K8 Erweiterung angedacht hatte und jetzt eben umsetzt. Muß dann optisch durchaus nicht mehr auffallen.

b) Die die Einführung der eSiGe Technik dürften sich die Abmessungen der Transistioren im Verhältnis zu den Leiterbahnen verändern. Das hat bei SRAM-Zellen sicherlich deutliche geometrische Veränderungen zur Folge, was dann auch gut sichtbar ist.
Zudem experimentiert AMD lt. eigener Aussage mit ZRAM, obiges Bild könnte so ein Testsample sein (65nm Produktionschips mit nur einem Core - außer Sempron - und viel L2-Cache erscheinen recht unpssend für den Weltmarkt 2007++.

c) Solange keiner der bisherigen Test die Bandbreite von DDR-II 800 auch im Ansatz zeigt, muss man von gedrosselten Samples ausgehen. Erst wenn die ca. 11 GByte/s gemessen werden, sind die anderen Werte überhaupt relevant.

 

[Dresdenboy]

a) Bleibt natürlich die Frage, was AMD bereits vor vielen Jahren als mögliche K8 Erweiterung angedacht hatte und jetzt eben umsetzt. Muß dann optisch durchaus nicht mehr auffallen.

Da hätte Hans de Vries in seinem Artikel sicher schon einen Hinweis gegeben. Und einen 2. DP-FP-Multiplizierer versteckt man nicht einfach so. Höchstens genau unter dem ersten bei verdoppelten Chipherstellungskosten

b) Die die Einführung der eSiGe Technik dürften sich die Abmessungen der Transistioren im Verhältnis zu den Leiterbahnen verändern. Das hat bei SRAM-Zellen sicherlich deutliche geometrische Veränderungen zur Folge, was dann auch gut sichtbar ist.
Zudem experimentiert AMD lt. eigener Aussage mit ZRAM, obiges Bild könnte so ein Testsample sein (65nm Produktionschips mit nur einem Core - außer Sempron - und viel L2-Cache erscheinen recht unpssend für den Weltmarkt 2007++.

Die Caches wurden auch umstrukturiert. Jetzt ist anscheinend auch das Verhältnis zw. eigentlichen SRAM-Zellen und der Steuerlogik besser (war etwa 50:50 beim K8 bis Rev. E). Und speziell die Logikschaltungen hängen auch sehr stark von Leiterbahnenbreiten, -längen usw. ab.

c) Solange keiner der bisherigen Test die Bandbreite von DDR-II 800 auch im Ansatz zeigt, muss man von gedrosselten Samples ausgehen. Erst wenn die ca. 11 GByte/s gemessen werden, sind die anderen Werte überhaupt relevant.

Aber es gab auch schon deutliche Transferrateneinbrüche (gegenüber dem theor. Maximum) bei Tests mit DDR400 vs. DDR480 usw.
(http://aceshardware.com/forums/read_post.jsp?id=115160908&forumid=1)

 

[rkinet]

Aber es gab auch schon deutliche Transferrateneinbrüche (gegenüber dem theor. Maximum) bei Tests mit DDR400 vs. DDR480 usw.
(http://aceshardware.com/forums/read_post.jsp?id=115160908&forumid=1)

Es erscheint doch recht unwahrscheinlich, daß der 'alte' Stepping 'E' Core bei schnellerem RAM mitzieht, während Stepping 'F' plötzlich beim Transfer blockiert.
Zudem hat AMD ja am Memory-Controller (wg. Virtualisierung) kräftig gearbeitet, da erscheinen Einbrüche recht unlogisch.
Nur, AMD dürfte sich kaum das aktuelle Geschäft stören lassen, wenn tolle Werte über die nächste Generation bekannt werden. Intel erlebt ja gerade beim Marktanteil, wie die Leute eben vermeindlich 'alte' Technik nicht mehr so recht kaufen wollen.

Aber in wenigen Tagen / Turion X2 / DDR-II 667 haben wir ja echte Serien-Cores für Benchmarks zur Verfügung. Ich tippe auf eine angenehme positive Überraschung und AMD-typisch ordentliche Transferraten nahe am theoretischen Maximum der Speicheriegel.

 

[xxmartin]

c) Solange keiner der bisherigen Test die Bandbreite von DDR-II 800 auch im Ansatz zeigt, muss man von gedrosselten Samples ausgehen. Erst wenn die ca. 11 GByte/s gemessen werden, sind die anderen Werte überhaupt relevant.

Aber in wenigen Tagen / Turion X2 / DDR-II 667 haben wir ja echte Serien-Cores für Benchmarks zur Verfügung. Ich tippe auf eine angenehme positive Überraschung und AMD-typisch ordentliche Transferraten nahe am theoretischen Maximum der Speicheriegel.

Ich will Dich ungern enttäuschen, aber mittlerweile bezweifle ich stark, daß man auf absehbare Zeit die theoretische DDR2-Bandbreite zu 80-90% ausreizen kann, wie derzeit beim S939 und DDR1. Ich hatte es auch gehofft, aber die Zahlen sprechen eine andere Sprache. Der K8 ist ab einem gewissen Speicherdurchsatz einfach nicht mehr bandbreitenbeschränkt. Zwischen S754 und S939 war das damals noch deutlich anders mit Single Channel vs. Dual Channel. Aber die erneute Verdopplung der verfügbaren Bandbreite wird im Moment einfach nicht ausgenutzt, so daß die Latenzen durchschlagen.

Mich hätten allerdings die Anandtech Benches mit 800 MHz und 3.0-3-3 interessiert. Das wäre dann wirklich extrem interessant geworden.

 

[Kunibert_KA]

Es erscheint doch recht unwahrscheinlich, daß der 'alte' Stepping 'E' Core bei schnellerem RAM mitzieht, während Stepping 'F' plötzlich beim Transfer blockiert.
Zudem hat AMD ja am Memory-Controller (wg. Virtualisierung) kräftig gearbeitet, da erscheinen Einbrüche recht unlogisch.

Es scheint so zu sein, das AMD ein echtes Problem hat. Erst wurde verschoben und jetzt hat von kurz vor der Veröffetnlichung immer noch keine guten Werte. Die Frage ist was das Problem ist und weshalb man es nicht früher erkannt hat bzw es nicht möglich war dieses zu beheben.
Die Frage ist, ob eben durch die Virtualisierung ein Problem dazugekommen ist, oder ob es schon in der Architektur vorhanden war.
Die Effizienz des Memcontrollers ist ja bisher schon nicht mit der Bandbreite gewachsen. Dazu einige Zahlen aus dem Test bei computerbase:
http://www.computerbase.de/artikel/hardware/arbeitsspeicher/2006/bericht_ram_takt_timings/

Ich habe da mal ein paar Werte der synthetischen Benchmarks angesehen.
Das ganze lief auf einem Opteron 146 @3Ghz, der durch den hohen Takt eher mehr von schnelleren RAM bzw Bandbreite profitieren sollte.
Die Zahlen geben Takt/Timing, Theoretische Bandbreite, gemessene Bandbreite und die Effizienz an.
Everest:
200 MHz @ 3,0-4-4-8-2T 6400 5512 86,13
200 MHz @ 3,0-4-4-8-1T 6400 5605 87,58
200 MHz @ 2,0-2-2-5-1T 6400 5954 93,03
250 MHz @ 2,0-2-2-5-1T 8000 7055 88,19
300 MHz @ 3,0-4-4-8-2T 9600 7745 80,68
300 MHz @ 3,0-4-4-8-1T 9600 7798 81,23

SiSoftSandra – RAM Int
200 MHz @ 3,0-4-4-8-2T 6400 4904 76,63
200 MHz @ 3,0-4-4-8-1T 6400 5932 92,69
200 MHz @ 2,0-2-2-5-1T 6400 6023 94,11
250 MHz @ 2,0-2-2-5-1T 8000 7482 93,53
300 MHz @ 3,0-4-4-8-2T 9600 6947 72,36
300 MHz @ 3,0-4-4-8-1T 9600 7975 83,07

PCMark05 – RAM
200 MHz @ 3,0-4-4-8-2T 6400 4279 66,86
200 MHz @ 3,0-4-4-8-1T 6400 4651 72,67
200 MHz @ 2,0-2-2-5-1T 6400 4862 75,97
250 MHz @ 2,0-2-2-5-1T 8000 5316 66,45
300 MHz @ 3,0-4-4-8-2T 9600 5160 53,75
300 MHz @ 3,0-4-4-8-1T 9600 5546 57,77

Bei allen wird die höchste Effizienz bei engen Timings bei 200 MHz erreicht. Höherer Takt bringt trotz scharfer Timings (die bei dem Takt auch eine gute Latenz bedeuten) schlechtere Effizienzwerte.
Das reicht nicht aus die schlechten Werte des AM2 zu erklären, kann aber ein Hinweis darauf sein, das irgendwo eine Engstelle sitzt, die dazu führt das die zusätzliche Bandbreite immer schlechter genutzt werden kann.
Nehmen wir mal den PCMark als Beispiel:
DDR400 @ 3,0-4-4-8-1T
6400 max 4651 eff 72,67%
DDR600 @ 3,0-4-4-8-1T
9600 max 5546 eff 57,77%
DDR2 800
12800 max 6441 eff? 50,03%?
Annahme dabei: DDR400->DDR600 theoretisch 50%=3200 mehr effektiv 895
DDR400 -> DDR2 800 thearetisch 100%=6400 effektiv 2*895

~6500MB/s geht gut in die Richtung die Anandtech und andere gemessen haben.

 

[xxmartin]

kann aber ein Hinweis darauf sein, das irgendwo eine Engstelle sitzt, die dazu führt das die zusätzliche Bandbreite immer schlechter genutzt werden kann

Betrachte es so, daß der Core mit steigender Bandbreite diese einfach nicht weiter nutzen kann. Das ist keine Engstelle sondern schlichtweg "kein Bedarf". Irgendwo sättigt sich das ganze ab. Beziehungsweise der Prozessor kann die Daten nicht schnell genug verarbeiten - die Skalierung von Datenhunger bei steigendem Takt und theoretischer Bandbreite nimmt also ab. Ein Fahrzeug mit 300 PS fährt auch nicht zwangsläufig doppelt so schnell wie eines mit 150 PS. Als Optimist kann man es als üppig vorhandene Leistungsreserven hinsichtlich Quad-Core und dem K8L für den AM2 betrachten.

 

[Kunibert_KA]

Betrachte es so, daß der Core mit steigender Bandbreite diese einfach nicht weiter nutzen kann. Das ist keine Engstelle sondern schlichtweg "kein Bedarf". Irgendwo sättigt sich das ganze ab. Beziehungsweise der Prozessor kann die Daten nicht schnell genug verarbeiten - die Skalierung von Datenhunger bei steigendem Takt und theoretischer Bandbreite nimmt also ab. Ein Fahrzeug mit 300 PS fährt auch nicht zwangsläufig doppelt so schnell wie eines mit 150 PS. Als Optimist kann man es als üppig vorhandene Leistungsreserven hinsichtlich Quad-Core und dem K8L für den AM2 betrachten.

Das der K8 auch als Dualcore zur Zeit kaum Bedarf für diese Bandbreite hat sehe ich auch so. Es geht hier aber um andere Punkte.
1. ein mehr an Bandbreite würde zumindest in einigen Bereichen etwas Performance bringen, die gegenüber dem Conroe wohl nötig sein wird.
2. weshalb ist die Effizient so schlecht? Was bedeutet das für die Zukunft? Was muss geändert werden?
3. Wenn der Quadcore kommt, dann wird man die Bandbreite benötigen. Bis dahin ist auch nicht mehr so viel Zeit. Wenn die schlechte Ausnutzung der Bandbreite an etwas fundamentalem liegt, dann bedeutet das auch zusätzliche große Änderungen am Kern, wenn man nicht das Risiko eingehen will, das der Quad wegen fehlender Bandbreite verhungert.

Wie gesagt, beim AM2 K8 wird das für die reale Performance wohl nicht so viel ausmachen, für den K8L oder andere Quads wird es aber ein Problem werden können.
Bei vielen Nutzern hätte man mit hoher Bandbreite (ob sinnvoll oder nicht) auch marketingmässig Punkten können. Da man es aber trotz Verschiebung nicht hinbekommen hat, scheint es ja etwas fundamentaleres zu sein, was bei mir hinsichtlich der Zukunft eben die Frage aufwirft ob man es bis zu den Bandbreitenhungrigeren CPUs gelöst bekommt.

 

[voodoo44]

Betrachte es so, daß der Core mit steigender Bandbreite diese einfach nicht weiter nutzen kann. Das ist keine Engstelle sondern schlichtweg "kein Bedarf". Irgendwo sättigt sich das ganze ab. Beziehungsweise der Prozessor kann die Daten nicht schnell genug verarbeiten - die Skalierung von Datenhunger bei steigendem Takt und theoretischer Bandbreite nimmt also ab. Ein Fahrzeug mit 300 PS fährt auch nicht zwangsläufig doppelt so schnell wie eines mit 150 PS. Als Optimist kann man es als üppig vorhandene Leistungsreserven hinsichtlich Quad-Core und dem K8L für den AM2 betrachten.

Sorry, wenn ich mich grad in die Diskussion einmische (hab von dem Thema eh nicht so Ahnung wie ihr...fühl mic hrichtig dumm gegenüber euch :|) aber - der Vergleich Hinkt, beim Auto braucht man 8mal soviel PS, da man einen steigenden luftwiderstand hat...
gibts sowas bei prozessoren auch?

 

[mtb][sledgehammer]

Interessant wäre es ja mal gewesen, wenn die Jungs mit nur einem DDR2 Modul (vs Dual Channel DDR) getestet hätten. Gleiche bandbreite, vergleichbare Timings - was bringt das an Performance?

 

[xxmartin]

Sorry, wenn ich mich grad in die Diskussion einmische (hab von dem Thema eh nicht so Ahnung wie ihr...fühl mic hrichtig dumm gegenüber euch :|) aber - der Vergleich Hinkt, beim Auto braucht man 8mal soviel PS, da man einen steigenden luftwiderstand hat...
gibts sowas bei prozessoren auch?

Dann hast Du mein Posting nicht ganz verstanden.

Interessant wäre es ja mal gewesen, wenn die Jungs mit nur einem DDR2 Modul (vs Dual Channel DDR) getestet hätten. Gleiche bandbreite, vergleichbare Timings - was bringt das an Performance?

Jo, ist auch interessant. Aber allein der Test bei gleichen Timings wäre schon super gewesen. Die OCZ schaffen 800 MHz mit 3.0-3-3-8 locker - nur das Testboard erlaubte nicht, die Timings zu verstellen. Denn DDR2-800 sollte jeden DDR1 mit "400 MHz" (sprich den üblichen 200 MHz) bei gleichen 3.0-3-3-8 Timings gehörig deklassieren. Dann hätte man definitiv überall ein "+" vor den Prozenten und wäre im Schnitt vermutlich auch mehr in Richtung 5-10% Zugewinn.

Von daher bleibt nur abwarten auf die ersten final Boards, insbesondere von DFI, wo man dann alles bis ans Limit tweaken kann.

 

[rkinet]

Die Frage ist, ob eben durch die Virtualisierung ein Problem dazugekommen ist, oder ob es schon in der Architektur vorhanden war.

Das reicht nicht aus die schlechten Werte des AM2 zu erklären, kann aber ein Hinweis darauf sein, das irgendwo eine Engstelle sitzt, die dazu führt das die zusätzliche Bandbreite immer schlechter genutzt werden kann.

a) Der Aspekt 'Virtualisierung' ist natürlich zu beachten, aber erklärt nicht das Limit bei recht genau DDR-II 400 Dual-Channel.

b) Es gab Gerüchte über einen Bug im Memorycontroller, man kann dies aber auch als Drosselung vielleicht im Zusammenhang mit der Beta-Version der Virtualisierung betrachten.

Es gibt keinen erkennbaren technischen Grund, daß beim K8 auf So.AM2 im Vergleich zu So.939 ein Limit entstanden ist. Ich bleibe dabei, es sieht nach Absicht im Zusammenhang mit den ersten Samples aus. Aber ab 9.5. gibts ja den Turion X2 (incl. Virtualisierung/ DDR-II 667), dann haben wir ja echte Serien-CPUs zum Vergleich.

 

[Reisi]

Aber allein der Test bei gleichen Timings wäre schon super gewesen. Die OCZ schaffen 800 MHz mit 3.0-3-3-8 locker - nur das Testboard erlaubte nicht, die Timings zu verstellen. Denn DDR2-800 sollte jeden DDR1 mit "400 MHz" (sprich den üblichen 200 MHz) bei gleichen 3.0-3-3-8 Timings gehörig deklassieren. Dann hätte man definitiv überall ein "+" vor den Prozenten und wäre im Schnitt vermutlich auch mehr in Richtung 5-10% Zugewinn.

Die Timings waren doch (fast) gleich, zumindest aus absoluter Sicht. Dass DDR2-800 mit 3-3-3 schneller sind als DDR-400 mit 3-3-3 ist logisch, da dann eben nicht nur ein Vorteil in der Bandbreite vorhanden ist, sondern auch bei den Latenzen.

Weiß eigentlich irgendjemand mit welchen CPU-Takt da gebencht wurde? Ich frag mich da schon mit welchem Takt der Speicher läuft. Bei den aktuellen Athlons ist der Speicherteiler immer ganzzahlig, so dass beide Taktflanken des Speichers immer synchron mit Taktflanken der CPU sind. Beim AM2 sind die CPU Taktunterschiede nach wie vor bei 200 MHz, wenn der Speicher immer mit 400 MHz arbeitet, würde das aber bedeuten, dass auch nicht ganzzahlige Speicherteiler zum Einsatz kommen und dadurch nciht mehr beide Taktflanken synchron sind.

 

[xxmartin]

Die Timings waren doch (fast) gleich, zumindest aus absoluter Sicht. Dass DDR2-800 mit 3-3-3 schneller sind als DDR-400 mit 3-3-3 ist logisch, da dann eben nicht nur ein Vorteil in der Bandbreite vorhanden ist, sondern auch bei den Latenzen.

Ja, aber eben genau da wäre der Performanceunterschied doch am entscheidensten. Denn schließlich soll der AM2 ein Upgrade sein. Und wenn DDR2-800 mit 3.0-3-3-8 sagen wir durchweg ~10% Vorteil bringen gegenüber DDR1-400 3.0-3-3-8, dann ist das schon mehr als nur ein "Kosmetikupgrade".

Weiß eigentlich irgendjemand mit welchen CPU-Takt da gebencht wurde?

X2 4800+, also 2*2400 MHz mit 2*1M.

Ich frag mich da schon mit welchem Takt der Speicher läuft. Bei den aktuellen Athlons ist der Speicherteiler immer ganzzahlig, so dass beide Taktflanken des Speichers immer synchron mit Taktflanken der CPU sind. Beim AM2 sind die CPU Taktunterschiede nach wie vor bei 200 MHz, wenn der Speicher immer mit 400 MHz arbeitet, würde das aber bedeuten, dass auch nicht ganzzahlige Speicherteiler zum Einsatz kommen und dadurch nciht mehr beide Taktflanken synchron sind.

DDR2 ist die Datenrate vierfach (4 Bits pro Takt), bei DDR1 nur zweifach (2 Bits pro Takt).

Dementsprechend ist DDR2-800 im Endeffekt 200 MHz Grundtakt * 4 und somit kannst Du weiterhin ganzzahlige Teiler verwenden. Nur für DDR2-666, DDR2-533 und sonstige "krumme" Takte wird wieder abgerundet werden. Es bleibt also weiterhin bei ganzzahligen Speicherteilern.

 

[Reisi]

Ja, aber eben genau da wäre der Performanceunterschied doch am entscheidensten. Denn schließlich soll der AM2 ein Upgrade sein. Und wenn DDR2-800 mit 3.0-3-3-8 sagen wir durchweg ~10% Vorteil bringen gegenüber DDR1-400 3.0-3-3-8, dann ist das schon mehr als nur ein "Kosmetikupgrade".

Ok, aber die eigentliche Frage ist doch, was bringt DDR2, nicht was bringen niedrige Latenzen

DDR2 ist die Datenrate vierfach (4 Bits pro Takt), bei DDR1 nur zweifach (2 Bits pro Takt).

Dementsprechend ist DDR2-800 im Endeffekt 200 MHz Grundtakt * 4 und somit kannst Du weiterhin ganzzahlige Teiler verwenden. Nur für DDR2-666, DDR2-533 und sonstige "krumme" Takte wird wieder abgerundet werden. Es bleibt also weiterhin bei ganzzahligen Speicherteilern.

Dem Speichercontroller interessiert der Speicherzellentakt aber gar nicht. Der kommuniziert ja nur mit dem I/O-Buffer, und der hat eben 400 MHz.

 

[xxmartin]

Ok, aber die eigentliche Frage ist doch, was bringt DDR2, nicht was bringen niedrige Latenzen

DDR2 bringt höhere mögliche Taktraten.

Das Auto fährt in rot nicht schneller als in gelb.

DDR1-400 3.0-3-3-8 sollte theoretisch auf selbem Niveau liegen können wie DDR2-400 3.0-3-3-8. Das dem allerdings nicht so ist, liegt somit an anderen Dingen (Protokoll-Overhead, anderer Chipaufbau, etc.).

Von daher kann man eben nur die höheren Taktraten vergleichen - ein 1:1 Vergleich ist somit zweckfrei, da er schon von der puren Logik her keinen Unterschied bringen kann. Ein FX-60 ist bei 1.8 GHz eben genauso flott wie ein Opteron 165 bei 1.8 GHz. Nur, daß der FX-60 eben mehr Takt kann. Und DDR2 hat eben auch deutlich mehr Luft nach oben als DDR1.

Dem Speichercontroller interessiert der Speicherzellentakt aber gar nicht. Der kommuniziert ja nur mit dem I/O-Buffer, und der hat eben 400 MHz.

Ist trotzdem nicht relevant, da der Referenztakt des Systems weiterhin bei 200 MHz bleibt. Und nur selbigen stellt man ein (sonst müßte man auch die Hypertransport-Berechnung via LDT sowie CPU-Taktfrequenz-Berechnung umstellen und das ist nahezu ausgeschlossen). Ob der Speichertakt intern dann noch verdoppelt angelegt wird, ist reine Betrachtungssache. Eingestellt werden weiterhin Regionen von 133-250 MHz, die dann am Ende *4 am Speicher ankommen - da bin ich mir ziemlich sicher.

 

[Reisi]

Ist trotzdem nicht relevant, da der Referenztakt des Systems weiterhin bei 200 MHz bleibt. Und nur selbigen stellt man ein (sonst müßte man auch die Hypertransport-Berechnung via LDT sowie CPU-Taktfrequenz-Berechnung umstellen und das ist nahezu ausgeschlossen). Ob der Speichertakt intern dann noch verdoppelt angelegt wird, ist reine Betrachtungssache. Eingestellt werden weiterhin Regionen von 133-250 MHz, die dann am Ende *4 am Speicher ankommen - da bin ich mir ziemlich sicher.

Es geht mir nicht darum, wie der Takt erzeugt wird, es geht mir nur um die Datenübertragung. Hier ist es Fakt, dass bei DDR2-800 die Daten mit 400 MHz übertragen werden. Bei einem CPU Takt von z.B. 2,2 oder 2,6 GHz ist somit immer eine Taktflanke nicht synchron. Diese Szenario hatte man bis jetzt nicht, da der Speicherteiler immer ein ganzzahliger Teiler des CPU Taktes war. Die Frage (für mich) ist jetzt, ob diese eine nicht synchrone Flanke jetzt irgendwelche Leistungseinbußen mit sich zieht, oder ob das kein Problem ist, oder ob bei diesen Taktfrequenzen der Speicher gar nicht mit 400 MHz läuft.

 

[Dresdenboy]

Hier noch eine interessante Antwort von David Wang (bekannt von Artikeln auf Realworldtech) zu dem Thema:
http://realworldtech.com/forums/ind...PostNum=4269&Thread=2&entryID=65733&roomID=11

 

[Kunibert_KA]

Hier noch eine interessante Antwort von David Wang (bekannt von Artikeln auf Realworldtech) zu dem Thema:
http://realworldtech.com/forums/ind...PostNum=4269&Thread=2&entryID=65733&roomID=11

Ja das ist auf jeden Fall eine Erklärung. Ich möchte aber doch noch mal ein paar Zahlen einwerfen.
In der Erklärung oben geht es ja darum warum der AM2 mit DDR2 nicht die Effizienz erreicht.
Wenn ich mir aber die Zahlen ansehe, dann ist das schon beim S939 mit DDR so. Beim AM2 tritt es wohl stärker in Erscheinung, da der Controller noch nicht so ausgereift wie der des S939(DDR) ist.
Quelle: x-bit labs
Memory: Patriot PDC1G5600ELK (PC5600)
Board: DFI LANParty UT NF4 Ultra-D
CPU: AMD Athlon 64 FX-57 CPU (Socket 939, 2.8GHz, 1024KB L2 cache, San Diego core)

ScienceMark Mem:
Takt/Timings Max. Effektiv %
DDR400 @ 2,0-2-2-10-1T 6400 5664 88,5
DDR430 @ 2-2-2-10-1T 6880 6031 87,66
DDR466 @ 2-2-2-10-1T 7456 6464 86,7
DDR510 @2.5-3-3-10-1T 8160 6894 84,49
DDR560 @2,5-4-4-10-1T 8960 7128 79,55
DDR622 @3-4-4-10-1T 9952 7290 73,25
DDR700 @3-5-5-10-2T 11200 6951 62,06

Um es noch etwas deutlicher zu machen, hier die zusätzliche Bandbreite und was davon ankommt:
Takt / Timings Max +max. +eff. %
DDR400 @ 2,0-2-2-10-1T 6400
DDR430 @ 2-2-2-10-1T 6880 480 367 76,46
DDR466 @ 2-2-2-10-1T 7456 576 433 75,17
DDR510 @2.5-3-3-10-1T 8160 704 430 61,08
DDR560 @2,5-4-4-10-1T 8960 800 234 29,25
DDR622 @3-4-4-10-1T 9952 992 162 16,33
DDR700 @3-5-5-10-2T 11200 1248 -339 -27,16

Wie man sieht bricht auch der S939 DDR1 Controller bei höherer Bandbreite sehr deutlich ein.
Es kann also nicht nur am AM2 / DDR2-Controller liegen!
Was ist hier der limitierende Faktor?
Ich habe hier ja den Cache im Verdacht.
Alles was über den Memcontroller geladen wird, muss ja auch in den Cache geschoben werden. Diser hat aber auch eine begrenzte Bandbreite und eine Latenz.
Beispiel:
Bei einem Takt von 1,8 Ghz beträgt die Theoretische Bandbreite 14400 MB/s
Effektiv werden aber 8260 gemessen. Das bedeutet er nutzt 57,36% der theoretischen Bandbreite aus.
Bei einem Takt von 2,4Ghz beträgt die theor. Bandbreite 19200 MB/s, gemesen wurden mit ScienceMark 8833 MB/s, was eine Ausnutzung der Bandbreite von 46% bedeutet.

Damit will ich sagen, das wenn die Benchmarks nur einen Kern nutzen, die Daten auch nur in einen L2-Cache geschrieben werden. Dieser hat zur Zeit aber nicht die nötige Bandbreite um die Daten des Memcontrolers anzunehmen. Immerhin sind ja durch den Benchmark ja auch Zugriffe auf den L2 zu verzeichnen, die die für den Memcontroller nutzbare Bandbreite des L2 weiter einschränken (FSB-Dilemma).

Um festzustellen ob der Cache der limitierende Faktor ist, müsste man den RAM mal bei verschiedenen Taktraten der CPU testen, da ja die Bandbreite des L2 mit der CPU skaliert.

Ergebnis: Wenn ein Benchmark beide Kerne und damit beide L2s nutzt könnte die Bandbreite die wir beim Memcontroller sehen deutlich höher sein.
AMD sollte die Bandbreite des L2 von 64+64 erhöhen auf 128, was auch besser zu den 128 bit SSE passen würde. So müssen für eine 128 bit SSE Instruktion 2 Cachelines gelesen werden.

 

[RPGILE]

Bei Anandtech gibt es einen neuen Artikel bzgl. AM2 und DDR2 Performance

www.anandtech.com/cpuchipsets/showdoc.aspx?i=2741

 

[rkinet]

Bei Anandtech gibt es einen neuen Artikel bzgl. AM2 und DDR2 Performance

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2741&p=3

'Everege Latency' ist bei DDR-II wirklich auf Bestmarke, dafür klemmt es sichtbar an der Transferleistung des Speichers.
Sowas nennt man Drosselung, mal sehen weshalb AMD dies macht.

Erste So.AM2 CPUs gelistet
http://www.theinquirer.net/?article=31022
https://usm.channelonline.com/ntw/s...tarts_with&search_type=ds_products_ss

Stepping F = 'CN' = Single Core,
Stepping F = 'CU' = Dual Core 2* 512k,
Stepping F = 'CS' = Dual Core 2* 1024k

Die Preise sind beim A64 recht hoch, die So.AM2 Semprone aber auf normalem Niveau.

 

[Crashman]

Sowas nennt man Drosselung, mal sehen weshalb AMD dies macht.

Ich glaub so langsam solltest auch du anerkennen, dass da einfach net mehr geht und der AM2 keinen riesigen Schub bringen wird.

 

[Denniss]

Ich glaub so langsam solltest auch du anerkennen, dass da einfach net mehr geht und der AM2 keinen riesigen Schub bringen wird.

Solche Kommentare bringen rein gar nichts.

Was der AM2 wirklich kann (oder nicht) sagt Dir das Licht (erfahren wir bei der offiziellen Vorstellung der CPU). Von irgendwelchen Vorserienmustern auf die Geschwindigkeit des Endprodukts zu schließen muß nicht immer richtig sein obwohl es durchaus schonmal Anhaltspunkte setzen kann.