holdes schrieb:
Bei uns lief das bisher eigentlich relativ gut wenn die Generationen nicht zu weit auseinanderliegen und man kein SAP HANA einsetzt welches TSX anspricht.
Einfach den EVC Mode einknipsen auf den kleinsten gemeinsamen Nenner und ab dafür. Das Problem ist, das nur out of the box Intel mit Intel kompatibel ist und AMD mit AMD. Beides zusammen in ein Cluster heist, du fingerst da mit CPU Bitfolgen in irgendwelchen Advanced Configs rum. Das KANN man alles machen - irgendwie. Nur dafür interessiert sich da draußen real praktisch keine Person, die irgendwie auch nur ansatzweise mit der Technik zu tun hat. Das muss laufen und möglichst ohne Bastel Schwurbel Mist. Ich hatte früher zu K8/K10 Opteron Zeiten mal nen Core2 based Xeon im Cluster mit nem AMD. Das war schon nicht soooo ultra schön.
In einem Enterprise Cluster kann man das sogar noch bisschen abfedern, weil DRS dafür sorgt, dass die Last verteilt wird bei Bedarf. Was dennoch mehr schlecht als recht funktioniert ist das hantieren mit seeehr unterschiedlichen CPU Geschwindigkeiten.
Richtig hässlich wird sowas schon bei seeehr hohen Turbo Boost Deltas. Ich hatte hier jüngst nen Spielehost auf nem Intel NUC in den Fingern. So ein "U" Mobile 6C/12T Prozessor. 1,1GHz Base. Da hast du dann bei vier vCPUs in einer VM 120% CPU Auslastung laut Host
weil er 12T x 1,1GHz = 13,2GHz rechnet. Der Boost der Mobile CPU bei guter Kühlung aber in die Region hohe drei Komma GHz geht. Sowas mit CPUs zu paaren, die ganz andere Charakteristik haben in einem (DRS) Cluster würde alle Nase lang VMs rumfliegen lassen...
Alexander2 schrieb:
Ja, es werden mehrere Chiplets verwendet, das stimmt wohl :-)
Es wird halt ein Vollfunktionsfähiger Chiplet verwendet und alle anderen dürfen ziemlich sicher teildefekte sein, wo "nur" der Cache sauber laufen muss.
Das Konstrukt lässt doch eh nur zu, gerade Teiler einzusetzen. Es muss immer die gleiche Anzahl an Kernen pro CCD aktiv sein. Zumindest ist das meines Wissens nach wie vor der Fall. Ggü. Zen2 hat sich das etwas "gebessert", weil bei Zen2 war es die gleiche Menge an Kernen pro CCX - und ein Zen2 CCD bestand aus zwei CCXen. Weswegen 56C erst mit Zen3 und nicht schon mit Zen3 gehen. 24C hingegen gehen - mit vier aktiven CCDs zu je drei Cores je CCX.
Btw. ergibt alles andere auch gar keinen Sinn (technisch). Der Cache soll Zugriffe abpuffern, die über die IF erfolgen. Würde man jetzt den Cache verteilen hast du exakt gar nichts gewonnen. Weil die Links der IF insich sehr langsam sind. Man benötigt zwei CCD um überhaupt mal die Speicherbandbreite lesend und schreibend! von zwei Channeln übertragen zu bekommen. Epyc hat derer acht. Zwar ist die eine Richtung selbst gemachtes übel, weil AMD das künstlich kastriert hat, aber auch lesend vom RAM schafft man pro CCD nur die Bandbreite von ca. einem Memory Kanal. Soll heißen - es ergibt überhaupt keinen Sinn vom CCD über die IF zum IO Die und dann nochmal über die IF zu nem anderen CCD und dessen L3 Cache zu greifen -> weil man kann am IO Die in den Memory abbiegen und hat vieeeel mehr Menge an "Cache" zur Verfügung. Man will aber eigentlcih gar nicht die IF bemühen - denn da ist noch ganz anderer Traffic los. Man möchte möglichst lokal alles aus den Cache Stufen der CCDs abfedern. Das geht mit niedrigen Latenzen und im Bereich hunderter GB/sec an Bandbreite. So ein einziger IF Link von CCD zu IO Die ist wie breit? 16-18GB/sec oder sowas?
.
