AMD Zen - 14nm, 8 Kerne, 95W TDP & DDR4?

Der Interposer allgemein ist einfach nur ein Träger von verschiedenen Dies. Da gibt's aktive mit Logik (Arbiter, Scheduler etc) und welche die einfach passiv sind und "durchkontaktieren" bzw. verdrahten. Ich denke bei Fiji werden wir einen passiven sehen der keinerlei Logik beinhaltet. Kombiniert man CPU & GPU auf einem Interposer mit HBM hat man fette Bandbreite bei sehr geringen Latenzen. Der muss dann aber aktiv sein.
 
Interposer gibt es viele verschiedene Typen, von einfachen Leiterplatten hin zu silicium Interposern.

interposer.jpg
Interessant die µBumps. Dadurch sind wesentlich mehr Kontakte als herkömmlich auf einem Die realisierbar.
Die High Bandwidth Connections zwischen 2 Dies benötigen auch keine großartigen Ausgangstreiber, spart also Chipfläche.
Dadurch, dass Leitungen im Interposer geroutet werden, spart man bei der Herstellung eines Dies eventuell noch eine Metallage, eine Maske weniger.
Der Interposer selbst kann günstig im altem 65nm Prozess gefertigt werden.

Hat also schon ein paar Vorteile. Bleibt nur noch die Frage, wie ausgereift die Technik mittlerweile ist und ob es sich im Gesamtpaket lohnt einen Interposer und kleinere einfachere Dies zu verwenden oder mehrere ICs herkömmlich mit jeweils eigenem Maskensatz, da werden für jeden Prozessschritt des Dies eine Maske benötigt also ca. 60 Masken für etwas komplexeres.

--- Update ---

Kombiniert man CPU & GPU auf einem Interposer mit HBM hat man fette Bandbreite bei sehr geringen Latenzen. Der muss dann aber aktiv sein.
Wieso muss der aktiv sein?
 
Interposer gibt es viele verschiedene Typen, von einfachen Leiterplatten hin zu silicium Interposern.
Hat also schon ein paar Vorteile. Bleibt nur noch die Frage, wie ausgereift die Technik mittlerweile ist und ob es sich im Gesamtpaket lohnt einen Interposer und kleinere einfachere Dies zu verwenden oder mehrere ICs herkömmlich mit jeweils eigenem Maskensatz, da werden für jeden Prozessschritt des Dies eine Maske benötigt also ca. 60 Masken für etwas komplexeres.
Bei kleinen einfachen untis, komme ich auf 256 Threads oder 64 Cores in Summe mit 4P.!?
 
Also ein Seitenfehler tritt eigentlich nur auf wenn ein Programm auf einen Speicherbereich zugreift der nicht physisch im DRAM gespeichert ist. Ist also eher Softwaresache. Ich habe hier keinen AMD zum Vergleich, aber mein System produziert nur bei einigen Programmen permanent Seitenfehler. Kann an schlampiger Programmierung liegen (z. B. Steelseries-Software hat schon nach wenigen Minuten ~2 Mio Pagefaults) oder einfach an Windows' MMU die es nicht hinbekommt 16 GB auszunutzen bevor swapping statt findet.
Mich interessiert jetzt wirklich dein Link. Vielleicht reden wir gerade von zwei verschiedenen Dingen.

Ich sage einfach mal Bullshit, pagefaults haben in der Regel nix mit schlechter Programierung zu tun. Lesen und schreiben nach einen mmap() erzeugt pagefaults ohne Ende.
 
Rückwirkend betrachtet geht aus meinem Beitrag nicht hervor dass ich die blöde Steelseries-Software meinte. Da kann ich mir nämlich nicht erklären warum bei 86 Sekunden CPU-Zeit, 50 Mio Pagefault bei 8 MB I/O zustande kommen. Das beschäftigt mich aktuell nämlich etwas. Woran das liegt weiß ich einfach nicht.


Generell sind Pagefaults aber keine große Sache oder etwas ausergewöhnliches, stimmt. Ich weiß auch nicht ob das mit AMD <-> Intel wirklich so stimmt *noahnung*
 
