News Server-Prozessor: Massive Preisnachlässe bei Intel Xeon wegen AMD Epyc

[xexex]

Ach, sind wir nun gerade klammheimlich von Intel vs. AMD nach Windows vs. Linux gewechselt?

Du hast behauptet Windows hat Probleme mit CPUs, deshalb setzen angeblich viele Linux ein. Was zwar Quatsch ist, aber ich lasse es hier mal so stehen.

Schlussfolgerung davon ist letztlich, dass man EPYC nun wohl kaum für Windows empfehlen kann oder? Wenn Windows Probleme mit EPYC CPUs hat, was in der Tat der Fall ist, wie diverse Tests zeigen, ist EPYC nun mal nichts für Serversysteme die auf Windows Basis laufen.....
https://www.phoronix.com/scan.php?page=news_item&px=Netperf-Windows-Linux

Dafür braucht man kein Studium um es zu verstehen.

 

[Smartcom5]

Ach, sind wir nun gerade klammheimlich von Intel vs. AMD nach Windows vs. Linux gewechselt?

Flamewar ist Flamewar!

In diesem Sinne

Smartcom

 

[Hayda Ministral]

Du hast behauptet Windows hat Probleme mit CPUs

Ich schrieb von CPU-Konfiguration. Und das nicht im Kontext eines Windows vs. Linux sondern als Hinweis darauf das Windows nur ein mögliches OS ist wenn es um Workstation und Server geht und das entsprechend Probleme die Windows mit einer CPU-Konfiguration hat nicht notwendigerweise ein Ausschlußkriterium der CPU bilden.

Dafür braucht man kein Studium um es zu verstehen.

Da stimme ich Dir zu. Lesen zu können ist aber meiner Erfahrung nach kein Nachteil.

 

[chithanh]

Ups, irgendwie ist dieser Beitrag bei mir untergegangen. Falls es noch relevant ist, hier meine Antwort:

Du redest hier von Windows 10 und einem Problem, was anscheinend behoben wurde. Was hat das nun mit Windows Server und der Unterstützung von vielen Kernen zu tun?

Windows 10 und Windows Server unterscheiden sich da nur in Details. Die Windows-Skalierungsprobleme treten mit schöner Regelmäßigkeit immer dann auf, wenn mehr Kerne als bislang üblich auf eine bestimmte Aufgabe angesetzt werden.
Diejenigen Forennutzer, die alt genug sind, erinnern sich vielleicht noch an den AMD Dual-Core Optimizer für Windows.

24 Kerne sind heutzutage bei einem Server schon fast recht wenig. Der Preis/Kern Sweetspot liegt irgendwo bei 14 Kernen und ergibt dann 28 Kerne aufgeteilt auf 2 NUMA Nodes, die man durchaus schon als "Masse" bezeichnen kann. Irgendwelche Probleme wären da schon längst bekannt und zig mal behoben worden. Was glaubst du auf welcher Basis die gesamte Azure Cloud aufgebaut ist?

Mit Epyc betritt man dennoch Neuland. Plötzlich bekommt man 32 Kerne / 64 Thread-CPUs mit NUMA zum gleichen Preis wie zuvor nur 20C/40T ohne NUMA. Das heißt, entsprechende Kunden können auf einmal 50% mehr Kerne und 300% mehr NUMA-Nodes auf die gleichen Aufgaben ansetzen.

Das Windows Bugs hat, wie jedes andere System, dürfte jedem klar sein und viele Bugs merkt man erst wenn irgendeine Grenze überschritten wurde.

Interessanterweise waren die von den Chromium-Entwicklern gefundenen Bugs Microsoft teilweise schon bekannt, aber sie haben erst dann mit der Fehlerbehebung begonnen als es öffentlich wurde. Das steht im krassen Gegensatz dazu, wie Bugs unter Linux behandelt werden.

Teilweise ist es auch kein richtiger Bug sondern krass schlechtes Design, wie das single-threaded Prozessabräumen. Und obwohl Microsoft das inzwischen gefixt hat, gibt es weiterhin richtig üble Defizite dieser Art im Betriebssystem.

Ein Beispiel ist der Indigo-Benchmark. 2990WX unter Linux erreicht ~3200 Punkte ootb, ~3500 Punkte nach kleineren Optimierungen in diesem Benchmark.

Level1Techs haben sich das mal genauer angesehen, warum der 2990WX im Indigo unter Windows so schlecht performt. Und es stellt sich heraus, wenn man den Benchmark per Prozess-Lasso auf 63 logische Kerne beschränkt und einen freilässt, dann kommt er plötzlich auf über 3000 Punkte. Dieser eine Kern wird aber dennoch ausgelastet, und zwar von Windows mit irgendwelchen Verwaltungsaufgaben - die wie es scheint nur single-threaded abgearbeitet werden.

