News AMD-Epyc-Prozessoren: Alle Wege führen nach Rome

Ned Flanders schrieb:
Gefühlt ist gut.... Das gabs AFAIK noch nie...
Gab es nicht irgendwann einen - zugegebenermaßen - sehr kurzen Zeitraum, wo AMD auch die bessere Fertigung hatte?

Zumindest beim AMD Thunderbird stand es fertigungstechnisch gleichstand bin ich der Meinung.
 
@Taxxor Nimm für den Vergleich einen Non-X und Non-k Da wird es noch deutlicher im n-Core Cinebench
 
Volle Fahrt voraus!. Ich hab zwar selber zwei Intels zu Hause und auch auf der Arbeit, zu diesem Zeitpunkt gab es leider keine ordentliche Alternative.
Ich freu mich sehr für die und die nächste CPU wird sicher ein Ryzen
 
Volkimann schrieb:
Zumindest beim AMD Thunderbird stand es fertigungstechnisch gleichstand bin ich der Meinung.

Musste ich jetzt selbst nachschauen, aber der Thunderbird kam Juni 2000 auf den Markt und war das erste 180nm Produkt. Der erste Intel mit 180nm kam ein dreiviertel Jahr vorher (Pentium III Coppermine).

Gefühlt wars eher so, dass wenn immer AMD drann oder drüber war, Intel sich in den nächsten Fertigungsnode "geflüchtet" hat ;-).
 
conf_t schrieb:
@Taxxor Nimm für den Vergleich einen Non-X und Non-k Da wird es noch deutlicher im n-Core Cinebench
Nicht wirklich

2700: 1526/125W = 12,2
8700: 1389/104W = 13,3
Vorsprung Intel: 9%
 
Simon schrieb:
- Non-NUMA-Aware Software oder Software die keine großen Latenzunterschiede zwischen Kernen und Remote-Cache verkraften sind unter EPYC auch kein Traum
- Unterbestückung der RAM-Kanäle ist ein massives Problem, da dann manche Kerne ohne lokal angeschlossenen Speicher immer über die IF gehen müssen. Nicht jeder braucht immer 256/512GB/1+TB RAM.

-Naja ich kann diverse Software relativ leicht auf einen CCX festnageln bzw auf demselben DIE
das ist nun kein Hexenwerk
-Dann kauf ich einfach mehr kleinere Module und das Problem ist auch keines mehr.
Ergänzung ()

Excel schrieb:
Ist das so? Der Test von Tomshardware zeigt für den 8700K einen klar höheren Verbrauch. keinen Nachteil für den Ryzen.

Davon ab, bei den üblichen Taktfrequenzen eines Server Prozessors also 3.2-3.8 Ghz läuft
Ryzen im Sweet Spot. Da ist der Verbrauch aufgrund der Fertigung deutlich niedriger als bei Intel
und das mit mehr Kernen.
Die Leistung pro Watt pro Kern wird ähnlich sein, aber die wird am Server hoffentlich keiner betrachten.
 
Zuletzt bearbeitet:
"....hat AMD nach bisherigem Stand fast alles richtig gemacht."

So eine Meldung nächstes Jahr im Grafikkartensektor, und alles wird gut :)
 
schmalband schrieb:
Ich ich würde sogar noch weniger Kerne kaufen und noch weiter mit der Frequenz hochgehen wenn möglich. Auch auf HT würde ich verzichten und lieber einen weiteren Sockel in Betracht ziehen wenn nötig.
Naja, kommt halt immer so auf den Workload an. Bei ~4 GHz ist momentan sowieso Schluss.

Der Gold 6144 macht All-Core-Turbo auf acht Kernen 4,1 GHz und der Gold 6146 afaik immerhin noch durchgehend 3,7 GHz auf allen zwölf. Das ist m.E. momentan so das schnellste, was geht. Der 4-Kern Platinum 8156 macht auch nur 3,7.

HT kostet keine Lizenz, aber ja - es gibt natürlich Anwendungen die ohne noch etwas besser laufen. Aber ohne Not auf mehr als zwei Sockel gehen, ich weiß nicht - da fällt mir kein besonderer Grund für ein, außer mehr RAM und mehr PCIe. Hat aber auch Nachteile.

Ansonsten unterschreibe ich aber auch Dell + Intel. ;) (wobei die PER 7415 als VSAN-Node oder mit 24 x NVMe Drives für MS S2D auch schon sehr nice sind ^^).
 
