Userreview Threadripper & Experimente... ;)

B

Besterino

Urgestein
Mitglied seit
Jul 22, 2018
Beiträge
6.734
Bewertungspunkte
3.328
Punkte
112
Moinsen!

Er ist da, also darf gebastelt werden:

1442

In einem ersten Schritt soll das System aus folgenden Komponenten bestehen:

1. CPU: Threadripper 1920X
2. Board: Asus Prime X399 A
3. RAM: 2x 16GB Kingston Server Premier (KSM29RS4/16HCI - ECC RDIMM)
4. Kühler: Watercool Heatkiller IV Pro
5. GPU: 2080Ti FE
6. Storage: Diverse SSDs
7. Netzwerk: Mellanox Connectx-4 Dual 100Gbit (MCX456A-ECAT)
8. Gehäuse: Thermaltake Core P7

Nr. 1 und 2 sind eigentlich nur als Übergangslösung gedacht, bis die neuen Threadripper rauskommen und das eigentlich gewünschte Mainboard verfügbar ist. Mittelfristig soll nämlich idealerweise ein "Zen2 TR3000" - und dann am liebsten auf dem ASRock Rack X399D8A-2T (mein aktuelles TR4-Traumboard)- einziehen. Dieses Mainboard erklärt auch die sehr ungewöhliche / experimentelle RAM-Auswahl: beim RAM habe ich nämlich höchste Zweifel, ob der laufen wird - in dem Board und mit Threadripper allgemein, weil es sich um registered ECC RAM handelt. Den kann die Plattform eigentlich nicht. Der einzige Grund, warum ich das überhaupt versuche, liegt darin, dass der RAM in der Memory QVL von ASRock Rack zu meinem genannten Traumboard geführt wird. Witzigerweise als einziger 2933 RAM...

