[Work-Log] Aufrüsten auf einen 5800X3D! Was ist an Leistung möglich!

@BreadPit Bei mir ist SOC_SET die vsoc Einstellung im BIOS.
 
BreadPit schrieb:
Nein, SOC_TELEM ist die manuelle Override Einstellung im BIOS. SOC_SET ist was die CPU / AGESA "tun wollen würde", aber nicht kann wegen dem Override ;)
Kann ich hier so nicht bestätigen. BIOS 1006mV, SOC_SET 988mV, SOC_TELEM 994mV
 
@BreadPit das mit der Vsoc lass ich mal bleiben. VSOC_SET ist bei mir die Bioseinstellung VSoc_Tel ist das was er anfordert, denke ich. Was meinst du mit manuelle Override?
Hast du schon mit der neuesten Corecycler Version getestet? Mit dem neuen Config Parameter verteilt er die Last nun zwischen den logischen und virtuellen Core. Mit der alten Version war die Last immer auf den logischen und virtuellen Core. Kannst im Taskmanager nachprüfen. So kommt man wahrscheinlich wieder auf andere CO Werte.

# General settings
[General]
stressTestProgram = YCRUNCHER
runtimePerCore = 256s
# runtimePerCore = 30s --> HNT only Quick Check Cycles
# runtimePerCore = 256s --> N64, HNT, VST, C17 Final Check overnight
delayBetweenCores = 5
# delayBetweenCores = 15 is dfault, 5 simply accelerates the test
# disableCpuUtilizationCheck = 0
# disableCpuUtilizationCheck = 0 is default; 1=enabled does not allow error detection in Y-Cruncher . Y-Cruncher gives no feedback except for its Terminal-Ouptut. It has no log file, and does not allow access the terminal ouput. The only possibility for error detection is thru CPU utilization check calculation.
restartTestProgramForEachCore = 0
# restartTestProgramForEachCore = 0 is default, and leaves the Y-Cruncher window open so you can scroll thru to check for errors; 1=enabled leads to not seeing errors in the Y-Cruncher test window as it restarts with each core
coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7
# coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7
skipCoreOnError = 1
numberOfThreads = 1
# Use only one thread for load generation, but assign the affinity to both virtual (logical) cores
# This way the Windows Scheduler should bounce the load back and forth between the two virtual cores
# This may lead to additional stress situation otherwise not possible
# This setting has no effect if Hyperthreading / SMT is disabled or if numberOfThreads = 2
# Default: 0
assignBothVirtualCoresForSingleThread = 1

# y-Cruncher specific settings
[yCruncher]
mode = 19-ZN2 ~ Kagari
tests = N64, HNT, VST, C17
# tests = HNT --> HNT only Quick Check Cycles
# tests = N64, HNT, VST, C17 --> Final Check overnight
# tests = BKT, BBP, SFT, FFT, N32, N64, HNT, VST, C17 --> all tests
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: 4BitDitherBayer und Fas7play
https://www.3dmark.com/3dm/94187609?

So, erstmal alle andere in die Schranken gewiesen...:D
(und trotzdem noch teilweise im CPU Limit....)
1684058647494.png
 
In der Kombi, 4090 und 3D (mit minimalisten bclk von 100.250)

TS Extreme wird dann auch ohne CPU Limit sein, bei mir meine ich... ;)

https://www.3dmark.com/3dm/94204702?

Reicht nicht für P1 aber egal, hauptsache es läuft :freaky:
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Erpel, Fas7play, Creekground und 2 andere
Gratulation zu Rank#1 4090+x3D, spitze wie du dich da reinhängst.
 
Zuletzt bearbeitet:
TBH eigentlich war es nur ein Benchmark nach Umbau der GPU auf Wasser, da mein Block endlich kam, bzw lieferbar war.

Zwar nicht 100% den bekommen den ich wollte (Full Acetal) aber passt auch so.
Rechner ist nun wieder zu und die temps werden auf der CPU nun höher ausfallen, da der Loop so ausgerichtet ist, das erst die GPU und dann die CPU gekühlt wird.
 
verstehe, bin auf angaben dazu gespannt.
kriegst du legit noch was rausgedrückt an GPU score?

hab auch D5 -> GPU -> CPU -> RAD..
hab am samstag ein gigabyte B550 verbaut... der moment wo man seine hardtubes hasst. :king:
letzte (glaub ich mir ja selber nicht g) adaption ist irgendwann mal der MoRa.. :)

PS: 96W nach CBR23 und punkte da wo sie sein sollen
 
Ob ich aus der GPU noch was rausholen kann weiß ich noch nicht, 3120 sind aber schon recht ok, VRAM ist leider ein Krüppel.