Hier wird es erklärt, zwischen 7:47 und 8:35, das Video lohnt sich aber in Gänze anzusehen:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[xexex]

Mit Epyc betritt man dennoch Neuland. Plötzlich bekommt man 32 Kerne / 64 Thread-CPUs mit NUMA zum gleichen Preis wie zuvor nur 20C/40T ohne NUMA. Das heißt, entsprechende Kunden können auf einmal 50% mehr Kerne und 300% mehr NUMA-Nodes auf die gleichen Aufgaben ansetzen.

Es liest sich bei dir so als wäre NUMA was gutes, was es allerdings nicht ist. Optimal wäre immer ein einziges Node, bei dem alle Kerne mit voller Geschwindigkeit auf den Speicher zugreifen können.

NUMA (non-uniform memory access) deklariert letztlich nur bestimmte Kerngruppen und Speicherbereiche als lokal und remote. Applikationen und Lasten die damit recht gut umgehen können, können so einen Teil der Kerne jeweils nur auf den lokalen Speicher zugreifen lassen.

Bei Intel ist es klar geregelt, du hast bei einem Dual-Sockel System zwei CPUs die jeweils den vollen Speicherzugriff haben und UPI/QPI, was diese CPUs verbindet. Im Optimalfall nutzt eine VM oder eine Applikation nur eine CPU und daran angebundenen Speicher, wenn das nicht geht, müssen die Daten über den Link. Das klappt auch soweit meist wunderbar, bei den "beliebten" DS Systemen hast du zwei CPUs mit vergleichsweise vielen Kernen und entsprechend viel Speicher an jeder Node.

EPYC macht nun aber aus jeder CPU ein 4 Node System und bindet jede Node an nur 2 Speicherkanäle an. Hier fällt die Aufteilung nun lange nicht so einfach aus, weil du vergleichsweise wenig Speicher an jeder Node hast und bei den kleineren EPYCs auch recht wenig Kerne. Das funktioniert eigentlich nur gut wenn viele Threads mit eher wenig Speicherzugriffen autark Berechnungen durchführen können und auch nur dann, wenn der Scheduler diese Threads nicht ständig umverteilt.

Aus diesem Grund ist zum Beispiel Cinebench eine Vorzeigedisziplin bei EPYC, aber auch andere Numbercruncher Aufgaben. Ebenfalls in das Schema passen Cloud Provider die vergleichsweise kleine VMs vermieten. Braucht eine Applikation viel Speicher oder hohen Speicherdurchsatz, wird es für EPYC zum Problem und alles muss ständig über IF transportiert werden.

Aber um auf den Kern meiner Aussage zurückzukommen, EPYC macht es komplizierter und nicht einfacher. schneller oder "besser".

 

[chithanh]

Es liest sich bei dir so als wäre NUMA was gutes

Nein, wo? Die gleiche Leistung über mehr Kerne und mehr NUMA-Nodes zu verteilen, verschärft die Anforderungen an Anwendungen und Betriebssysteme. Solche die schlecht darauf vorbereitet sind, performen dann schlechter.

Braucht eine Applikation viel Speicher oder hohen Speicherdurchsatz, wird es für EPYC zum Problem und alles muss ständig über IF transportiert werden.

Das es zum Problem wird gilt nicht generell. Selbst Anwendungsfälle, die typischerweise durch den Speicherdurchsatz limitiert sind (etwa CFD) skalieren noch sehr gut auf Epyc. Da kommt es aber massiv darauf an, wie gut oder schlecht Anwendungen und Betriebssysteme mitmachen:

Entweder gar nicht:

Oder mehr schlecht als recht:

Oder einigermaßen gut:

Aber um auf den Kern meiner Aussage zurückzukommen, EPYC macht es komplizierter und nicht einfacher. schneller oder "besser".

Das ist so allgemein ausgedrückt falsch.

Epyc hat tatsächlich Eigenheiten, die bei Xeon so nicht der Fall sind. Umgekehrt gibt es auch bei Xeon Fälle, in denen ausgesprochen schlecht performt wird. Wie man aber gesehen hat, sind die Probleme bei Epyc in den bisher aufgedeckten Fällen entweder das Betriebssystem (7-zip, Indigo), oder die Anwendung (Euler CFD), oder eine Kombination aus beidem.

 

[xexex]

Nein, wo? Die gleiche Leistung über mehr Kerne und mehr NUMA-Nodes zu verteilen, verschärft die Anforderungen an Anwendungen und Betriebssysteme. Solche die schlecht darauf vorbereitet sind, performen dann schlechter.

Mit Epyc betritt man dennoch Neuland. Plötzlich bekommt man 32 Kerne / 64 Thread-CPUs mit NUMA zum gleichen Preis wie zuvor nur 20C/40T ohne NUMA.