Heute kommt dann also schon einmal ein erster Test, ob vielleicht der Speicherkontroller vom TR allgemein mehr kann, als man gemeinhin glaubt... ;) Falls nicht, hab ich hier noch ein paar unbuffered ECC Riegel liegen (allerdings nur 2400er :( ) und dann bleibt nur die (dann noch geringere) Hoffnung, dass es vielleicht mit dem ASRock Rack Board klappt. Wenn mir da nicht der ASRock Rack Support schon vorher mit einer Negativaussage die Illusion raubt... (zurzeit pending).

Wie dem auch sei, jetzt kann erstmal der 1920X ausgetestet werden, wie der sich so im Alltag anfühlt. Ich werde berichten... schau'mer mal, dann seh'ma schon... :p
 
Sortiere nach Datum Sortiere nach Stimmen
EDIT & Korrektur: ESXi lässt ein Passthrough-Device gleichzeitig an verschiedene VMs anbinden. Du musst vermutlich nur aufpassen, dass nicht beide VMs gleichzeitig laufen.
 
Zuletzt bearbeitet :
Upvote 0 Downvote
Getreu dem Motto "nur weil es noch nicht wie gewünscht läuft, heißt das noch lange nicht, dass man nicht weiter dran rumfrickeln kann" werde ich mich heute mal mit dem Thema RAM beschäftigen: hier liegen zwei Kingston 3600/17/19/19er 32GB HyperX Predator Kits (je 2x16GB). Die insgesamt 64GB werde ich zunächst erst einmal ohne Virtualisierung/ESXi testen. Mehr als 3200 erwarte ich bei 4x Dual Rank DIMMs allerdings nicht wirklich, bzw. wäre schon ein super Ergebnis. Denke, ich werde eher bei um die 2933 landen. Schau'mer mal...

Dafür aber vielleicht endlich Quad (bzw. 2x Dual) Channel. :p Werde das dann auch mal zu Testzwecken auf 2666 laufen lassen...
 
Upvote 0 Downvote
Mögen die RAM-Spielereien beginnen...

Zur Erinnerung:
CPU: AMD TR 1920X@4GHz
Board: ASUS X399 Prime A
GPU: 2080Ti FE (+115MHz Core)

4GHz und 2x16GB 2400er RAM @2666 (Kingston ECC UDIMMs):

Total: 11776
Grafik: 14241
CPU: 5945

Genauso wie oben, nur eben 4x16GB 3600er RAM @2666 (Kingston HyperX Predator):

Total: 13272
Grafik: 14190
CPU: 9712

Krass. 1500 Punkte Differenz. Also 3DMark jedenfalls mag mehr RAM... Timings hab ich jetzt nicht verglichen, stand jeweils auf "Auto".

Zum Vergleich noch mit Graka@stock:
Total: 13060
Grafik: 13880
CPU: 9788
 
Upvote 0 Downvote
Jo, schrieb ich oben. Kann leider nicht testen, wie es mit 4x 8GB Modulen wäre.
 
Upvote 0 Downvote
Aktueller Zwischenstand:

Orientiere mich an diesem - aus meiner Sicht echt sehr hilfreichen - How-To von einem aus der Computerbase-Community (über's Luxx gefunden): Ryzen RAM OC Anleitung

Habe jetzt aktuell von dem Guru3D DRAM Calculator for Ryzen die "Fast" Settings laufen... Stabilitätstest steht noch aus, hab nur eben 3DMark mal durchlaufen lassen:

4x16GB@3200/14/14/17/18/28/42

Insgesamt: 13594
Grafik: 14255
CPU: 10767

Schön, die 10.000er Marke hätten wir dann schonmal bei der CPU. :p

EDIT: ...aber die 14.000er Marke insgesamt sollte es heute noch nicht sein: 13.942
 
Zuletzt bearbeitet :
Upvote 0 Downvote
So, auf 3200 ist der RAM mit den oben genannten Settings wohl stable: Der Karhu RAM Test läuft jetzt seit heute 2 Uhr morgens und zeigt bei ~10.800% keine Fehler. :)

Dann wären wohl als nächstes schärfere (Sub)Timings oder höherer RAM-Takt auf der Agenda... :)
 
Upvote 0 Downvote
Upvote 0 Downvote
So, ein bisserl Spielerei musste nochmal sein:

1. Zur Erinnerung: der i7-7700K mit seiner VM (8 Kerne) lag all@stock bei:
Insgesamt: 11462
Grafik: 14413
CPU: 5306

2. 1920X@8x4GHz, GPU@Stock
Insgesamt: 12251
GPU: 14645
CPU: 6361

3. 1920X@8x4GHz, GPU+115MHz
Insgesamt: 12299
GPU: 15043
CPU: 6048

(ganz ordentliche Varianz beim CPU-Score, obwohl ich daran gar nichts geändert hatte)

4. 1920X@12x4GHz, GPU@stock
Insgesamt: 13114
GPU: 14277
CPU: 8974

5. 1920X@16x4GHz, GPU@stock
Insgesamt: 13239
GPU: 13946
CPU: 10288

(jetzt ganz ordentliche Varianz beim GPU-Score, obwohl keine Einstellungen dazu geändert)

6. 1920X@20x4GHz, GPU@stock
Insgesamt: 13560
GPU: 14240
CPU: 10676

(Nicht mehr so ein Sprung wie von 12 auf 16 Threads.)

7. 1920X@20x4GHz, GPU@+115MHz
Insgesamt: 14240
GPU: 15101
CPU: 10765

Witzige Randbemerkung: Das ist aktuell meine persönliche TimeSpy Bestmarke - Windows 10 nativ mit 24 Threads @4,1GHz lief schlechter (13945). :D

Ich mag' ESXi. ;)

8. Fire Strike 20x4GHz, GPU+115
Insgesamt: 23853
GPU: 29240
CPU: 23418
 