Mir ging es aber tatsächlich erstmal um die Temps der CPU, weil ja nun die 500w Abwärme direkt drauf knallen, aber scheint keinen großen Unterschied in der Leistung zu machen, obgleich die Temps nun 5 - 10°C (je nach Dauer der GPU Last) höher sind auf der CPU.

Beim zocken kommt eh ein FPS Cap rein und dann geht das klar.

Ich lasse nur gerne alles auf Anschlag laufen, wenn ich den Loop "neu" verschlauche. ;)

Kurz:
CO ist auch mit höheren Temperaturen noch stabil und gedrosselt wird auch nichts.
 
  • Gefällt mir
Reaktionen: Fas7play
von wo kommt das her? (CO = 0!)

1684095812351.png



:EDIT: wird ausgelöst durch:
numberOfThreads = 2
hab nun umgestellt auf = 1
was aber SMT aus wäre... hm !?!?!
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Creekground
Was würde bei ein 5800x3d mehr bringen? Beziehungsweise mit welchen der 2 möglichkeiten würdet ihr euren 5800x3d betreiben?

3200 MHz cl16 oder 3600 MHz cl18 ?
 
Creekground schrieb:
@BreadPit das mit der Vsoc lass ich mal bleiben. VSOC_SET ist bei mir die Bioseinstellung VSoc_Tel ist das was er anfordert, denke ich. Was meinst du mit manuelle Override?
Bei mir heisst die manuelle vSOC Einstellung "Override" im MSI BIOS. Dort stelle ich zB 1,1625V ein, und das Setting wird mir immer zuverlässig in PBO2tuner Monitor als SOC_TELEM angezeigt. Während bei zu viel BCLK OC die SOC_SET von ebenfalls 1,1625 auf 1,2000 springt. SOC_SET ist auch der einzige Wert, der 1,2 anzeigt - alle Sensoren liefern brav die eingestellte vSOC.
Creekground schrieb:
Hast du schon mit der neuesten Corecycler Version getestet? Mit dem neuen Config Parameter verteilt er die Last nun zwischen den logischen und virtuellen Core. Mit der alten Version war die Last immer auf den logischen und virtuellen Core. Kannst im Taskmanager nachprüfen. So kommt man wahrscheinlich wieder auf andere CO Werte.
Nein, welche Version ist das? Fahre noch 0.9.3.0 . Hast Du schon Erfahrungen mit der neuen?
MehlstaubtheCat schrieb:
Welchen Ram hast du denn? Sicher das der "nur" 3600 mit CL18 macht?
Es wäre sehr ungewöhnlich, egal mit welchen Chips da verbaut sind!
@MehlstaubtheCat ich weiss ich wiederhole mich mit dem Punkt ;) : @Experte18 mit 64GB kann das schon sein, dass man zumindest nur mit viel Mühe auf 3600C16 kommt. In meinem Fall nur mit 1,46V (statt 1,25 CL 18...) und wichtig: tRCDRD 21 min, eher 22!

Wenn Du <=32GB hast wäre es wirklich selten.
Ergänzung ()

fas7play schrieb:
von wo kommt das her? (CO = 0!)
Anhang anzeigen 1357427
:EDIT: wird ausgelöst durch:
numberOfThreads = 2
hab nun umgestellt auf = 1
was aber SMT aus wäre... hm !?!?!

Beschreibung aus der config.default.ini:

Code:
# The number of threads to use for testing
# You can only choose between 1 and 2
# If Hyperthreading / SMT is disabled, this will automatically be set to 1
# Currently there's no automatic way to determine which core has thrown an error
# Setting this to 1 causes higher boost clock speed (due to less heat)
# Default: 1
# Maximum: 2

Ich fürchte es ist einfach ned 100% stabil bei voller SMT-Auslastung eines Kerns.
 
Zuletzt bearbeitet:
BreadPit schrieb:
Bei mir heisst die manuelle vSOC Einstellung "Override" im MSI BIOS
OK. Diese Bios Einstellung habe ich nicht. Mit dem 5800X war damals noch ein Vsoc offset möglich. Gibt es aber nicht mehr. Das was ich als Vsoc einstelle wird in der SOC_SET angezeigt. SOC_TEL kommt dann vom Board.
BreadPit schrieb:
Fahre noch 0.9.3.0
Die neueste ist die V0.9.4.2. Hier der changelog:
Added a new assignBothVirtualCoresForSingleThread setting that allows you assign both virtual (logical) cores to a single stress thread.
This way the Windows Scheduler should bounce back and forth the load between the both virtual cores, which may open a new possibility to test for load change instabilities.