Was offenbar einige bei dieser Speicherfehlerdiskussion verwechseln: Pagefaults sind keine Fehler in dem Sinne, daß was kaputt ist, sondern das heißt nur, daß Daten nicht dort vorhanden sind, wo man sie sucht, und daher die nächste Ebene durchsucht werden muß (L1->L2->L3->RAM->Festplatte...), also "fault" im Sinne "Fehlgriff" oder "Griff ins Leere". Aber was da (http://www.planet3dnow.de/vbulletin/showthread.php?p=5004544#post5004544) gelistet wurde, waren Bitflips, also tatsächliche RAM-Fehler, wo die Daten eben nicht so rauskommen, wie sie gespeichert wurden, sondern sich spontan verändert haben (durch was auch immer, Fertigungsfehler, auch radioaktive Strahlung auf die Speicherzellen kann sowas verursachen). Also bitte nicht verwechseln!
 
Es geht hier um die Bitflips auf benachbarten RAM-Bänken, die ja auch als Sicherheitsrisiko identifiziert wurden. Hier gibt es eine ausführliche Studie mit Messungen zu Piledriver, Sandy Bridge, Ivy Bridge und Haswell:
http://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf

attachment.php


Hier ist ein Unterschied um dem Faktor 1000 zwischen den Intel Controllern und AMDs Implementierung.

Möglicherweise ist das Speicherinterface von Intel einfach nur schneller, die Rowhammer Geschichte hat was mit der Schreibgeschwindigkeit mit tun.

--- Update ---

Rückwirkend betrachtet geht aus meinem Beitrag nicht hervor dass ich die blöde Steelseries-Software meinte. Da kann ich mir nämlich nicht erklären warum bei 86 Sekunden CPU-Zeit, 50 Mio Pagefault bei 8 MB I/O zustande kommen. Das beschäftigt mich aktuell nämlich etwas. Woran das liegt weiß ich einfach nicht.


Generell sind Pagefaults aber keine große Sache oder etwas ausergewöhnliches, stimmt. Ich weiß auch nicht ob das mit AMD <-> Intel wirklich so stimmt *noahnung*

Was ist das den für eine lustige Software? Was macht die?
 
Möglicherweise ist das Speicherinterface von Intel einfach nur schneller, die Rowhammer Geschichte hat was mit der Schreibgeschwindigkeit mit tun.
Das ist nicht sehr wahrscheinlich. AMD kommt mit höher getakteten RAM auch zu höheren Leistungen. Bei Intel ist meist ab 1800er Ram keine Leistungsteigerung mehr zu sehen.
 
Möglicherweise ist das Speicherinterface von Intel einfach nur schneller...
Die DRAM Frequenz ist natürlich ein maßgeblicher Faktor für Bitfehler. Umso höher der Takt, umso eher treten gekippte Bits auf. Insbesondere bei DDR3L und anderen Stromsparvarianten. Ich gehe jedoch davon aus, dass die Forscher dieselben Timings auf allen Systemen verwendet haben, um ansatzweise eine Vergleichbarkeit sicher zu stellen. Das geht zwar nicht aus dem Text hervor, aber alles andere wäre unsinnig. Insofern wäre es durchaus möglich, dass Intel Prozessoren durch die Art und Weise, wie schreibende DRAM Zugriffe bei ihnen erfolgen, im Vergleich anfälliger sind. Womöglich erzeugen AMD Prozessoren tatsächlich Zugriffsmuster, die weniger störanfällig sind. Jedoch spielt dies für die Praxis keine entscheidende Rolle. Alle Studien haben bisher belegt, dass die Hauptplatine und natürlich der DRAM selbst die mit Abstand größten Fehlerquellen sind. Die CPU kann allenfalls noch das Zünglein an der Waage sein; spielt jedoch eine untergeordnete Rolle. Andernfalls wäre die Dominanz der Xeons längst gebrochen und die Opterons befänden sich auf dem aufsteigenden Ast.
 
Zuletzt bearbeitet:
Naja bei den Server-CPUs ists aufgrund ECC sowieso egal, da tritt das Problem nicht auf.
ECC soll als Netz und doppelter Boden dienen. Jede Häufung von Speicherfehlern (im Log) würde früher oder später eine Spurensuche auslösen. Wenn es auf Xeon Systemen bis zu tausend Mal mehr Speicherfehler als bei Opteronen Systemen geben würde, bliebe das nicht unbemerkt. Wie gesagt sind Hauptplatine und die Speichermodule selbst von größerer Bedeutung als die eingesetzten CPUs. Die Opterons können sich hier keinen Vorteil gegenüber den Xeons erarbeiten. Andererseits fallen sie genauso wenig hinter sie zurück. Im Serveralltag liegen sie im Rahmen der üblichen Streuung auf einem Level.
 
Wenn die Häufung aber erwartet und bekannt ist und durch ECC kompensiert wird, gehen keine Alarme los.

Hier ist auch ein komplettes beschreiben des Exploits basierend auf der Forschungsarbeit.
Es wird Projct Zero genannt und zeigt detailiert wie es dazu kommt. Interessant hierbei scheint zu sein, dass bei höheren Frequenzen diese bitflips weniger werden, da wohl eine mindest Refreshzeit von 32ms nötig sein sollen um einen bitflip zu verursachen. Man kann sogar dort ein Testtool für den eigenen Rechner runterladen.
http://googleprojectzero.blogspot.de/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
Testing your own machine

Users may wish to test their own machines using the rowhammer-test tool above. If a machine produces bit flips during testing, users may wish to adjust security and trust decisions regarding the machine accordingly.

While an absence of bit flips during testing on a given machine does not automatically imply safety, it does provide some baseline assurance that causing bit flips is at least difficult on that machine.
BIOS updates and increasing refresh rates

Have hardware vendors silently rolled out any BIOS updates to mitigate the rowhammer problem by changing how the BIOS configures the CPU’s memory controller?

As an experiment, we measured the time required to cause a bit flip via double-sided hammering on one Model #4 laptop. This ran in the “less than 5 minutes” range. Then we updated the laptop’s BIOS to the latest version and re-ran the hammering test.

We initially thought this BIOS update had fixed the issue. However, after almost 40 minutes of sequentially hammering memory, some locations exhibited bit flips.

We conjecture that the BIOS update increased the DRAM refresh rate, making it harder — but not impossible — to cause enough disturbance between DRAM refresh cycles. This fits with data from Yoongu Kim et al’s paper (see Figure 4) which shows that, for some DRAM modules, a refresh period of 32ms is not short enough to reduce the error rate to zero.

We have not done a wider test of BIOS updates on other laptops.

Edit: Dieses Tool sollte eigentlich in jede "Toolbox" einer Hardwareredaktion gehören. Gibt es noch RAM-Tests? Man sieht ja da kaum noch ausführliches im Netz.
 
Zuletzt bearbeitet:
Interessant hierbei scheint zu sein, dass bei höheren Frequenzen diese bitflips weniger werden...
Bei steigendem Takt ereignen sich die meisten Bitfehler nicht in den DRAM Zellen, sondern durch das Rauschen auf dem (teils ungeschützten) Speicherbus. Durch die engen JEDEC Vorgaben hat man wenig Optionen dem beispielsweise durch stärkere Treiber entgegen zu wirken und sich auf diese Weise von der Konkurrenz abzuheben. Was der Standard zulässt, wird sowohl von Intel als auch AMD - so sagt man - vollumfänglich ausgeschöpft.
Wenn die Häufung aber erwartet und bekannt ist und durch ECC kompensiert wird, gehen keine Alarme los.
Jeder Speicherfehler (ob single-bit oder multi-bit) wird protokolliert. Die Auswertung und daraus zu ziehende Schlüsse obliegen dem zuständigen Administrator. Mir sind an dieser Stelle keine Unterschiede zwischen Xeon und Opteron Systemen bekannt. Die Gewichtung von Bitfehlern ist stets dieselbe. Man drückt bei einer Intel Plattform nicht beide Augen zu. Bei den RAS Features werden traditionell keinerlei Zugeständnisse gemacht.
 
Zuletzt bearbeitet:
Man sieht generell kaum noch Tests die der Hardware auf den Zahn fühlen. Das war früher (gefühlt) anders.
Hängt aber sicher auch damit zusammen, dass man mit langen Balken und reißerischen Artikeln mehr Aufmerksamkeit bekommt als mit guter Recherche.
 
Bei steigendem Takt ereignen sich die meisten Bitfehler nicht in den DRAM Zellen, sondern durch das Rauschen auf dem (teils ungeschützten) Speicherbus. Durch die engen JEDEC Vorgaben hat man wenig Optionen dem beispielsweise durch stärkere Treiber entgegen zu wirken und sich auf diese Weise von der Konkurrenz abzuheben. Was der Standard zulässt, wird sowohl von Intel als auch AMD - so sagt man - vollumfänglich ausgeschöpft.
Jeder Speicherfehler (ob single-bit oder multi-bit) wird protokolliert. Die Auswertung und daraus zu ziehende Schlüsse obliegen dem zuständigen Administrator. Mir sind an dieser Stelle keine Unterschiede zwischen Xeon und Opteron Systemen bekannt. Die Gewichtung von Bitfehlern ist stets dieselbe. Man drückt bei einer Intel Plattform nicht beide Augen zu. Bei den RAS Features werden traditionell keinerlei Zugeständnisse gemacht.

Inwiefern widerspricht das den zitierten stellen von mir? Ich schreibe hier die ganze Zeit von dem Rowhammer bitflip. Was dein Bus-Rauschen da zu suchen hat ist unklar.

Und eine vollumfängliche Protokollierung ist die Grundvorraussetzung um einen Alalrm auszulösen bei fehlerhaften Systemen. Ich schrieb, dass die Intel bitflips durchaus innerhalb der Parameter liegen können wenn ECC diese ausgleicht. Wenn ich weiss was mein System tut, dann muss ich auch nichts ändern, auch wenn AMD da niedrigere Werte hat, dies in der Praxis letztendlich aber keine Rolle spielt wenn ECC zum Einsatz kommt.
 
"So schlecht nicht" reicht aber nun mal nicht, wenn man ein deutliches Update gegenüber Kaveri bieten will.
Wer sagt, dass man das will? Richland war auch nur ein laues Update ... große Sprünge gibts aktuell eigentlich nie, das ist immer ne sukzessive, langsame Verbesserung, Intel machts auch nicht anders. Für sowas würden schon die 32kB von Excavator reichen, zusammen mit der besseren GPU-Leistung aufgrund DDR4 ist das ne außreichend-schöne Kombination, besser als Richland allemal.

Performance und Leistungsaufnahme. Was sonst? Verrate mir doch mal, wie Carrizo mit 5% mehr IPC ein lohnenswertes CPU Update erhalten soll, wenn bei 95W TDP die Taktraten nicht erhöht werden können bzw vielleicht sogar um einige Prozent sinken.
Erstens sprechen wir von ner APU, eine reine Betrachtung der CPU ist also wenig zweckmäßig, zweitens rechne ich nicht mit weniger Taktrate, die Kurve auf die Du Dich beziehst ist ohne AVFS- wie schon besagt. Die mit AVFS ist flacher, würde sie im Diagramm konstant weitergezeichnet sein, wäre man *unter* der Kaverilinie, ergo besser.

Versteh mich nicht falsch. Mit einem Desktop Carrizo wäre sicherlich CPU- und GPU-seitig ein Update möglich wie von Richland auf Kaveri, eventuell sogar etwas mehr.
Ok, dann verstehen wir uns zumindest in dem Punkt.
Nur, inwiefern lohnt sich das denn noch, wenn man eben auch eine Zen APU vielleicht Mitte 2016 am Start haben könnte? Klar, wenn man davon ausgeht, dass so eine APU erst 2017 kommt, dann könnte man zumindest mit Carrizo noch 2016 überbrücken. Aber ich gehe davon aus, dass man Zen früher launchen will.
Das ist abermals der Punkt zwischen "AMD bräuchte" und "AMD kann" ... keine Frage, AMD bräucht Zen am besten gestern, aber wenns nicht geht, gehts einfach nicht.

Könnte AMD also wirklich Mitte 2016 eine ZEN-APU haben? Theoretisch vielleicht, aber praktisch sage ich nein, das Risiko wäre aus meiner Sicht zu groß. Wir reden über neuen Speicher, neue Plattform und über eine neue Architektur. Natürlich wäre es schön, wenn AMD in einem Rundumschlag alles erneuert. Aber was passiert wenn auch nur ein halbschwerer Bug auftritt? Dann säße man tief in der Sch....e. In Anbetracht von AMDs Finanzlage nicht erstrebenswert.

Wenn die Roadmap wider Erwarten doch echt sein sollte, dann kann man das im Umkehrschluss als Hinweis werten, dass AMD bereits jetzt dicke Probleme hat und aus Verzweiflung so nen aggressiven Launch plant, schlicht da man den Erfolg/das Geld braucht. Wenns schief geht übernimmt dann halt Samsung, oder wer ist der aktuelle Favorit bei den immer wieder neuen Übernahmegerüchten?

Mit HBM und mehr Shadern wäre trotzdem nochmal ein ganz anderer Leistungssprung möglich.
Klar und dann am besten doppelt und dreifach soviel HBM-Speicher und in 5nm mit SOI und 100MB Z-RAM cache, da wären ganz andere Leistungssprünge drin ;)
Ist halt immer Wunschdenken <> Wirklichkeit ...


