News AMD Epyc bereits mit B2-Stepping des Zeppelin-Dies? (Update)

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Nach etlichen Engineering-Samples im letzten Jahr befand AMD das Stepping B1 für reif, um in einem finalen Produkt eingesetzt zu werden, konkret im AMD Ryzen 7 seit März und und Ryzen 5 seit April 2017. Das französische Magazin Canard PC Hardware, das sich bereits im Vorfeld des Ryzen-Launches als zuverlässige Quelle in Sachen Leaks erwiesen hatte, hat in den letzten Tagen ein neues Stepping B2 ins Gespräch gebracht.
(…)

» Artikel lesen
 
Dann müssen es aber triftige Fehler im Uncore/SoC Bereich sein, wenn sie ein eigenes neues Stepping rechtfertigen.
 
Zuletzt bearbeitet:
Nicht zwingend - es reicht dass gewisse Server Features noch nicht "richtig" im B1 laufen aber für Desktop überhaupt nicht erforderlich sind, sodass AMD weiter verbessert bzw. optimiert und ein neues Stepping aufgelegt hat ...

Leider sind die youtube Videos nicht gut genug zu lesen, sonst hätte man bei diversen Clips die linux lshw Ausgaben lesen können.
 
Nicht zwingend - es reicht dass gewisse Server Features noch nicht "richtig" im B1 laufen aber für Desktop überhaupt nicht erforderlich sind
Ja, zum Beispiel im Bereich PCIe – das erwähnt Canard sogar explizit – was aber bei Ryzen für AM4 mit nur 16 Lanes schlicht egal ist? Wer weiß...
 
Zeppelin hat 32 Lanes für IO
Ryzen hat:
- 16 Lanes für PEG
- 8 Lanes für weitere PCIe
- 4 Lanes für Promontory (Chipsatz)
- 4 Lanes für 4 SATA Ports
= 32 Lanes
 
Zeppelin hat 32 Lanes für IO
Ryzen hat:
- 16 Lanes für PEG
- 8 Lanes für weitere PCIe
- 4 Lanes für Promontory (Chipsatz)
- 4 Lanes für 4 SATA Ports
= 32 Lanes
Jo, aber die 8 weiteren Lanes werden doch bei AM4 nicht genutzt, oder täusche ich mich da? Vom Ryzen für AM4 selber gehen doch nur die 16 (oder wahlweise 8+8 ) Lanes für PEG nach außen und die 4 für die Promontory-Anbindung (die wahlweise anderweitig verwendet werden können, wenn kein Zusatzchip verbaut ist wie z.B. beim X300) – sonst nix *kopfkratz
 
Jo, aber die 8 weiteren Lanes werden doch bei AM4 nicht genutzt, oder täusche ich mich da? Vom Ryzen für AM4 selber gehen doch nur die 16 (oder wahlweise 8+8 ) Lanes für PEG nach außen und die 4 für die Promontory-Anbindung (die wahlweise anderweitig verwendet werden können, wenn kein Zusatzchip verbaut ist wie z.B. beim X300) – sonst nix *kopfkratz

Der M.2 hängt noch am SoC.

Macht dann also 16 Lanes für PEG, 4 für M.2 und 4 für den Promontory - macht in Summe die 24 Lanes, die kommuniziert wurden.
 
M4 hängt nicht am S0C sondern teilt sich die vorhandenen Lanes - hat man halt nur 4 Lanes für andere Dinge (PCI-Bus, GLAN, WLAN ...)
 
M4 hängt nicht am S0C sondern teilt sich die vorhandenen Lanes - hat man halt nur 4 Lanes für andere Dinge (PCI-Bus, GLAN, WLAN ...)

M4? Meinst du M.2?

Und zudem hängen die ganzen anderen Sachen doch am Promontory.



EDIT: M.2 muss natürlich nicht am Prozessor hängen, das werden die meisten Boardhersteller aber wohl tun. Denn wenn man M.2 über den Promontory anbindet, hat man "nur" PCIe x4 2.0. Da werden die meisten Hersteller wohl lieber 3.0 vom SoC nehmen, weil sonst die Laufwerke limitiert werden.
 
