News Intel Xeon: Sapphire Rapids steht im Stau (Teil 2)

Piak schrieb:
Und ich dachte immer Kleben wĂ€re so einfach ...😂

Cool Master schrieb:
Was sagte Intel noch mal zu AMD die CPU ist nur geklebt? Sieht so aus als ob euer Kleber wohl nicht so gut ist.
Bestimmt irgendeinen no-Name genommen. HĂ€tten sie halt doch lieber auf Pattex setzen sollen đŸ€Ș
 
  • GefĂ€llt mir
Reaktionen: Smartbomb und Cool Master
Die Kunst des Klebens beherrscht nicht jeder Klaus!

Edit: Da Meteor Lake auch auf einem Chiplet-Design basiert, könnte es auch hier zu Verzögerungen kommen.
 
Zuletzt bearbeitet:
  • GefĂ€llt mir
Reaktionen: GT200b, DonL_ und Skorpion1976
soll Intel den Start der neuen Xeon-Generation fĂŒr Server in der Tat erst fĂŒr den Zeitraum zwischen der 6. und der 9. Kalenderwoche des kommenden Jahres planen – also zwischen dem 6. Februar und dem 3. MĂ€rz 2023."
Leute ! geht das nicht ein bischen genauer ?
 
stefan92x schrieb:
Ich frage mich bei diesem Thema gerade, wie eigentlich z.B. die Struktur vom Ampere Altra ist? Da wÀre ein Quervergleich der Designs, die Dutzende Kerne haben wirklich mal spannend.
Das, was ich als letztes gesehen habe, geht Ampere Àhnlich wie AMD vor, sie fassen Kerne zu Kerngruppen und diese Kerngruppen gehen dann an das Interconnect:
ampere-emag-procesor-servethehome-04.jpg


Das sieht dem, was AMD macht nicht unÀhnlich, auch wenn es etwas anders organisiert ist.
stefan92x schrieb:
Mesh kam ja mal anstelle des Rings, um mehr Kerne schneller zu verbinden, aber mittlerweile scheint AMDs "Ring of rings" (im IO-Die und dann in jedem CCD) tatsĂ€chlich die kĂŒrzeren Wege zu bieten.
Stimmt nicht ganz, weil die Kerne in einem CCX eigentlich ĂŒber den L3-Cache verbunden werden und dort jeder CPU-Kern entsprechend an 2/3 L3-Slices angebunden ist und die L3-Slices auch noch mal verbunden sind, was auf Reddit in einer Grafik fĂŒr Zen 1 gut verdeutlicht wird.

Und beim IOD ist es auch schwer, man kann es als "Ring" interepretieren, was man zu sehen bekommt, wird dem aber auch nicht so ganz gerecht. AMD stellt heute den InfinityFabric eher als ein großen gewaltigen Hub da, der ĂŒber eine gewisse Menge an Ports verfĂŒgt, an die man entweder weitere Hub anschließen kann oder eben andere Komponenten.

Der Hub ist die zentrale Stelle und vereinfacht die Verwaltung enorm und hilft auch entsprechend die Zeit konstant zu halten. Wenn ein Kern auf den Memory-Controller zu greifen muss, dann gibt der Kern die Anweisung an den IF-Link im CCX, die Anweisung springt dann in den IF-Hub (IOD) und wird dort an den IF-Link des Memory-Controllers weiter geleitet, der die Anweisung dem Memorycontroller gibt. Man hat in dem Fall halt 2 SprĂŒnge im Infinity Fabric.

Auch wenn ein Kern auf einen anderen Kern außerhalb des eigenen CCX zugreifen will, es sind immer 2 SprĂŒnge: IF-Link zum Hub zum IF-Link.

Ich stell mir AMDs-Lösung nicht wie ein Ring der Ringe vor, sondern eher als Stern, an dem man weitere Sterne anschließt, was dann ja auch in einem Mesh endet.
 
  • GefĂ€llt mir
Reaktionen: Anakin Solo, pipin, Cr4y und eine weitere Person
DevPandi schrieb:
Stimmt nicht ganz, weil die Kerne in einem CCX eigentlich ĂŒber den L3-Cache verbunden werden und dort jeder CPU-Kern entsprechend an 2/3 L3-Slices angebunden ist und die L3-Slices auch noch mal verbunden sind,
Es ist mittlerweile bekannt, dass ein CCX seit Zen 3 ĂŒber einen doppelten Ringbus verfĂŒgt.
1659357462266.png