Also das kann und darf nun wirklich keine Ausrede sein. Man hatte lange genug Zeit. FM2(+) ist jetzt wie alt? 3 Jahre? AM3(+) ist noch deutlich älter. Da wird man wohl in der Lage sein, endlich eine neue Desktopplattform zu bringen. So oder so, das müsste man auch bei deinem DDR4 Carrizo.
Natürlich muss ne neue Plattform her, das ist doch nicht der Punkt, der Punkt ist der, dass da wieder Bugs auftreten können. Der logische Schritt ist, dass man bewährte Technik nimmt (28nm+Excavator) und mit der die neue Plattform in Gang setzt. Es gibt ja nicht nur getrennte Plattform- und Architektur-Bugs sondern auch Bugs die nur bei best. Kombinationen auftauchen ... deswegen will keiner freiwillig ne neue Plattform samt neuer Kern- und Speicherarchitektur debuggen. Wenn da was schief geht hast Du 6 Möglichkeiten an was es liegen könnte .. viel Spass bei der Ursachenforschung...

Eine Zen APU Q2/3 und eine Zen CPU ein Quartal später würde auch Sinn machen. Von mir aus auch umgekehrt. Machbar ist das. Und bis dahin muss halt der Kaveri Refresh noch durchhalten.
Machbar wäre es - wenn die Zens auf den jeweils gleichen Stand wären. Will man aber v.a. bei ner neuen Kernarchitektur nicht wirklich. Da will man erstmal das Teil debuggen um beim zweiten DIE dann schon ne Version 1.0b haben zu können. Aber das dauert, erstmal muss man die Fehler finden, dann beheben, dann Tapeout und dann die Produktion. Dafür brauchts inklusive Maskenschnitzen ca. 6 Monate, das Minimum im allerbesten Idealfall waren 4 Monate, wenn ich mich recht erinnere, in jedem Fall mehr als ein Quartal - allein für die Produktion, ohne Fehlersuche und -behebung.

