News AMD Epyc: Naples ohne Heatspreader zeigt 4-Die-Multi-Chip-Design

autoshot schrieb:
Wie schnell ist im Vergleich die Anbindung von L2/L3-Cache?

Kann ich nach der Arbeit mal messen. Aber Bandbreite allein ist ja nicht alles... da kommt noch Latenz oben drauf.... Caches werden ja nicht unbedingt wegen dem max. Durchsatz verbaut sondern weil die Latenzen im Vergleich zu RAM sehr gering sind.
 
Zuletzt bearbeitet:
ich denke die Multi Chip Strategie hat rein wirtschaftlichen Hintergrund und ich begrüße AMDs Entscheidung. Mit GPU kann man das aber 0 vergleichen.

Bei CPU und dem erwarteten Einsatzfeld, zb Virtualisierung, wird das Multi Chip Design kaum Nachteile haben. Selbst wenn die Chip zu Chip Kommunikation weit langsamer ist als L2 /L3.

Je granularer die Arbeit, umso besser skaliert man. CCX hat zb einen kleinen Nachteil wenn Thread A und B miteinander reden müssen aber nicht im gleichen Cluster sitzen. Bei AMDs Multi CHip wird das noch viel gravierender sein aber für so etwas gibt es NUMA. Das sagt dem Sheduler auf welcher Die was genau zusammengehört. Wenn die wenigsten Threads miteinander kommunizieren müssen, zb bei Virtualisierung, dann ist das kaum von Nachteil und in jedem Fall noch deutlich schneller als zb über 2 Sockel hinweg.

Edit:
cachemem_R7-1800X_1-pcgh.png

420 GB/s klingen realistisch und wären gut fix. Auf einem Package sollte das auch kein Problem sein. Sockel zu Sockel wäre das unmöglich.
 
Zuletzt bearbeitet:
Ned Flanders schrieb:
According to AMD, it is a 256-bit wide bi-directional crossbar

Infinity Fabric ist ein Hypertransport abgeleiteter Bus.

Das würde bedeuten das bei 3200MHz takt uni direktional 420gb/s durchgehen....

dächte, die Fabric taktet nur mit dem halben DDR - also quasi normal SD-RAM Takt; bei 3200 MHz komme ich auf ca. 1600e6*256/8/1024^3 ~ 47,7 GB/s. Aber wie du in #22 sagst, spielen die Wartezeiten wahrscheinlich die größere Rolle, als die reine Bandbreite.
 
dass schrieb:
In der Praxis ist maximal 22GB/s zwischen CCX (Angaben AMD)

Quelle?
Ergänzung ()

Krautmaster schrieb:

HT Überträgt aber auch im DDR verfahren... Die frage ist halt ob die Leistungsdaten real oder effektiv bezogen sind. Ich gehe aber davon aus das AMD den HT 3.1 6400MHz genannt hätten wenn sie es hätten können.

EDIT:

Laut der englischen Hypertransport Wikipedia:

Infinity Fabric is a superset of HyperTransport announced by AMD in 2016 as an on-chip interconnect for its GPUs and CPUs.[6] The company said the Infinity Fabric would scale from 30GBytes/s to 512GBytes/s, and be used in the Zen-based CPUs and Vega GPUs which to be released in 2017.

Ich glaube schon das Meine Rechnung grob richtig liegt....

EDIT2:

im Orginal:

The company declined to give data rates or latency figures for Infinity, which comes only in a coherent version. However, it said that it is modular and will scale from 30- to 50-GBytes/second versions for notebooks to 512 Gbytes/s and beyond for Vega.
 
Zuletzt bearbeitet:
Ist es nicht abhängig vom Speicherinterface ?

Das Octa Channel bietet alleine schon 170,7 GB/s mit Vollbestückung, entspricht dann nicht die Bandbreite der Fabric Bidirektional in jede Richtung genau die Hälfte der maximal Bandbreite, also jeweils 85,35 GB/s in jede Richtung ?

@NedFlanders , hast du mit 3200 oder 1600 MHz gerechnet ?
 
Zuletzt bearbeitet:
aivazi schrieb:
@NedFlanders , hast du mit 3200 oder 1600 MHz gerechnet ?