Quelle
 
  • GefĂ€llt mir
Reaktionen: or2k, Skysnake, janer77 und 4 andere
Colindo schrieb:
Es ist mittlerweile bekannt, dass ein CCX seit Zen 3 ĂŒber einen doppelten Ringbus verfĂŒgt.
Danke, wieder etwas gelernt.

Ist an der Stelle aber glaub ich nicht ganz so wichtig, da dieser Ring ja nicht InfinityFabric ist, sondern ein spezieller interner fĂŒr das CCX. Unten ist ja der IF-Link in der Grafik zu sehen.
 
  • GefĂ€llt mir
Reaktionen: janer77 und Colindo
die L3 der CCXe sind auch nicht untereinander verbunden, max. 256MB Cache ist daher etwas falsch.
Was mich interessieren wĂŒrde was passiert wenn selbstmodifizierender Code in mehreren L3 gespeichert ist, Cache flush etc bestimmt tricky :cool_alt:
 
DevPandi schrieb:
Das, was ich als letztes gesehen habe, geht Ampere Àhnlich wie AMD vor, sie fassen Kerne zu Kerngruppen und diese Kerngruppen gehen dann an das Interconnect
Untermauert den Verdacht, dass ein Mesh, in dem alle Kerne auf gleicher Ebene verbunden werden, irgendwann einfach ineffektiv wird und der hierarchisch strukturierte Ansatz von AMD, Ampere und vermutlich auch anderen besser geeignet ist.
 
  • GefĂ€llt mir
Reaktionen: DonL_ und Colindo
Rollo3647 schrieb:
dieser "Balken" verbraucht aber viel mehr Strom.
Das ist zwar richtig, aber ist wohl weniger eine Frage des Konzepts, sondern des Packagings, da bei AMD die IF-Links durch das Substrat gehen und fĂŒr die Distanz relativ viel Energie pro Bit brauchen. Wenn IO-Die und CCD per EMIB oder vergleichbarer Technik verbunden wĂ€ren, wĂ€re das wohl auch signifikant sparsamer.
 
Rollo3647 schrieb:
dieser "Balken" verbraucht aber viel mehr Strom.
Tja, etwas mehr Stromverbrauch, oder ein nicht zu bÀndigendes Monster?
Systeme mĂŒssen runtergebrochen leicht fĂŒr ein Menschen verstĂ€ndlich sein, sonst passieren nur Fehler und es funktioniert nicht oder sehr schlecht - so meine Erfahrung.
 
Rollo3647 schrieb:
dieser "Balken" verbraucht aber viel mehr Strom.
Ja und Nein. Der Balken benötigt nicht pauschal mehr Enrgie, sondern es kommt darauf an, was man am Ende erreichen will und wie viel Energie dafĂŒr benötigt wurde.

Ja, der IOD benötigt Energie, das benötigen die IO-Tiles/Blöcke aber in den Tiles auch, hier wird das Budget einfach nur zu Teilen verlagert.

Und natĂŒrlich sind es auch die "GoldfĂ€den" aktuell innerhalb der CPU als Verbinder, die etwas mehr energie benötigen, weil die Wege "lĂ€nger" sind.

Am Ende ist es aber nicht relevant ob das ĂŒbertragene Bit beim Aufbau von AMD zur Übertragung etwas mehr Energie benötigt oder weniger, sondern wie viel Energie fĂŒr das Bit vom Anfang bis zum Ziel benötigt wurde und auch wie viel Zeit verstrichen ist.

Jetzt mit fiktiven Zahlen, wir haben ja keine genauen, aber um dir das zu verdeutlichen: Wenn Intel pro Bit pro Sprung in ihrem Mesh 5 Joule braucht und AMD pro Sprung in ihrem Mesh 15 Joule.

AMD benötigt in ihrem Infinity-Fabric 2 SprĂŒnge vom Core zum Memory-Controller und damit 30 Joule und zwar IMMER. Intel benötigt mindestens 1 Sprung (also 5 Joule) und maximal 5 SprĂŒnge innerhalb des Tiles, also 25 Joule. Geht es ĂŒber die Tiles hinweg können auch 6 und sogar 9 SprĂŒnge notwendig sein im Mesh, damit kommen wir dann auf 30 - 45 Joule, die man fĂŒr das Bit benötigt.