Das Gerücht scheint sich zu bewahrheiten. In einem <a href="https://www.youtube.com/watch?v=NPyNuAt92WE" target="_blank">YouTube-Video</a> ist kurz die lscpu-Ausgabe für einen Epcy 7601 zu sehen:
<center><a href="https://www.planet3dnow.de/cms/wp-content/uploads/2017/06/b2-stepping.png"><img src="https://www.planet3dnow.de/cms/wp-content/uploads/2017/06/b2-stepping.png" alt="" width="466" height="352" class="aligncenter size-full wp-image-32639" /></a></center>

Zum Vergleich: hier mein Ryzen 7

b1-stepping.png
 
Zuletzt bearbeitet:
Die Dinger müssten dann ja auch demnächst in die normale Ryzen-Linie einfließen. Man sehen, ob sich evtl. auch was bei der Speicherverträglichkeit getan hat oder beim Verbrauch. Möglicherweise sind ja auch fürs Weihnachtsgeschäft ein paar MHz mehr drin (1900X?).
 
Die Dinger müssten dann ja auch demnächst in die normale Ryzen-Linie einfließen.

Ist das so sicher, oder ist AMD davon abgekommen, die Steppings zu wechseln? 2018 soll ja schon die nächste Generation kommen.
 
Zuletzt bearbeitet:
Na dann bewahrheitet sich meine Vermutung also doch. Ich bin mal gespannt, ob sie was an der Taktschraube drehen konnten. AVX2 Verbesserungen wären eine nette Sache.
 
Weil ...? Welche Einschränkungen hast du denn?

Ich nutze Ryzen mit Linux und habe bisher keinerlei Probleme.

Gruß,
Ritschie

Ich habe keine Einschränkungen :-)
Habe aber auch noch keinen Ryzen. Und ich werde sicher so lange warten, bis diese Thematik geklärt ist.

Schön für Dich, dass bei Dir das Problem nicht auftritt (oder so selten, dass Du es nicht merkst).
Das ist aber kein Trost für die Gentoo-Leute, die sich auf die vielen Kerne fürs Kompilieren gefreut haben und nun mit Instabilitäten zu kämpfen haben.
 
Ich hoffe, dass endlich mal dieses Problem gelöst wird:
gcc segmentation faults on Ryzen / Linux
https://community.amd.com/thread/215773?start=0&tstart=0
Aus dem Thread:
Cannot reproduce after 6 hours of kernel builds 3 Ryzen machines, Asrock x370 pro(1700x) and two x370 k4 (1700)

Ubuntu 17.04 with 4.12rc5 kernel
32GB ECC RAM at 2400Mhz for all three.(Correction from 16GB to 32 GB)
IOMMU/SRIOV/ ECC Options all enabled.
Infiniband Connect x3 cards installed.
Xeon Phi in x370 pro machine
x370 pro even has custom bios to enable above 4g decoding that is based on the 2.10 bios.

I cannot get this error to happen.
CPU temps never go above 55C, they are in cold basement.
IOMMU ist mit standard Einstellungen "disabled" im UEFI.

Zudem soll das abschalten von ALSR: https://de.wikipedia.org/wiki/Address_Space_Layout_Randomization den Fehler verhindern.
 
Ich habe keine Einschränkungen :-)
Habe aber auch noch keinen Ryzen. Und ich werde sicher so lange warten, bis diese Thematik geklärt ist.

Schön für Dich, dass bei Dir das Problem nicht auftritt (oder so selten, dass Du es nicht merkst).
Das ist aber kein Trost für die Gentoo-Leute, die sich auf die vielen Kerne fürs Kompilieren gefreut haben und nun mit Instabilitäten zu kämpfen haben.

Also ich habe das Problem auch in keinster Weise, kompiliere täglich mit gcc (inzwischen 7.1.1).
Das kann kein genereller Fehler im RyZen sein, höchstens eine Randerscheinung mit etwas anderem zusammen.
 
Ich hoffe ja auch, dass der Grund für die Probleme mit gcc gefunden und behoben wird.
Der Thread im AMD Forum zeigt aber, dass es nicht nur ein Troll ist, der irgendwas behauptet...
Wenn es mit nem BIOS Update beheben lässt - gut.
Ein Sicherheits-Feature wie ALSR abzuschalten halte ich für keine Lösung.
 
Hab dennoch gestern meinen neuen 1800x verbaut. Wann die B2's reell bei uns Konsumenten aufschlagen, steht derzeit in den Sternen und anfangs dürfte der Versuch, ein solches Exemplar zu ergattern, wohl eher einem Roulette-Spiel gleichen. DIe Geduld habe ich nicht.
 