Als AMD-Chef würd ich das Risiko nicht eingehen wollen - aber der bin ich nicht und weiss deshalb auch nicht wie prekär AMDs Lage ist. Möglich, dass sie alles auf eine Karte setzen, weil Ihnen das Wasser bis zum Halse steht.

Oder noch hinterhältiger gedacht: Man könnte die rosaroten "Alles-wird-gut-mit-Zen-und-14nm-Roadmaps" nur für die naiven Investoren angefertigt haben, um Geld reinzuholen und "zauberte" dann Anfang 2016 in Richland-Manier plötzlich doch ne 28nm-Excavator-DDR4-APU aus dem Hut, weil - leider, leider - die Zen-APU noch nicht fertig ist. Roadmaps sind ja schließlich "subject to change"...

Aber warten wir die paar Tage mal noch ab, in diesem Sinne:

Frohen 1. Mai
 
Erstens sprechen wir von ner APU, eine reine Betrachtung der CPU ist also wenig zweckmäßig, zweitens rechne ich nicht mit weniger Taktrate, die Kurve auf die Du Dich beziehst ist ohne AVFS- wie schon besagt. Die mit AVFS ist flacher, würde sie im Diagramm konstant weitergezeichnet sein, wäre man *unter* der Kaverilinie, ergo besser.
Du weisst doch aber selbst gut genug, dass in den typischen Reviews die CPU im Vordergrund steht. Dementsprechend wird auch das Fazit ausfallen. Und AVFS bringt halt nur in den unteren TDP Bereichen nochmal was. Bei 95W hilft dir das auch nicht viel.