Man ist dann zwar pro Bit und Sprung im Mesh gĂŒnstiger, am Ende braucht man aber mehr, weil mehr SprĂŒnge notwendig sind.

stefan92x schrieb:
Das ist zwar richtig, aber ist wohl weniger eine Frage des Konzepts, sondern des Packagings, da bei AMD die IF-Links durch das Substrat gehen und fĂŒr die Distanz relativ viel Energie pro Bit brauchen.
Ja und Nein, es ist durchaus auch eine Frage des Konzeptes, ich denke der IF wird immer etwas mehr Energie benötigen pro Bit als das Mesh bei Intel, am Ende ist aber halt die Frage, was jeder Sprung an Energie benötigt und da kann sich das ganze auch drehen, siehe Rechnung oben.
stefan92x schrieb:
Wenn IO-Die und CCD per EMIB oder vergleichbarer Technik verbunden wÀren, wÀre das wohl auch signifikant sparsamer.
EMIB wird auf jeden Fall die Kosten pro Bit und Sprung drĂŒcken, aber am Ende dennoch etwas mehr benötigen, da Infinty Fabric etwas anders aufgebaut ist und etwas mehr "Kontrolle" hat.
Colindo schrieb:
Erwartet man ja deswegen auch bei Zen 4 und RDNA 3.
Ach, es wird spannend, was da in den nÀchsten Jahren kommt!
 
  • GefĂ€llt mir
Reaktionen: Smartbomb, Cyberwiesel, GT200b und 2 andere
Hat einer ne idee was da bei Intel mit der Validierung schief geht?

Von schweren Validierungsproblemen hab ich noch nie was gehört
 
  • GefĂ€llt mir
Reaktionen: Salutos
Ned Flanders schrieb:
Von schweren Validierungsproblemen hab ich noch nie was gehört
Das ist doch völlig egal, Intel hat wieder eine nichts sagende Aussage getroffen damit die Welt darĂŒber spekulieren kann.
TĂ€uschen und blenden, wie jetzt schon ĂŒber Jahre.

Rein fiktiv.
Ein Validierungsfehler kann auch schon beim Design passieren, wenn man das Teil dann "baut" stellt man fest, es funktioniert nicht wie erwartet.
Einordnung des Problems -> schwererwiegend
So kann es sein, muss es aber nicht.

Dass es sich um ein Hardwareproblem handelt bestÀtigt ein weiteres Stepping.
Dass es "nicht alle Kunden" sprich Modelle betrifft könnte man so einordnen, dass das Problem in einem grĂ¶ĂŸeren Ausbau, ab einer gewissen Anzahl Kerne, auftritt.
 
  • GefĂ€llt mir
Reaktionen: Ned Flanders
Salutos schrieb:
Dass es "nicht alle Kunden" sprich Modelle betrifft könnte man so einordnen, dass das Problem in einem grĂ¶ĂŸeren Ausbau, ab einer gewissen Anzahl Kerne, auftritt.
Das wÀre eine Möglichkeit, es könnte aber auch ein Problem mit bestimmten Features sein, die manche Kunden einfach nicht brauchen und die dann keinen Schmerz haben, wenn dieses bei ihnen in der CPU deaktiviert wird.
 
stefan92x schrieb:
Das wÀre eine Möglichkeit, es könnte aber auch ein Problem mit bestimmten Features sein, die manche Kunden einfach nicht brauchen und die dann keinen Schmerz haben, wenn dieses bei ihnen in der CPU deaktiviert wird.
Schwierig dann mĂŒsste CPU sowas wie P- und E-Tiles haben.
 
Salutos schrieb:
Schwierig dann mĂŒsste CPU sowas wie P- und E-Tiles haben.
Nein, ich spreche wirklich von Features. Es war ja die Rede von einem Security-Problem, also könnte es z.B. ein Fehler im SSL-Accelerator rein. Wer jetzt sagt, er braucht keine Crypto-Funktionen, kann die CPU einfach guten Gewissens trotzdem mit (z.B. per Microcode) deaktiviertem SSL-Accelerator einsetzen, z.B. fĂŒr HPC-Anwendungen.