Zuletzt bearbeitet :
Upvote 0 Downvote
Virtuelle. ESXI behandelt an der Stelle echte Kerne und SMT gleich, d.h. ich könnte der VM bis zu 24 Kerne zuweisen. Hab aber noch nicht herausgefunden, wie ich da differenzieren kann (also z.B. mal zu Testzwecken 6 echte + 6 SMT vs. 12 echte).

TimeSpy für 16 und 20 Threads oben eingefügt.

Und damit es nicht ganz so textlastig / langweilig hier zugeht, hier mal 2 Bilder: 1x Gesamtsystem (als noch das ASUS Board im System war) und 1x von meiner super-duper-Aquaero-Aufhängung mit durchsichtigem Klebeband@Glas. :D

1520

1521

Sorry für die Quali, Kabel-Chaos und außen klebt auch noch die Schutzfolie am Glas. Hat halt alles noch "Lab-Charme"... ;)

EDIT: noch ein paar Benches oben ergänzt.
 
Zuletzt bearbeitet :
Upvote 0 Downvote
Mal ein kurzes Update: ich bilde mir ein, dass bei meinem System bei zwei Gelegenheiten in Tom Clancy's Rainbow Six Siege sehr störende Ruckler aufgetreten sind, nachdem das System mehrere Tage am Stück ohne Reboot lief. Das erste Mal fiel mir das auf, als das Spiel in einer VM lief, so dass ich natürlich erst mein ESXi-Win10-GPU-Passthrough-Frickelgebilde im Verdacht hatte. Beim zweiten Mal war's aber Windows 10 nativ, allerdings gefühlt nicht ganz so extrem. Und man darf auch nicht vergessen, dass die native Win10-Installation ursprünglich ein Intel System war und insgesamt auch schon mehrere Jahre so läuft. Wer weiß, was sich da treibermäßig ggf. noch alles in Gehege kommt...

Die Kombination aus "erst nach längerer Laufzeit" und den völlig unterschiedlichen Rahmenbedingungen macht die Fehlersuche leider etwas kompliziert. Umgekehrt hab' ich aber dafür noch Hoffnung, dass sich die Gaming-VM auf ESXi-Basis mit dem Threadripper-System doch sauber realisieren lässt...

...also teste ich jetzt erst einmal mit ESXi weiter. :D

Zunächst hatte ich ja einen onboard USB3-Controller per PCIe-Passthrough in die VM gehängt (den braucht man, damit man nativ Eingaben von Maus und Keyboard in die VM bringen kann). Bis ich das überhaupt halbwegs lauffähig hatte (vor allem der USB-controller einen reboot der VM überlebte) dauerte ja einige Zeit. Und das Ganze war mir auch nicht so richtig geheuer, da die USB3-Controller des Mainboards alle in PCI-Gruppen mit anderen Geräten hängen: von denen weiß ich zum Teil überhaupt nicht, was sie machen und leider muss man sie zusammen mit dem USB-Controller dem Host "wegnehmen" (warum? Siehe Spoiler).

Wer will: Kleiner Exkurs zum Thema PCIe-Passthrough
PCIe-Passthrough funktioniert grds. so, dass ein entsprechendes Gerät dem Zugriff des Hypervisors (auch "Host" genannt) vollständig entzogen wird, und dann eine virtuelle Maschine (VM) die vollständige Kontrolle über dieses Gerät erhält. Für den Host existiert das Gerät dann schlicht nicht mehr - übrigens unabhängig davon, ob die entsprechende VM läuft oder nicht. Für das VM-Betriebssystem (auch "Gast-OS") erscheint das Gerät dann so und ist so verwalt- und steuerbar, wie es auch bei einer ganz normalen Installation des OS "direkt auf dem Blech" (engl. "bare metal"), also ohne den Hypervisor (bzw. "Virtualisierungs-Layer"), erscheinen würde.