Das ist abermals der Punkt zwischen "AMD bräuchte" und "AMD kann" ... keine Frage, AMD bräucht Zen am besten gestern, aber wenns nicht geht, gehts einfach nicht.
Und was gibt dir die Sicherheit, dass es AMD nicht kann?

Könnte AMD also wirklich Mitte 2016 eine ZEN-APU haben? Theoretisch vielleicht, aber praktisch sage ich nein, das Risiko wäre aus meiner Sicht zu groß. Wir reden über neuen Speicher, neue Plattform und über eine neue Architektur. Natürlich wäre es schön, wenn AMD in einem Rundumschlag alles erneuert.
Man wird doch nicht in einem Rundumschlag alles erneuern. Man hat ein Jahr für verschiedene Produkte Zeit. Ich würde jedenfalls damit rechnen, dass die einfacheren Designs wie die 4-Kern Zen APU zuerst gelaunched werden. Da sollte das Risiko für Probleme am geringsten sein.

Natürlich muss ne neue Plattform her, das ist doch nicht der Punkt, der Punkt ist der, dass da wieder Bugs auftreten können.
Wie gesagt, man hatte lange genug Zeit. Da kann und darf es keine Ausreden für Bugs geben. Entweder die Plattform funktioniert oder sie funktioniert nicht. Wenn sie für die Zen APU nicht funktioniert, dann wird sie auch für eine Carrizo APU nicht funktionieren.