Hört sich für mich nach: 50% mehr zum gleichen Preis an, wurde nur vergessen zu erwähnen, dass es dafür 20 Einzelpackungen statt einer Großpackung sind.

Wie man aber gesehen hat, sind die Probleme bei Epyc in den bisher aufgedeckten Fällen entweder das Betriebssystem (7-zip, Indigo), oder die Anwendung (Euler CFD), oder eine Kombination aus beidem.

Ich muss zugeben, dass mich diese Anwendungsfälle bei Epyc nicht wirklich interessieren. Für mich stellt sich bei den Server-CPUs in erster Linie die Frage wie gut sie universell einsetzbar sind. Dann überlege ich wo man eventuell die Stärken des Systems ausspielen könnte.

Leider ist es natürlich bei Serversystemen nicht so einfach, dass man ein Benchmark durchjagt und mitkriegt was für eine CPU Leistung man fürs Geld bekommt. In Moment habe ich die Frage einfach zur Seite gelegt, da die Epycs allesamt nur recht wenig Takt pro Kern bieten, die Lizenzen aber pro Kern und nicht pro Sockel beschafft werden müssen, ist die erste Generation von vorne herein uninteressant gewesen.

Threadripper wäre hingegen durchaus für Server interessant gewesen, leider gibt es nicht ein Mainboard, was sich dafür eignen würde oder einen OEM der daraus Server bauen würde. Mal schauen was kommendes Jahr vorgestellt wird.

 

[MK one]

typischer xexex Bla Bla ...

schon aufgefallen das EPYC und TR sich nur im Takt unterscheiden und beim Speicher ?
EPYC unterstützt ECC mir Reg , was für Server wichtig ist - TR nicht und Octa statt Quad Channel , wieso sollte man also einen TR als Server nutzen wollen . Nur wegen dem Takt ?
Mit Epyc Rome wird es sicher auch einige hochtaktende Versionen geben mit weniger Kernen , jedoch ist im Server Bereich in der Regel Effizienz wichtiger als Takt , jedenfalls bei Systemen die dutzende oder gar 100 derte Blades benutzen wie zb in einem Rechenzentrum .

 

[Smartcom5]

…
In Moment habe ich die Frage einfach zur Seite gelegt, da die Epycs allesamt nur recht wenig Takt pro Kern bieten, die Lizenzen aber pro Kern und nicht pro Sockel beschafft werden müssen, ist die erste Generation von vorne herein uninteressant gewesen.

Nur interessehalber; Welche Software wird denn 'bei Euch' per Kern lizenziert?


In diesem Sinne

Smartcom

 

[xexex]

wieso sollte man also einen TR als Server nutzen wollen . Nur wegen dem Takt ?

Die schnellste Epyc CPU hat einen maximalen Boost auf 3,2Ghz, der zum TR vergleichbare Epyc 7551P boostet auf maximal 3Ghz. Für 2.500,- gibt es hier also 32 Kerne mit maximal 3Ghz, alternativ 2x16C 2,9Ghz für gute 2400€.

Ein Threadripper 2950X hat schon einen höheren Grundtakt als diese CPUs und boostet auf 4,4Ghz. Es geht hier nicht um "nur" es macht einen gewaltigen Unterschied!

Vergleichbare Intel CPUs gibt es in mehreren "Geschmacksrichtungen" einmal die normalen Varianten....

….einmal die High Clock CPU Varianten...

...und einmal die W Varianten für Workstations.

Derzeit hat AMD dem wenig entgegen zu setzen. Eine Epyc Workstation ist mäh, für den Terminalserverbetrieb oder die SQL Antwortzeiten sind die niedrigen Taktraten suboptimal und bei Kernlizenzierung bezahlt man schlichtweg mehr für weniger Leistung, was jeglichen Preisvorteil auffrisst.

Ein TR-2950X wäre für solche Anwendungsfälle eine perfekte CPU, nur gibt es dafür keine Boards für diesen Markt und auch keine Reg-RAM Unterstützung, aber ich wiederhole mich.

Nur interessehalber; Welche Software wird denn 'bei Euch' per Kern lizenziert?

In erster Linie Windows Server, das macht vor allem bei den Datacenter Lizenzen einen nicht unerheblichen Preisunterschied.

https://www.software-express.de/hersteller/microsoft/windows-server-2016/datacenter/

Lizenzen für Microsoft SQL Server oder Oracle sind noch eine ganz andere Nummer.

Zwecks Berechnung der Zahl an Prozessoren, die lizenziert werden müssen, werden im Falle von AMD und Intel Multicore Chips „n“ Prozessorkerne durch Multiplizieren der Gesamtzahl aller Kerne mit dem Faktor 0,50 bestimmt.