Bei 3200MHz effektiv Takt (1600MHz real) sollte ein Hypertransport Link mit 256bit Breite (Infinity Fabric) 420gb/s durchlassen können. AMD sagt "bis zu 512gb/s" ohne den Takt näher zu erläutern.

Das sind aber natürlich idealwerte und ich glaube auch nicht das der IF Takt bei RAM vollbestückung auf ner Server Plattform 3200MHz real beträgt.

Bei 2400MHz effektiv währen es aber immer noch >300gb/s

Mal dies hier lesen, das ist sehr aufschlussreich und die Quelle sehr glaubwürdig.

EETimes
 
Zuletzt bearbeitet:
Ned Flanders schrieb:
AMD hat es während der Vorstellung von Ryzen gesagt.


(Sorry auf französisch)
Si AMD n'a pas pu nous donner une idée de la latence d'un accès sur le second CCX, il nous a fourni une autre donnée largement plus importante : la bande passante entre ces deux CCX : ils l'auraient mesuré en pratique à seulement 22 Go/s !

AMD wollte ihnen keine Angaben über die Latenz des Bus zwischen 2 CCX geben, die sagten aber Sie haben den Bus mit maximal 22GB/s messen können.
http://www.hardware.fr/articles/956-23/retour-sous-systeme-memoire.html

d.h Sie haben die kleinste (mit den wenigsten Links) Variante vom HT 3.0 ausgewählt.
30GB/s max theoretisch, 22GB/s in der Praxis scheint ok zu sein.
 
Zuletzt bearbeitet:
dass schrieb:
d.h Sie haben die kleinste (mit den wenigsten Links) Variante vom HT 3.0 ausgewählt. 30GB/s max theoretisch, 22GB/s in der Praxis scheint ok zu sein.

Merci!

Hilft offensichtlich wieder nur selber messen...

22gb/s erscheint aber unrealistisch langsam für eine 256bit breite HT implementierung.

Das hat HT 3.0 mit 32bit bereits im Jahr 2006 gebracht (bei 2600MHz).
 