Der große Vorteil von PCIe-Passthrough ist vor allem, dass die Performance des Geräts uneingeschränkt der VM zur Verfügung steht und es (so gut wie) keine Performance-Einbußen im Vergleich zu einer normalen / "bare metal" Konfiguration gibt. Darüber hinaus stehen dem Gast-OS eben auch wirklich uneingeschränkt alle Funktionen des Geräts zur Verfügung. Beispiel: bei einem komplett durchgereichten SAS-Controller kann die VM selbst die SMART-Werte, Sensoren o.ä. der HDDs auslesen oder lowlevel Kommandos an die Datenträger über den SAS-Bus absetzen. Mit virtuellen Festplatten oder selbst vollständig durchgereichten Datenträgern funktioniert das nicht, da das Host-OS (hier ESXi) die Kontrolle über den Controller selbst behält. Das Gast-OS bleibt hierzu also vergleichsweise "dumm & ahnungslos". Das ist aber beim einem SAS-Controller mit mehreren Laufwerken dran insbesondere ungünstig, wenn eine VM die Platten bekommen soll und die Aufgabe eines "NAS" bzw. "Storage-Servers" wahrnimmt... dann wäre es z.B. durchaus hilfreich zu wissen, dass eine HDDs haufenweise Errors wirft...

Und für uns Frickler im Homelab sind weitere positive Nebeneffekte, dass (i) das Gerät aus der VM mit den ganz normalen Treibern des VM-OS angesteuert werden kann (es also keine speziellen Treiber für den Hypervisor geben muss) und (ii) es den Treiber deutlich schwerer fällt, zu erkennen, dass sie in einer VM laufen... Dann kann man insbesondere den fehlenden Support des Geräte-Herstellers und/oder des Host-OS für das Gerät ignorieren und das Gerät einem OS in der VM überlassen, dass das Gerät eben unterstützt (= es gibt Treiber dafür). Dies ist wiederum wichtig, weil Hypervisor-OS's und Gerätehersteller z.T. stark zwischen Consumer- und Enterprise-Hardware differenzieren. Gerade nVidia ist berühmt-berüchtigt dafür, dass die Consumer-Geräte eigentlich nicht in Serverumgebungen (mit Server-Betriebssystemen) funktionieren (sollen)...

Die Details was geht und wie es geht sind im einzelnen aber etwas komplizierter. Denn natürlich erfolgt die Steuerung aller Geräte am Ende in ein und der gleichen CPU. Außerdem ist manchmal ein Gerät im physikalischen Sinne (z.B. eine Grafikkarte) nicht nur ein Gerät auch im "logischen" Sinn: eine Nvidia RTX 2080Ti bringt neben der GPU "als solches" nämlich u.a. auch noch einen Audio-Controller und einen USB-Controller mit. Insgesamt bevölkern hier 4 "Geräte" ein physikalisches "Gerät" und diese 4 Geräte hängen - logischerweise - in ein und demselben PCIe-Steckplatz. In der PCIe-Logik sieht das dann so aus, dass alle vier Geräte unter der gleichen Haupt-"PCIe-Adresse" (hier: 0000:0c:00) auftauchen und sich nur in einer kleinen Sub-ID am Ende unterscheiden (hier 0-3):

Bild: "4in1" bei einer Nvidia RTX 2080Ti (ESXi Hardwareverwaltung)
1629

Tja, und wie diese 4 Freunde sich dann ggf. separat ansteuern lassen, hängt dann von weiteren Details ab, wie z.B. von der Verschaltung der PCIe-Slots auf dem Mainboard und/oder der Logik von BIOS+CPU. Und hier zeigt sich dann auch gerne mal mit hässlicher Fratze, dass die logische Trennung von PCIe-Gerät und Host dann doch nicht 100%ig ist, denn der Host muss das PCIe-Gerät beim Start der VM ja doch noch irgendwie "bereitstellen", also Starten oder beim Shutdown/Reboot der VM stoppen oder resetten. Und da gibt der PCIe-Standard auch wieder diverse Varianten her, wie das umgesetzt werden kann und das kann sich auch wieder auf das Verhalten des Geräts auswirken...