Volkimann schrieb:
Ich finde seine Argumentation bzgl Stabilität usw recht witzig. Ryzen und Epyc sind diesselbe Soße, aber bei den Desktops kann ruhig Ryzen rein?

Ich erzähle es dir aus Sicht eines Entscheiders. Wenn ein paar Desktops nicht so richtig funktionieren oder nicht gut mit einer Applikation arbeiten, ist es ärgerlich.

Wenn ein Server am Ende nicht die Leistung erbringt die er sollte oder Probleme macht, können unter Umständen auch mal 100 oder mehr Leute nicht vernünftig arbeiten. Das ist dann nicht ärgerlich, das kostet dann den Kopf.

Ryzen und Epyc sind zudem nicht die gleiche Soße. Ryzen ist eine CPU für sich, Epyc sind 4 Zen auf einem Sockel. Es gibt diverse Einschränkungen für dieses Design, die man berücksichtigen und vorher testen sollte. Ein EPYC ist keine CPU die man gleichermaßen für Windows wie auch für Linux, für Datenbanken oder Terminal Server einsetzen kann.

Wenn du so einen Server einem Kunden anbietest hast du noch ein zusätzliches Problem. Lass mal irgendeine der dir vermutlich nicht bekannten Kundenapplikationen nicht richtig funktionieren. Dann fängt ein Ping Pong zwischen dem Hersteller der Software und dir als derjenige, der nicht einen Standardserver angeboten hat. Am Ende bis DU der Schuldige solange du keine Unschuld beweisen kannst. Und Wofür das ganze? Für 1000€?
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: (-_-)
Simon schrieb:
Und wer mir mit Linux um die Ecke kommt: RHEL + z.B. nen JBOSS/Wildfly Application Stack gibt es auch nicht unbedingt für lau hinterher geworfen. Ne Knoppix-Live-CD sieht man im Enterprise-Umfeld eher selten.
Dein Hauptproblem hast du ja selbst erkannt: Windows :D
Dein anderes Problem heißt wohl: Java EE. Das ist zwar nach wie vor der einzige "offizielle" Standard im Java Server Umfeld, aber seit Jahren rücken immer mehr und mehr Firmen davon ab. Die Entwicklung geht zu langsam voran (das ändert sich jetzt hoffentlich mit Jakarta EE), Enterprise Betrieb ist zu teuer, alles zu umständlich, etc.. Viele Java Software Häuser bieten nun auch großflächig Produkte auf Spring Basis an - seit ein paar Jahren sprießen im Java Umfeld aber immer mehr solche Frameworks aus dem Boden, die sich auf 1-2 Bereiche spezialisieren und dadurch dann eben extrem einfach zu handhaben und sehr performant sind. Oder man baut kunterbunte Microservices mit Node, Ruby, Python (und Java).

Ich kenne reichlich Systeme, die auf Kubernetes, OpenShift, Spring, etc. aufsetzen.
Und natürlich gibt's von diesen Softwares auch jeweils eine Enterprise Edition und/oder anderweitigen kostenpflichtigen Enterprise Support. Lizenzen wo man pro Kern bezahlt wären mir dort jetzt auf Anhieb nicht bekannt. Vielleicht gibt's was wo man "pro Installation" bezahlt, aber das ist dann ja auch eher ein Argument für mehr Kerne oder mehr-Sockel Systeme.

Unter Linux hat man halt eher die Wahl: Hole ich mir die System-, Netzwerk-, etc.-Admins ins Haus und arbeite mit kostenlosen Produkten. Oder miete ich SaaS- oder sonstige Cloud-Produkte, wo die Administration ein externer Dienstleister übernimmt.

Im Endeffekt ist es natürlich immer eine Geldfrage. Mit genug Geld kriegt man auch das passende Personal und/oder kann sich direkt bei Amazon AWS im großen Stil einmieten und kriegt alles erdenkliche fertig eingerichtet frei Haus.
 
@xexex

Tja, da du aber ständig Propaganda gegen AMD machst, solltest du mal belegen das die Epyc Plattform Probleme macht. Ich habe weder davon etwas gelesen, noch ist es mir in meinem Umfeld von den Leuten die mit Epyc Servern arbeiten zu Ohren gekommen.
Auch deine ständige Behauptung Epyc würde nicht zu Windows Server passen, ist schlicht deine subjektive Behauptung und nur davon abgeleitet, das Epyc Server unter Linux schneller sind, das trifft übrigens auch auf Intel zu.
Dein ständiges Bashing ist durch absolut null Fakten unterlegt, ansonsten bringe mal Belege für deine anti Epyc Propaganda!
 