Auf dieser Funktionsebene kann sich das durchaus bewegen, muss nicht genau dieses Beispiel sein, aber soll das Prinzip zeigen.
 
  • GefĂ€llt mir
Reaktionen: Skysnake und Ned Flanders
DevPandi schrieb:
Ich stell mir AMDs-Lösung nicht wie ein Ring der Ringe vor, sondern eher als Stern, an dem man weitere Sterne anschließt, was dann ja auch in einem Mesh endet.
Nein das ist kein Mesh was du beschreibst. Ein Mesh ist ein Mesh und ein Ring ein Ring. Man spricht hier von Netzwerktopologien und die sind verdammt gut analysiert. Also sowohl mathematisch als auch technischer Natur.

Colindo schrieb:
Es ist mittlerweile bekannt, dass ein CCX seit Zen 3 ĂŒber einen doppelten Ringbus verfĂŒgt.
Anhang anzeigen 1245598

Quelle
Danke fĂŒr die solide. War an mir bisher vorbei gegangen.
Ned Flanders schrieb:
Hat einer ne idee was da bei Intel mit der Validierung schief geht?

Von schweren Validierungsproblemen hab ich noch nie was gehört
Das kann alles oder nichts sein. Intels Sata Gate Bug war einer. AMDs TLB Bug war einer Intels fdiv Bug war einer und so geht es gerade weiter.

Es können also sowohl logische Fehler im Design sein, also auch Fehler die dazu fĂŒhren das hin und wieder etwas falsches raus kommt, oder man schafft die anvisierte Taktrate nicht. Dann muss man das Feature meist ganz abschalten. Oder etwas braucht zu viel Energie, sprich schafft den Takt bei gegebener Energie nicht.

Wie gesagt, das ist an sich ziemlich nichtssagend und kann alles oder nichts bedeuten.
 
Eine Anmerkung zum Ringbus:
Generell gilt, AMD ist ziemlich verschwiegen was die Details angeht.
Bei Zen 2 waren im CCX 3 Verbindungen je Kern möglich. Ein Ringbus benötigt nur 2 Verbindungen je Kern. Damit stellt sich die Frage: Hat AMD mit Zen 3 nun eine Verbindung eingespart oder ist ein es "Ringbus mit Querverbindungen"?. Die Messungen von anandtech bescheinigen, dass die timings besser sind, als es bei einem Ringbus zu erwarten wÀre.

stefan92x schrieb:
Wenn IO-Die und CCD per EMIB oder vergleichbarer Technik verbunden wÀren, wÀre das wohl auch signifikant sparsamer.
Definitiv.

Da gibt es eine breite Auswahl an Techniken, die besser sind, als das was AMD aktuell einsetzt. Denn das ist schlicht und einfach die Dies per FlipChip auf ein Substrat zu klatschen. Und das Substrat ist Leiterplattentechnik, die nur relativ grobe Strukturen ermöglicht.

Intel nennt seine Technik mit SiliziumbrĂŒcke EMIB. SiliziumbrĂŒcken ermöglichen eine die effiziente Verbindung zwischen zwei Dies. EMIB hat sie ein paar Eigenarten, die mir nicht gefallen. Die Entsprechung bei AMD wĂ€re EFB, die bei den MI200 eingesetzt wird. Hier werden FanOut (mit Leiterbahmen in DĂŒnnschichttechnik) und eine SiliziumbrĂŒcke kombiniert.

Bei der aktuellen Die-Anordnung von EPYC kann ich mir keine Umsetzung mit SiliziumbrĂŒcken vorstellen. Denn die SiliziumbrĂŒcken sind eine 1:1 Verbindung zwischen 2 Chips. Interposer dĂŒrften inzwischen in der erforderlichen GrĂ¶ĂŸe machbar sein, ich halte sie aber fĂŒr zu teuer.

Ich habe gehört, dass Zen 4 anders aufgebaut sein soll. Hier haben einige ein FanOut ins Spiel gebracht, Aber alles was ich an Bildern (AbstÀnde zwischen den Dies) gesehen habe, suggeriert, dass es AMD bei Zen 4 nochmal mit dieser alten Technik aus Zen2/3 wagt.
 
ZurĂŒck
Oben