Dieses "mehrere Geräte zusammen" Prinzip ist übrigens besonders häufig bei onboard-Komponenten der Fall: Wahrscheinlich auch um mit den PCIe-Lanes sparsam umzugehen, werden onboard einfach häufig viele Komponenten zusammengefasst. Bei meinem Board z.B. u.a. der USB3.1-Controller und der SATA-Controller:

Bild: "2in1" von SATA und USB 3.1 (ESXi Hardwareverwaltung)
1630

Das Fiese: Nimmt man ESXi diesen USB-Controller per PCIe-Passthrough weg, sind auch die Datenträger am SATA-Controller nicht mehr verfügbar... blöd. Also aufgepasst! ;)

Am Ende des Tages kann es recht schwierig / aufwändig (oder unmöglich) sein, logische Geräte auf ein und demselben physischen Gerät zu trennen und z.B. nur 2 von 3 dem Host wegzunehmen und 1 dem Host zu belassen. ESXi lässt das jedenfalls standardmäßig nicht zu. Und wenn das mit dem PCIe-Passthrough nicht auf Anhieb funktioniert, muss man da eben tiefer eintauchen und mit den verschiedenen Einstellmöglichkeiten herumspielen.

Das gilt übrigens prinzipiell für alle Hypervisoren, wobei diese eben mit den verschiedenen Themen unterschiedlich umgehen und unterschiedliche Konfigurationsmöglichkeiten bieten.

Das mit dem onboard-USB-PCIe-Passthrough ist mir jedenfalls nicht so recht geheuer und um eine mögliche Fehlerquelle auszuschließen, ist also jetzt meine bekannte und bewährte USB3-PCIe-Controllerkarte von Sedna ins System eingezogen: https://www.amazon.de/gp/product/B0183H6D4I/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

Ich habe jedenfalls mit den NEC USB-Chips speziell mit PCIe-Passthrough gute Erfahrungen gemacht und nachdem ich 2x mit anderen Herstellern ins Klo gegriffen habe (1x kullerte mir schon ein Cap beim Auspacken entgegen...), kauf' ich halt auch nur noch dieses Modell. Gebranntes Kind + Feuer und so...

Immerhin, diese Karte steht hier jetzt hübsch einzeln da, hat ihre eigene PCIe-Adresse und sollte sich mit keinerlei anderen Komponenten ins Gehege kommen.

Bild: Sedna USB-Controller (ESXi Hardwareverwaltung)
1631

In der VM sieht das Ganze dann auch ganz gut aus, bisher keine gelben Ausrufezeichen oder ähnlicher Ungemach.

Bild: Gerätemanager mit PCIe-Passthrough Geräten (Win10-VM)

1632

(Man beachte auch die "virtuellen" Grafikkarten, insb. von vmware.)