xexex schrieb:
Wenn ein Server am Ende nicht die Leistung erbringt die er sollte oder Probleme macht, können unter Umständen auch mal 100 oder mehr Leute nicht vernünftig arbeiten. Das ist dann nicht ärgerlich, das kostet dann den Kopf.
So ist es. Stichwort Opportunitätskosten.
 
"Dabei ging es nicht nur um die aktuellen Gegebenheiten der Server-Prozessorserie, sondern auch den kleinen Ausblick auf das, was Mitte 2019 kommt."
Warum Mitte 2019? Ist das eine Info von AMD?
Nochmal eine weitere Runde beim neuen 7nm Prozess nach aktuellem Sampling, was mit weiteren ca. 6 Monaten genau passen würde?
Oder versucht man das Inventory (derzeitige Chips) zu reduzieren und hat daher verschoben?
Nach derzeitiger Lage, wird wohl beides zutreffen.
Damit würde das Zeitfenster, um den Vorteil zu nutzen, noch etwas kleiner werden.
 
DonL_ schrieb:
Tja, da du aber ständig Propaganda gegen AMD machst, solltest du mal belegen das die Epyc Plattform Probleme macht.

Habe ich behauptet sie macht Probleme? Sie kann Probleme machen.

Das ist der Speicherdurchsatz einer EPYC CPU im Vergleich zu einem Xeon.
1537461439990.png

https://www.anandtech.com/show/11544/intel-skylake-ep-vs-amd-epyc-7000-cpu-battle-of-the-decade/12

Wie gewährleistest du, dass eine Applikation, die womöglich in einer VM läuft mit solchen "seltsamen" Aufbau konstante Ergebnisse bringt? Her damit!

Nimm einen SQL Server installiere ihn auf rohen Blech und gib ihm 64 Kerne, da wird der EPYC abgehen. Installiere ein paar VMs mit Terminalserver, SQL Server, Exchange, SAP und du wirst je nach VM Konfiguration und Vorlieben deines VM Hosts unterschiedliche Ergebnisse bekommen.

Beide Virtualisierer die ich gut kenne und für die ich zertifiziert bin (ESX und Hyper-V), werden eine VM zunächst immer auf einem NUMA Node halten, damit erreicht eine EPYC CPU aber nur einen Bruchteil vom möglichen Speicherdurchsatz. Was du also brauchst ist eine Applikation die NUMA Aware ist und Fummelei in deinem Virtualisierungshost, damit er die vCPUs auf verschiedene Kerne aufteilt. Dann kannst du aber nur hoffen, dass die Applikationsthreads unabhängig voneinander arbeiten wie bei einem SQL Server. Hast du stattdessen einen Terminal Server unter Windows, willst du ja nicht, dass die Threads von Kern zu Kern geschaltet werden.

Am Ende brauchst du für solche gemischten Workloads Optimierung und Tests, die kosten Zeit und Zeit ist bekanntlich Geld.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: lalelu
Mensch ich will auch endlich mal nen Epyc verbauen. Nicht unbedingt nutzen, das geht weit über meine Bedürfnisse hinaus. Aber mal so ein richtig schön großes System aufbauen, würde mir schon Spaß machen. :)

