AMD Zen - 14nm, 8 Kerne, 95W TDP & DDR4?

[Mente]

Hi,

also übertackten ist so ne Sache, hab bisl rumgespielt derzeit hab ich meinen 1800x grade auf 4g mit 1,375Volt aber die temps kommen schon langsam in intel nähe bei simcraft tests
hab jetzt um 72grad mit dem DH15. aber ihr solltet euch zeit nehmen ist zum teil schon etwas buggy noch.
ich hab jete das "automatische über Takten" angetestet und den tpu1 porfil mal angetestet jetzt hab ich das plötzliche ausgehen nicht mehr´(aber Achtung der versucht bis ihr abbrecht bzw win abstürzt kranke Spannungen ich hab bei 1,5volt abgebrochen

 

[Complicated]

https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/

Dieser Link zu dem Beitrag von The Stilt ist ein absolutes muss wenn man OC betreiben will mit Ryzen. Besonders die einzustellenden Spannungen sind hier nicht so einfach, da eben falsche Werte angezeigt werden. Es gibt einen Offset den man unbedingt beachten sollte.

Understanding the voltages specified for the standard PStates can be confusing as well. That's because in the normal operating mode (i.e. "non-OC") the SMU controls the voltages automatically through the voltage controllers.

For example, the P0 PState might specify 1.37500V voltage, while the actual effective voltage during the residency in this state is 1.26250V or slightly higher. This is not a glitch, but the normal operation of the CPU. Basically, the voltage specified in the MSR is just the upper limit and the SMU will automatically add a dynamic negative offset to this value, reducing the actual effective voltage. The amount of the negative offset varies depending on load and the temperature. For the tested sample the offsets were -120mV & -144mV for the two highest base PStates (3.6 & 3.2GHz).

When the "OC Mode" is activated the SMU will disable the voltage controllers, which among other things disables the automatic voltage offsets. This can create an illusion that the power consumption is heavily increasing due to the use of "OC Mode". While technically it is accurate, it is more of a consequence than the actual reason. A vast majority of the increased power consumption comes from the now disabled automatic negative voltage offsets, which causes the actual CPU voltage to increase anything between 50 and 150mV. Because of this behavior, it is advised that the user doesn't increase the CPU voltage right away (when overclocking), but only upon actual demand (as usual).

Auch die Ausführungen zu den internen Spannungsregulatoren (dLDO) sind sehr interessant:

Despite the presence of the dLDOs, the consumers can ignore them completely. This is because in the consumer parts most of the dLDOs (all except some of the minor domains) are permanently placed in a by-pass mode. This means that actual regulators are disabled and all of the voltage regulation takes place on the motherboard, just like on the previous generation CPUs and APUs.

Sehr zu beachten der Teil wo die einzelnen Takte und Spannungen für die Cores ins Spiel kommen:

While each of the cores and their full speed L1 & L2 caches can be clocked independently, the shared L3 cache frequency is linked to the currently highest clocked core speed within the CCX at all times. Because of that there will be frequency difference dependent delta between the requested and the actual frequency, if all of the cores within the CCX don't have a common frequency.

Und weiter:

In cases where the cores within a CCX a clocked differently, calculating the effective multiplier is somewhat more complex. If all of the different PStates have the same CPUDFSId value, the effective multiplier can be calculated with following formula: Target core CPUFID / (1 + ((highest core CPUFID - target core CPUFID) / highest core CPUFID)). For example, if the highest core multiplier is 36.0x (CPUFID = 144 & CPUDFSId = 1) and the target multiplier for other cores is 32.0x (CPUFID = 128 & CPUDFSId = 1): 128 / (1 + ((144 - 128 )/ 144)) = 115.2 (28.8x). Further rules and limitations may apply, depending on the used CPUDFSId values and the actual frequency.

Also in diesem Beispiel wurde der am höchsten getaktete Kern mit 36x Multi eingestellt und die anderen mit 32x. Daraus resultiert für die niedriger getakteten Kerne lediglich ein effektiver Multi von 28,8x
Siehe:

The effective CPU multiplier consists of two components: CPUFID and CPUDFSId. The CPUFID is an integer value ranging from 16 to 255. The CPUDFSId is a floating-point value between 1 and 6. Due to the natural divider of 8 for the CPUDFSId, its adjustment step is always 0.125 (1/8 ). The effective multiplier is produced with following formula: ((CPUFID / (CPUDFSId / 8 )/ 4).

Es wäre grandios wenn sich einer der hiesigen Autoren dies für eine deutsche Übersetzung vornehmen würde Und sicherlich eine Referenz für die ganze deutschsprachige Ryzen OC-Community.

Edit: es wäre hilfreich wenn der Smiley 8) ein anderes Kürzel bekommen würde als "8 )"

 

[FredD]

@koschi

Danke schonmal für die Einschätzung. Das mit dem Aufpreis betrifft ja nicht nur den höher möglichen Takt, sondern auch die niedrigeren Temperaturen bei gleichem Takt aber eben niedrigerer Spannung.

Auf welchem Board betreibst du den R7 1700?

EDIT:
Interessanter als alle Kerne zu übertakten fände ich die Möglichkeit, den Boost zu erhöhen. Sagen wir auf 4,2 GHz statt 3,7 beim R7 1700.

 

[koschi]

ASUS PRIME X370-PRO mit neuestem BIOS

An die minimale vcore für 3.8GHz werde ich mich langsam heran tasten, aber sicher demnächst mal ein Update geben. Da bin ich mal gespannt inwieweit sich das von den schnelleren CPUs unterscheidet.
Singe Core Boost ist mir als BOINC Jünger relativ egal, ich brauche Performance auf allen Kernen.

 

[p4z1f1st]

Für die Übersichtlichkeit und die Zukunft: OC-Thread für Ryzen / Summit Ridge

 

[cyrusNGC_224]

1. Unter Linux schien der Takt auf 3GHz festgenagelt, auch mit performance governor änderte sich da (auslesbar) nichts. Kein Precision Boost, kein XFR. Zu Windows kann ich nichts sagen.

Naja, das war bisher oft so. Z.B. der Takt unter /proc/cpuinfo gibt dann nur den Standardtakt für die höchsten P-State an, egal wie hoch übertaktet wurde. Es bräuchte einfach Werkzeuge, die die korrekten Daten in Echtzeit aus den CPU-Registern holen.

Es wäre grandios wenn sich einer der hiesigen Autoren dies für eine deutsche Übersetzung vornehmen würde Und sicherlich eine Referenz für die ganze deutschsprachige Ryzen OC-Community.

Unbedingt!

EDIT:
Interessanter als alle Kerne zu übertakten fände ich die Möglichkeit, den Boost zu erhöhen. Sagen wir auf 4,2 GHz statt 3,7 beim R7 1700.

Bei den K10 war das möglich.

 

[koschi]

Bei dem i7 ging das auch problemlos über "cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq", jeweils der aktuelle Takt eines jeden Kernes wurde gezeigt. Mit Boost dann je nach Last schwankend, in Echtzeit. Der R7 zeigt da ohne Übertaktung und auch mit ondemand governor keinerlei Regung gezeigt. Meinem Verständnis nach schaltet sich die ganze Boost und XFR Geschichte dann mit manueller Übertaktung aber eh ab, von daher erstmal egal...

 

[MacroWelle]

Weiß eigentlich jemand, ob Ryzen auch ähnlich wie Skylake Haswell zusätzliche Anforderungen an Netzteile für Sleep-States hat?

 

[emulbetsup]

Du meinst den Haswell, oder?

 

[Yoshi 2k3]

War das dieses ErP-Gedöns? Das sollte AMD auch unterstützen. Hab im BIOS des PRIME X370-PRO zumindest eine Option, mit der ich das an/ausschalten kann.

 

[DonL_]

@ yoshi 2k3

Kannst du mal deine Eindrücke zum PRIME X370-PRO schreiben.
Läuft alles stabil?
Welchen Ram hast du und wie kannst du ihn takten?

etc. etc.

 

[Onkel_Dithmeyer]

Aber die Effizienz ist sehr gut, am Besten im Bereich um 30Watt und bis 65Watt noch gut.
Ware schön, wenn manche Mainboadrhersteller die cTDP-Funktion freischalten würden im BIOS.

Auf meine Nachfrage bezüglich cTDP bekam ich nur die Antwort, dass dies nicht Teil der Ryzen-Prozessoren sei. Wenn MB-Hersteller das also implementieren, dann auf eigene Faust.

--- Update ---

https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/

Ich frag mich wie der Autor Ryzen so weit runtertakten konnte. Bei mir geht nicht weniger als 3000 MHz

--- Update ---

Ich habe eben fix getestet, mein 1700er startet bei 4GHz & 1,375v bis zum Desktop, legt sich mit Handbrake aber umgehend auf die Bretter. Mehr Saft wollte ich ihm nicht geben (Blindflug dank Linux).
3.9GHz mit 1.35v das gleiche Problem, 1,375v hätte ich mal noch testen können, aber vergessen, hole ich bei Bedarf nach.
3.8GHz mit 1.3v lief heute tagsüber stabil (Lüfter wechselt ständig die Geschwindigkeit)
3.8GHz mit 1.275v teste ich gerade, Handbrake (H.264 encode) lief einmal durch, mal schauen was BOINC und Prime davon halten

Wenn das läuft, geht es jeden Tag ein wenig niedriger. Mit 26% OC kann ich gut leben.

Ein Auszug aus dem Review-Guide von AMD:

As a general guideline: a CPU voltage of 1.35V is acceptable for driving everyday overclocks of the AMD Ryzen processor. Core voltages up to 1.45V are also sustainable, but our models suggest that processor longevity may be affected. Regardless of your voltage, make sure you’re using capable cooling to keep temperatures as low as possible.
While there are never guarantees with overclocking, the majority of users should find that an 8C16T AMD Ryzen™ processor will achieve 4.2 GHz @ 1.45V of CPU voltage. Advanced and accomplished overclockers trying to push record frequencies may find more headroom by disabling cores and disabling SMT on motherboards that offer the option in the BIOS.

Zu Deutsch: 1,35 V kann man bedenkenlos 24/7 fahren. 1,45 V gehen zwar auch, können aber zu einem früheren Ableben führen. Die Meißten Ryzen solten 4,2 GHz bei 1,45 V erreichen, garantiert wird aber natürlich nichts.

Bei meinen ersten Tests konnte ich durch deaktivieren von SMT keine geringeren Spannungen ansetzen.

 

[Mente]

Hi braucht noch jemand ein Asus Prime X370-Pro?

 

[cyrusNGC_224]

Wenn ich mir die Kurven und Werte so anschaue, ZEN muss ja im Mobilumfeld richtig punkten.

 

[Complicated]

Und vor allem auch im Serverumfeld, wenn man bedenkt, dass das die onChip dLDOs bei den Desktop-Modellen kaum genutzt werden. Das verbessert noch das Powergating für feinere Granularität. Hier sollten auch mobile Konfigurationen noch sehr sparsam werden können.

 

[p4z1f1st]

Kann mir mal einer diese "Performance-Scaling" Diagramme erläutern?... ich muss gestehen, dass ich da nicht ganz verstehe, was die Aussage zum "Sweet-Spot" der CPU ist

 

[BoMbY]

Ich frag mich wie der Autor Ryzen so weit runtertakten konnte. Bei mir geht nicht weniger als 3000 MHz

Im Crosshair-BIOS (5704 und 5803) gibt es noch einige sehr tiefgehende Einstellungen, unter anderem kann man manuell die P-States übersteuern, da sollten auch deutlich niedrigere Werte möglich sein. Ich würde es ja versuchen, aber ich muss erstmal ein RMA starten.

 

[Onkel_Dithmeyer]

Beim Gigabyte/Aourus werden Werte unter 3,7 GHz aus dem BIOS gar nicht übernommen... Ich warte auf ein Update

 

[BoMbY]

[falscher thread, sorry]

 

[Yoshi 2k3]

@ yoshi 2k3
Kannst du mal deine Eindrücke zum PRIME X370-PRO schreiben.

Klar, gerne doch. Ausgeliefert wurde das Board mit BIOS 0502, also fast aktuell. Inzwischen hab ich 0504 geflasht. Stabilitätsprobleme konnte ich bisher keine feststellen. Ich habe jetzt nicht 12h am Stück gebencht, aber AIDA64 Memory Bench, Cinebench, Luxmark, CPU-Z, CompuBench CL laufen @Stock alle wunderbar ohne besondere Vorkommnisse. Beim RAM setze ich aktuell auf Crucial Ballistix Elite 2x 8GB 2666 MHz BLE2C8G4D26AFEA. Die laufen momentan nur mit 2400 MHz. Setze ich die Timings per Hand und den Takt auf 2666 MHz startet das Board nicht mehr. Piept dann eine ganze Weile und stellt nach 3 fehlgeschlagenen Versuchen selbstständig wieder auf 2400 MHz zurück. Was das angeht also alles recht "gutmütig". Da ich am Takt aktuell also nicht viel machen kann, was Asus ja auch selbst bestätigt, dass daran gearbeitet wird, muss ich mit den Timings spielen. Und das klappt meiner Meinung nach erstaunlich gut. Standard bei 2666 MHz wären 16-17-17-36, ich schaffe bei 2400 MHz 13-13-13-32 mit den normalen 1,20 V.

Laut ASUS soll man 2 Module ja in die A2/B2 Slots stecken, das muss ich noch umswitchen. Vielleicht geht dann noch was. Die QVL ist aber sehr aufschlussreich und ich denke bei zukünftigen BIOS-Updates wird sich am Speicher noch etwas verbessern.

AMDs Ryzen Master Tool erlaubt ja die Anhebung des RAM-Takts aus Windows heraus. Das muss ich auch noch testen. Und Crucial bietet ja meines Wissens nach auch noch ein Tool an, was das können soll. Muss ich mich auch noch schlau machen...

Das BIOS/UEFI ist übersichtlich, gefällt mir besser als bei meiner vorherigen MSI-Platine. So Wahnsinnig viele Einstellungsmöglichkeiten hat man noch nicht, aber eigentlich ist alles wirklich wichtige bereits an Bord. Spannungen kann man sehr fein einstellen, absolut und auch mit Offsets, bei den RAM-Settings ist noch Luft nach oben, das ist bisher recht spartanisch. Die Lüftersteuerung der einzelnen Anschlüsse ist wirklich intelligent aufbereitet, da kann man sich richtig austoben und hat mehr als zwei Hände voll an Settings pro Anschluss zur Verfügung.

Kommen wir zu den "Problemen" oder Unzulänglichkeiten. Dual-Boot Windows/Linux war der größte Krampf überhaupt. Das hatte ich bei meinem vorherigen Intel-System so nicht. Und zwar hat das Windows 10 Setup den Bootsektor NIE auf die Festplatte geschrieben, die zur Installation ausgewählt war, sondern immer auf die ESP-Partition der Linux-Installation. Das kann nur ein Bug sein. Ende vom Lied war, dass ich alle Platten bis auf die Windows-SSD abgestöpselt, Windows 10 installiert und dann alle anderen wieder angestöpselt habe. Dann hatten ich die Kosntellation so, wie ich wollte. Windows-Bootloader auf der Windows-SSD, Linux-Bootloader auf der Linux-SSD, passt. Solche Klimmzüge musste ich vorher (auch auf UEFI-Systemen) noch nie machen.

Kleiner Schönheitsfehler: selbst wenn der Rechner heruntergefahren ist, ist dieses komische Asus Aura LED Gedöns aktiv, obwohl im BIOS ausgeschaltet. Habe mir die zugehörige Windows-Software noch nicht angesehen, aber das sollte so nicht sein. Scheint also ein Bug zu sein und wird sicher noch behoben.

Ärgerlich ist insgesamt eben, dass schneller RAM aktuell nichts bringt, weil man den Takt nie erreicht. Aber das betrifft ja alle Hersteller und das ist meiner Meinung nach auch die größte Baustelle, an der gearbeitet werden muss.

Reicht dir das erstmal an Input? Wenn noch speziellere Fragen auftauchen, nur zu, gehe gern darauf ein.

 

[koschi]

Kann ich so unterschreiben. Meinem RAM geht es ähnlich, allerdings geht der von 3000(2933)MHz auf 2666MHz.
Auch ich habe die Speichermodule in A1/B1 gesteckt, das war mir im Handbuch so recht nicht ersichtlich. Werde ich bei Gelegenheit mal auf A2/B2 umstecken...

 

[eratte]

1700x und Crosshair 6 bestellt, mal sehen ob sie wirklich lieferbar sind. Wird ich in ca 3 Tagen zeigen. Handbuch per PDF ist ja auch verfügbar aknn ich das schon mal studieren.

 

[David64]

Kommen wir zu den "Problemen" oder Unzulänglichkeiten. Dual-Boot Windows/Linux war der größte Krampf überhaupt. Das hatte ich bei meinem vorherigen Intel-System so nicht. Und zwar hat das Windows 10 Setup den Bootsektor NIE auf die Festplatte geschrieben, die zur Installation ausgewählt war, sondern immer auf die ESP-Partition der Linux-Installation. Das kann nur ein Bug sein. Ende vom Lied war, dass ich alle Platten bis auf die Windows-SSD abgestöpselt, Windows 10 installiert und dann alle anderen wieder angestöpselt habe. Dann hatten ich die Kosntellation so, wie ich wollte. Windows-Bootloader auf der Windows-SSD, Linux-Bootloader auf der Linux-SSD, passt. Solche Klimmzüge musste ich vorher (auch auf UEFI-Systemen) noch nie machen.

Kenn ich von ASUS und W10 nicht anders. Mein FM2+ Board macht das auch, wobei das FM2+ UEFI sehr stiefmütterlich behandelt wird, im Gegensatz zu den Intel Boards. Beim Asrock hat das problemlos funktioniert - ich bin mir allerdings nich sicher, ob das nicht doch an Windows 10 liegt und die Art und Weise, wie UEFI dort behandelt wird.

 

[DonL_]

@ Yoshi 2k3

Vielen vielen Dank für die Informationen, da ich mit dem Mainboard liebäugele, wenn Ryzen 1600X kommt, ist das sehr hilfreich.

 

[hoschi_tux]

@David64

Kenne ich auch nicht anders. Windows (mind. seit 7) versucht immer auf die erste Platte im System zu schreiben (unabhängig von UEFI). Wenn das nun die Linux Platte ist, da man Win vielleicht nur als Backup nutzt, wird da dennoch einfach drüber gebügelt mit dem Ergebnis, dass man Linux nicht mehr booten kann.