Tjo, und jetzt heißt es erst einmal wieder Testen & Beobachten, wie das mit den Rucklern weitergeht... (und vielleicht geb' ich der Gaming-VM auch noch ein paar GB mehr RAM - läuft ja aktuell eh nix anderes als die Gaming-VM auf dem Host).
 
Upvote 0 Downvote
Besterino hat gesagt. :
Mal ein kurzes Update: ich bilde mir ein, dass bei meinem System bei zwei Gelegenheiten in Tom Clancy's Rainbow Six Siege sehr störende Ruckler aufgetreten sind, nachdem das System mehrere Tage am Stück ohne Reboot lief
Zum Vergrößern anklicken....

Denke nicht das das am System oder zu wenig RAM in der VM liegt , Die Game leif bei mir letztens als man es kostenlos spielen konnte auf nem 4790 @ 3,8GHz mit 16 GB DDR3 und ner GTX 1060 in FHD mit über 150 FPS mehr als flüssig , ich denke da war irgend ein Hintergrundprozess ,Netzwerkgeist oder sonstiges auf Krawall aus , So wie es sich leißt waren das auch Ausnahmen die man mit der Lupe suchen muss.
 
Upvote 0 Downvote
Ne, war schon sehr störend und trübte auch deutlich das Spielerlebnis.
 
Upvote 0 Downvote
Nö. Always on VM.

Die ganze Virtualisierungsgeschichte macht für mich (ganz persönlich) nur Sinn mit einem Host, der 24/7 läuft. Wenn dann will ich ja einen Rechner ersetzen bzw. den Fuhrpark insgesamt reduzieren und da ich immer einen Server schon für Storage und diverse andere Dienste brauchen werde, muss dann eigentlich der Server „auch“ ein Gamer werden. Bzw. der Gamer muss dann auch Server sein. Klappt das nicht, kann ich’s auch lassen und alles lassen wie es ist - funzt ja alles bisher auch prima. :)

Aber der Traum, der Traum ist quasi mein ganz persönlicher Mainframe mit ein paar VMs für alle Zwecke und ansonsten nur noch Displays und ein paar Keyboards und Mäuse im Haus. :D Der einzige Haken ist dabei, dass ich natürlich bei der Verkabelung in den eigenen 4 Wänden nicht daran gedacht habe, auch Displayportkabel vom Keller durch die halbe Hütte zu ziehen... ;) Aber das sind Zukunftsphantasien und so ein Threadripper wäre halt ein lustiger preiswerter Schritt auf dem Weg dahin...
 
Upvote 0 Downvote
Mal ein kleines Update, auch wenn das hier wohl eher ein Exoten-Setup ist. ;) Vielleicht interessiert es ja trotzdem jemanden. :p

Seit jetzt knapp 4 Wochen habe ich die Gaming-VM quasi im Dauereinsatz: Rock stable, kein Absturz. Keine Probleme. (Ruckler/Sound habe ich auch im Griff.) Die native Windows-Installation (noch Dual Boot mit ESXi) vermisse ich Null, benutze ich zurzeit de facto gar nicht. Mal abgesehen von dem ein oder anderen Reboot der VM lief die 24/7 über die 4 Wochen - der Host lief konstant durch.

Gespielt habe ich primär Rainbow Six Siege und WOW Classic, also jetzt nicht die Hardcore-Auslastung. :D Aber Ghost Recon Breakpoint lacht mich auch schon an... schau‘mer mal.

Inzwischen ist auch noch eine 2TB Intel 660p NVME SSD eingezogen. Zu Testzwecken erst einmal per Passthrough in die Gaming-VM gehängt, läuft und lesen/schreiben bis zu ~1900MB/sec (sequentiell). Passt & reicht. Zum Vergleich: auf meinem iSCSI-Netzlaufwerk aus 4 billigen ADATA SATA-SSDs im RaidZ (quasi Raid5) vom Mainserver liest die Gaming VM mit 2200MB/s, schreibt aber „nur“ mit ca. 850MB/a.

Überlege nun, zum einen die Cores der Gaming VM von aktuell 20 auf vielleicht 12 zurückzustutzen (sollte immer noch locker für alles reichen) und zum anderen die 2TB SSD in eine eigene Solaris-ZFS Storage-VM zu hängen, analog zur Storage-VM in meinem Mainserver. Damit kann ich den Platz flexibler nutzen, z.B. einen Teil für regelmäßiges Back-up (ZFS-Replikation sei Dank) der wichtigsten Daten auf dem Mainserver. Vielleicht muss ich aber auch nochmal mehr ändern: die blöde x1-USB3-Steckkarte frisst aktuell einen 16er-Slot, den ich gut noch für etwas anderes gebrauchen könnte...
 
Upvote 0 Downvote
Um antworten zu können musst du eingeloggt sein.
Oben Unten