Leider ist das auch für meine Kunden auf Spatzen geschossen. Denen kann ich sowas nicht mit gutem Gewissen andrehen. Nachdem dort teilweise noch Unternehmenssoftware von 1999 eingesetzt wird mit Unterstützung von max. 2GB RAM und Singlecore ;(. Hatte ja schon nen schlechtes Gewissen bei den 32GB RAM für den letzten "Server" (Ryzen 1800X). Bissi Dateifreigabe und eine 4GB große SQL Datenbank.

Ich brauch größere Kunden :D
 
dass schrieb:
Es ist schön euphorisch um den Aktienkurs zu sein, aber ich will nur aufmerksam machen dass im letzten annual report von AMD das folgende dran steht:
Das ist ein Standardspruch, der jedes Jahr unter dem Punkt Risikofaktoren aufgeführt wird.
 
modena.ch schrieb:
Naja ich kann diverse Software relativ leicht auf einen CCX festnageln bzw auf demselben DIE das ist nun kein Hexenwerk

Da Server heute meist virtualisiert sind (regelt damit der Hypervisor) und die VMs oft einen unterschiedlichen Bedarf an Arbeitsspeicher haben ist das ein ziemlich komplexes Thema welches mit zunehmender Anzahl an Nodes nicht gerade einfacher wird.

Dann kauf ich einfach mehr kleinere Module und das Problem ist auch keines mehr.

Die Teilbestückung ist bei Servern recht häufig da man eben keine kleinen Module verbauen will denn die sind später oft völlig nutzlos. Hinzu kommt das je nach Einsatzzweck und CPU die Bandbreite nicht benötigt wird. Weniger aktive Speicherkanäle und Module heißt auch weniger Verlustleistung. Das trifft vor allen die kleineren Epycs. Bei 16C mit 4 DIEs (Interconnects + IMCs) wird proportional betrachtet viel Energie für Interconnects und IMCs verheizt.
 
Zuletzt bearbeitet:
xexex schrieb:
Habe ich behauptet sie macht Probleme? Sie kann Probleme machen.

Das ist der Speicherdurchsatz einer EPYC CPU im Vergleich zu einem Xeon.
Anhang anzeigen 710205
https://www.anandtech.com/show/11544/intel-skylake-ep-vs-amd-epyc-7000-cpu-battle-of-the-decade/12

Wie gewährleistest du, dass eine Applikation, die womöglich in einer VM läuft mit solchen "seltsamen" Aufbau konstante Ergebnisse bringt? Her damit!

Nimm einen SQL Server installiere ihn auf rohen Blech und gib ihm 64 Kerne, da wird der EPYC abgehen. Installiere ein paar VMs mit Terminalserver, SQL Server, Exchange, SAP und du wirst je nach VM Konfiguration und Vorlieben deines VM Hosts unterschiedliche Ergebnisse bekommen.

Beide Virtualisierer die ich gut kenne und für die ich zertifiziert bin (ESX und Hyper-V), werden eine VM zunächst immer auf einem NUMA Node halten, damit erreicht eine EPYC CPU aber nur einen Bruchteil vom möglichen Speicherdurchsatz. Was du also brauchst ist eine Applikation die NUMA Aware ist und Fummelei in deinem Virtualisierungshost, damit er die vCPUs aufteilt auf verschiedene Kerne aufteilt. Dann kannst du aber nur hoffen, dass die Applikationsthreads unabhängig voneinander arbeiten wie bei einem SQL Server. Hast du stattdessen einen Terminal Server unter Windows, willst du ja nicht, dass die Threads von Kern zu Kern geschaltet werden.

Am Ende brauchst du für solche gemischten Workloads Optimierung und Tests, die kosten Zeit und Zeit ist bekanntlich Geld.
Das bestreite ich auch gar nicht, man kann aber ohne viel Aufwand den VMs bestimmte Kerne/Threads zuweisen/pinnen, jeweils nach socket und auch CCX.
Also das dürfte für gute Server Admins je nach Anzahl der VMs und Applikationen nun nicht der riesige Valdierungsaufwand sein.
Ich geb zu, dass es etwas mehr Aufwand ist, die optimale Konstellation herauszufinden, als beim Intel, aber es ist kein riesen Aufwand.
 
DonL_ schrieb:
Also das dürfte für gute Server Admins je nach Anzahl der VMs und Applikationen nun nicht der riesige Valdierungsaufwand sein.

Bisher haben ich vor allem von mir gesprochen, der in einem Systemhaus sitzt und darüber entscheidet ob wir etwas ruhigen Gewissens verkaufen können.... Genau hier endet eigentlich die Überlegung, da ich häufig nicht mal genau weiß welche Applikationen der Kunde derzeit einsetzt und definitiv nicht wissen kann welche er in der Zukunft einsetzen wollen wird.

Die EPYCs sind tolle CPUs wenn, wie du schon sagst, die interne IT die Zeit und die Möglichkeit hat den Anwendungsfall zu spezifizieren und zu optimieren. Eine feste Zuweisung von Kernen macht man allerdings auch nur bei einzelnen Servern, in einer Farm wird so ein Konzept nie aufgehen und unter Hyper-V wirst du nie eine so genaue CPU Zuweisung machen können.

Ich bin der erste der solche Hardware wieder in Erwägung ziehen wird, wenn:
a) Die Single Core Leistung annähernd die Xeons einholt (Lizenzen werden heutzutage pro Kern verkauft und schon längst nicht mehr per Sockel)
b) Die Speicheranbindung konsistenter gestaltet wird. (Selbst wenn es nur ein grosser L4 Cache wird)
 
Zuletzt bearbeitet:
Zurück
Oben