Kannst du mit dem Task Manager nachprüfen. Gestern konnte ich damit meine CO Werte wieder anpassen und habe damit die Vcore senken können. Den schlechtesten Kern konnte ich von -4 auf -14 zurückstellen. Fehlt nur noch ein Langzeittest.
 
@Creekground heißt das nicht einfach, dass die neue Version nicht mehr so stressig ist für die Cores - weil sie nicht mehr so hoch takten durch Nutzung beider Log. Cores für 1 Thread?
Ergänzung ()

Ergänze: ein Stresstest, der in einer alten Version Fehler liefert, und in einer neuen nicht mehr, ist wohl einfach weniger stressig in der neuen Version / mit neuen Parametern? :)
 
Zuletzt bearbeitet:
Moinsen zusammen.

Gehöre seit Samstagmittag nun auch dem X3D-Club an. 😈

Ich möchte mich bei @MehlstaubtheCat für diesen erstklassigen Thread und die gesammelten Informationen bedanken. Hast ein paar Bier gut bei mir. :schluck:

Derzeit läuft noch alles auf Stock, aber die Unterschiede zum R5 3600 sind bereits mehr als deutlich, wobei mir eher "gewaltig bis brutal" auf der Zunge liegt ...

Mein 5800X3D Sample erreicht "nur" 4.450 MHz ... SKANDAL !!111einself ^^

1684145310846.png
 
  • Gefällt mir
Reaktionen: MehlstaubtheCat, Creekground und BreadPit
1684146745499.png


@fas7play oder passt doch alles? Hatte das hier grad bei meinem Testlauf.

restartTestProgramForEachCore = 0 / Y-Cruncher Fenster kein Fehler / CoreCycler auf Basis der Load Fehler entdeckt.

Meiner Meinung nach bedeutet das, das Näherungsverfahren des CoreCycler, mit dem er die Y-Cruncher Load ermittelt (0% Load = Idle wegen Fehler), liefert hier einfach kein akkurated Ergebnis und glaubt nur, dass ein Fehler war. Sonst wäre ja auch im Y-Cruncher Fenster ein Fehler. @sp00n.82 siehst Du das auch so?
 
BreadPit schrieb:
Ich fürchte es ist einfach ned 100% stabil bei voller SMT-Auslastung eines Kerns.
Bedeutet meine CPU ist RMA? Da dies bereits STOCK also RAM und CO auf Werkseinstellungen aufkommt. 😭
Fehler bei N64.

HNT, C17 rennt auch mit -30 durch. N64 zerlegt die Kiste... Wie sind diese Tests aufgebaut. Was hat Einfluss auf SMT?

Schön langsam ist mir das eh egal.. am WE hatte ich Diablo 4 gespielt ohne Probleme. Nur bis dato zu wenig Zeit um SOTTR... was immer ein Blackscrenn Generator für mich war... zu testen.
Nur das SMT Thema... N64 error bei Co 0 irritiert mich nun sehr.

oder braucht Gigabyte irgend ein Bios Setting? SMT ist Auto, disabled natürlich nicht. Kann ich kaum glauben.
Ergänzung ()

Update: auf deinen neuen Post gehe ich nach Arbeitsende ein. Danke für deine Zeit!
 
  • Gefällt mir
Reaktionen: BreadPit
@fas7play kannst Du ja testen mit CO +10 versuchsweise. Wenns dann geht, ists wohl RMA...

Ich bin übrigens einen Schritt weiter. Wie es aussieht check ich das CoreCycler Verhalten noch immer nicht ganz, weil bei Undervolting mit vCore Offset eh keine N64 / VST / C17 Errors kommen, nur HNT. Das wiederum endet in einem Reboot, Fehler gibt es daher nie, das Y-Cruncher Fenster läuft ewig wie ne 1.

Aber ohne vCore Offset gibts sehr wohl Errors, offenbar bei N64 oder C17. Und bei einem Error startet CoreCycler offenbar den Y-Cruncher neu! Auch wenn ich stopOnError = 0 gesetzt habe, im Y-Cruncher Fenster ist "Stop on Error = Enabled" immer gesetzt, und dementsprechend wird es wieder zu gemacht.

Unten immer noch derselbe CoreCycler Test, aber offensichtlich mit einem neu gestarteten Y-Cruncher Fenster.
@sp00n.82 gibts ne Möglichkeit das Y-Cruncher Fenster eben nicht neu zu starten bei Error, sodass man sieht bei welchem Test der Fehler kam? stopOnError = 0 wird ignoriert, im Y-C Fenster sieht man immer noch "Stop on Error = Enabled".

1684149463332.png
 
Zuletzt bearbeitet:
Zurück
Oben