Verwundert mich jetzt nicht das es ggf. ein neues Stepping gibt. Immerhin hat der Epyc / Ripper einige Funktionen die der Ryzen nicht hat.
Wenn dabei ein Paar errata gefixt werden, bissel mehr Takt, bei weniger Hunger rauskommt, wäre das doch schön.
Was dann natürlich für manche Kunden doof wird, wenn einer B1 und der andere B2 hat, kommen bestimmt längst Vergessen Forum Threads ala

"Ripper Rücksendung wegen Stepping?" "oder Tausche B1 gegen B2 Stepping" ;D

mfg
 
Rückgabe hatte ich mir auch kurzzeitig überlegt, nachdem ich von der Meldung überrascht wurde, bis Freitag hätte ich ja noch Zeit dafür. Aber ich bleib jetzt bei meinem B1, denke eh, daß die Auswirkungen bzgl. Performance bei Ryzen nicht spürbar sein werden. Was Ram angeht, rechne ich fest mit baldigen DDR4 4000 Support in der Praxis (für B1) für Module von G.Skill, entsprechend deren Aussage steht das quasi vor der Tür zumindest für die Top Boards von Gigabyte und Asus:

http://www.tomshardware.de/g.skill-ddr4-rekord-ryzen-x299,news-258112.html

"Die G.Skill-Entwickler arbeiten gleichermaßen daran höhere Speichergeschwindigkeiten bei Ryzen-Prozessoren zu realisieren. Auch wenn der Speichertakt hier noch weit hinter dem zurückbleibt, was im Zusammenhang mit Intel-Prozessoren geboten wird: Immerhin erreicht der Hersteller auf zwei Mainboards, die von Gigabyte und Asus stammen, einen Speichertakt von 3600 MHz, außerdem versicherte G.Skill, dass auch DDR4-4000 in greifbarer Nähe ist, wenngleich eine Umsetzung zur Messe - auch mit dem letzten AGESA-Update von AMD - nicht mehr möglich war."

Was dann noch an Bugs bleibt, verursacht bei mir zumindest keine schlaflosen Nächte ;-)
 
Zuletzt bearbeitet:
Ich hoffe ja auch, dass der Grund für die Probleme mit gcc gefunden und behoben wird.
Der Thread im AMD Forum zeigt aber, dass es nicht nur ein Troll ist, der irgendwas behauptet...
Wenn es mit nem BIOS Update beheben lässt - gut.
Ein Sicherheits-Feature wie ALSR abzuschalten halte ich für keine Lösung.
Hallo mibo,
ich gehe mal davon aus, es gibt fähige Leute da drausen die wissen was "debuggen" bedeutet! 8)

ALSR ist an sich eine feine Sache, aber hat auch Schatten Seiten, habe dazu eine interessanten "Beitrag" gefunden: https://forums.grsecurity.net/viewtopic.php?f=7&t=3367&sid=80ef962357a996facbbc75f6133c92ea
All of it utterly useless as every one of these files is publicly available to anyone, including the attacker. And so the false security spreads.

---

IOMMU: https://de.wikipedia.org/wiki/IOMMU
Die IOMMU ermöglicht folgende Funktionen bei DMA:
Effektivere Nutzung von 32-Bit-Geräten in 64-Bit-Umgebungen, insbesondere Zugriff auf Speicherbereiche oberhalb von 4 GiB.
Zugriffsschutz beim Zugriff von Anwendungen auf bestimmte Geräte
Zugriffsschutz beim Zugriff von virtuellen Maschinen auf bestimmte Geräte
 
IOMMU ist ein Must-Have-Feature für Virtualisierung. Für Ottonormalanwender ggf. nicht, aber ich fand es schon bei AM3+ sehr gut von Asus, das die das IOMMU-Feature im BIOS unterstützt haben (Asrock bspw. nicht).

Denn nur mit IOMMU kann man physikalische Hardware des Hosts-Systems (PCI/PCIe) in die VM durchreichen. Sonst geht das nur mit USB-Zeugs. Damit habe ich schon einige unpatchbare Windows-Altsysteme (die auf PCI-Karten angewiesen waren) mitsamt ihren Karten auf einen Linux-Host und dort in eine KVM "verschieben" können. Dann noch das virtuelle Netz unter Linux gefirewalled und man schläft besser :).
 
Zurück
Oben Unten