Zuletzt bearbeitet:
Na ja, jetzt wird sich es zeigen ob die großen OEM`s wirklich Konkurrenz wollen. Denn das alles hilft nichts wenn, HP, Lenovo und Co. die Teile nicht verbauen. Dann schaut AMD wieder in die Röhre.
 
Hm für die angegebenen 512 GByte/s müsste ein Bus single data rate mit
512 [GByte/s] *1024^3 [Byte/GByte] * 8 [Bit/Byte] / 256 [Bit/clock]=17 GHz
takten, oder? DDR dann halt "nur" die Hälfte. Kann mir lediglich vorstellen, dass sich diese Angabe auf mehrere parallel arbeitende Busse bezieht. Bei der sinnbildlichen Grafik aus der Präsentation waren die Fabric Symbole zwischen den benachbarten Dice eingezeichnet - könnte ja sein, dass es so (marketingwirksam) addiert wird.
Was mich ein wenig wundert sind die 140 ns inter CCX-Latenz über die nach dem Ryzen release berichtet wurde, wenn ich mir zum Vergleich den Shot von AIDA64 in #27 anschaue. Die 140 ns wären nur geringfügig schneller als die doppelte RAM-Latenz. - Ich würde gern mehr Details über die Fabric erfahren.
 
Zuletzt bearbeitet:
Wenn Naples für 32 Kerne 4 Dies nutzt, dann könnte man ja für "Threadripper" (:freak:) 2 Dies annehmen...
Da bin ich mal gespannt, wie sie die NUMA-Geschichten auswirken, wenn man nicht mehr nur zwischen CCX sondern auch zwischen Dies kommunizieren muss.
 
user2357 schrieb:
Hm für die angegebenen 512 GByte/s müsste ein Bus single data rate mit
512 [GByte/s] *1024^3 [Byte/GByte] * 8 [Bit/Byte] / 256 [Bit/clock]=17 GHz

Das klingt plausibel. Warum wird dann HT3.1 bei 32bit breite und 3200MHz Takt mit 25.6Gb/s angegeben? Das ist ja definitiv nur eine Punkt zu Punkt Verbindung....

https://de.wikipedia.org/wiki/HyperTransport#Leistungsdaten

Irgendwas vergessen wir hier...

Ich nehme an, dass dies daran liegt das Hypertransport kein bitsream bus ist, sondern ein Packet basierter Bus ist.

HyperTransport is packet-based, where each packet consists of a set of 32-bit words, regardless of the physical width of the link. The first word in a packet always contains a command field. Many packets contain a 40-bit address. An additional 32-bit control packet is prepended when 64-bit addressing is required. The data payload is sent after the control packet. Transfers are always padded to a multiple of 32 bits, regardless of their actual length.

Das könnte auch die höhere Latenz als bei einem konventionellen Bus erklären.

Hier endet allerdings meine Expertise....

EDIT:

With the advent of version 3.1, using full 32-bit links and utilizing the full HyperTransport 3.1 specification's operating frequency, the theoretical transfer rate is 25.6 GB/s (3.2 GHz × 2 transfers per clock cycle × 32 bits per link) per direction, or 51.2 GB/s aggregated throughput, making it faster than most existing bus standard for PC workstations and servers as well as making it faster than most bus standards for high-performance computing and networking.

Sprich:

Hypertransport 3.1: 3,2*10^9* 2 (DDR) * 32 (breite) /8 (bits/bytes) = 25.6gb/s

Infinityfabric: 3,2*10^9 * 2 (DDR) * 256 (breite) /8 (bits/bytes) = 204 gb/s

das wirds dann wohl sein....
 
Zuletzt bearbeitet:
Hatte den Wiki-Artikel auch grad auf. Da wird mit der angegebenen Taktfrequenz als DDR gerechnet - sprich zwei mal die 32 Bit / clock. Anders kommen die Werte nicht zustande. Außerdem wird nicht mit 1024er Potenz auf die GByte/s umgerechnet. Damit wäre der Wert bei dem 3.1er in etwa 23,8GByte/s.

@Ned

Hattest du die 512 GByte/s - Werte in Bezug auf den Prozessor aus dem Artikel irgendwo aufgeschnappt?
 
Zuletzt bearbeitet:
user2357 schrieb:
@Ned

Hattest du die 512 GByte/s - Werte in Bezug auf den Prozessor aus dem Artikel irgendwo aufgeschnappt?

Nein, das stammt aus dem verlinkten Artikel auf EETimes. Offizielle Werte für die Epyc Plattform gibt es meines Wissens nicht.

Die Hypertransport Leistungsangaben sind aber auch außerhalb der Wiki Welt konsistent (e.g. auf Heise welche ja sicher rechnen können)
 
Ned Flanders schrieb:
Infinityfabric: 3,2*10^9 * 2 (DDR) * 256 (breite) /8 (bits/bytes) = 204 gb/s
an der Stelle greift aber wieder die single data rate Thematik, auf die Krautmaster vorhin gezeigt hatte (Techpowerup)
481927462be9.jpg
sodass es nicht *2 (DDR) ist, sondern /2 da single data rate

zu dem Vega-Bezug aus dem EETimes-Artikel: dort könnten mehrere "Fabric-Module" baukastenartig zusammen gefasst sein, um mit 8 Modulen pro HBM-Stack das 2048 Bit breite Speicherinterface zu basteln. Vielleicht ist es einfach ein genauso skalierbares Architektur-Element, wie der Zeppelin Die.
 
Zuletzt bearbeitet:
user2357 schrieb:
sodass es nicht *2 (DDR) ist, sondern /2 da single data rate

Warum /2. Die Breite reduziert sich durch SDR ja nicht, sie verdoppelt sich nur nicht.
 
Ned Flanders schrieb:
Warum /2. Die Breite reduziert sich durch SDR ja nicht, sie verdoppelt sich nur nicht.

von Krautmeisters Link: "i.e. when using 2133 MHz memory, the memory controller clock speed of 1066 MHz is the clock speed of the fabric."

Die heute gängigen Angaben zu RAM-Takten beziehen sich immer auf den DDR-Takt, real liegt doch nur die halbe Frequenz an.
 
Zurück
Oben