Machbar wäre es - wenn die Zens auf den jeweils gleichen Stand wären. Will man aber v.a. bei ner neuen Kernarchitektur nicht wirklich. Da will man erstmal das Teil debuggen um beim zweiten DIE dann schon ne Version 1.0b haben zu können. Aber das dauert, erstmal muss man die Fehler finden, dann beheben, dann Tapeout und dann die Produktion. Dafür brauchts inklusive Maskenschnitzen ca. 6 Monate, das Minimum im allerbesten Idealfall waren 4 Monate, wenn ich mich recht erinnere, in jedem Fall mehr als ein Quartal - allein für die Produktion, ohne Fehlersuche und -behebung.
AMD hat in der Vergangenheit gezeigt, dass man mehrere Designs basierend auf der gleichen Architektur innerhalb von 1-2 Quartalen launchen kann. Und das wird man auch mit Zen können. Jede weitere Diskussion führt doch zu nicht. Ich habe eher das Gefühl, dass du nur nach einer Rechtfertigung für deinen Desktop Carrizo suchst. ;)
 
dass AMD bereits jetzt dicke Probleme hat

Ja, haben sie. Einen nicht mehr konkurrenzfähigen 28nm Prozess. 20nm der nichts bringt außer Kosten. Wegbrechende Einnahmen im Low End dank Intel Kontra Revenue. Keine Chance im Tablet Bereich, was auch nicht allein an den Prozessoren liegt. OEMs die, wenn überhaupt, nur Alibi Produkte bringen. Lagerbestände von Trinity, Richland und ein paar GPUs.
Da kann AMD nur noch drauf hoffen mit 14nm und neuer konkurrenzfähiger Architektur wieder ins Geschäft zu kommen.
 
Dann schauen wir doch mal, wie viel dieses Dementi wert ist.
 
das ist kein Dementi, sondern eine Fälschung wie es aussieht^^.
 
Warum sollte man paar Tage vorher sowas fälschen?
Das hätte man doch schon vor 1 Jahr machen können.
 
Zurück
Oben Unten