Ja, weil der IMC tRFC2 und tRFCsb benutzt. Das hab ich hier glaub ich schon mal vor einer Weile geschrieben. Nichtmal Ryzen 9000 scheint tRFC2 und tRFCsb zu nutzen, was Schade ist. tRFCsb sollten mit deinen A-Die sogar knapp unter 100ns gehen.
Ah, die Info hatte ich wohl überlesen : )
Wird das ständige neuen Acc erstellen nicht langsam langweilig?
Zum Glück haben wir ja dich 🥲
Obs was bringt, keine Ahnung. Hab das mal auf Reddit aufgeschnappt.
zum Glück funktionert die IL hier im Luxx hervorragend
Vorteil ist, dass es im Falle einer RMA einfach wieder abgezogen werden kann.
Mach den Latency Test mal im Abgesicherten Modus von Windows, du hast sicher ganz viel Bloatware im Hintergrund laufen.
@Braegnok gerne duzen. Das war was wir rausfefunden hatten. Ich persönlich schaue nicht auf die peak Frequenz sondern auf die effektiv Frequenz. Schau mal in die readme von Ropbench da steht der Befehl. Diesen Befehl auf 10 sekunden dann noch setzen. Wenn sich durch co der effektive takt nicht ändert bist am Limit vom jeweiligen Kern. Aber auch im einzelchart gegen testen wenn die Kurve am Anfang mehrmals runter geht. Bedeutet das das der kern durch das co schwierigkeiten hat die frequenz zu halten. Wenn du über ropbench co einstellst kann es sein dass y cruncher und co natürlich nicht stable sind . Aber ich schau einfach im alltag ob mein game oder cinebench stable sind y cruncher ist halt etwas alltagsfremd@Wolf87
Makes sense if he tests L1D to L3 to Cache to L1D back
While i hoped for L1D or if bigger command ~ L2 to L2 betweeen cores.
// Where there are 1 op (zero delay) transfers and normal (long dly) transfers
L3 is shared, soo tracking is difficult
Most commands get broken down into chunks and allocated ~ without ever leaving cache
To my understanding
That should happen on all games, which is what can expose unstable CO or FCLK Package throttle
But i think if the understanding was to target mem oc effectiveness.
~ the cache to mem to cache approach is something that can visualize when MCLK pushing makes sense or not
Hmm difficult.
Optimally would be if both ways are testet and displayed as different visual examples, as this L$ - MEM - L$ , method already should be similar to Cache & RAM test.
Yet nothing of both should actively show FCLK Throttle ~ given that part is load balanced and may not be easily viewed as unstable (low load?)
EDIT:
If we do aim to show dynamic throttle into access time values
Internal testing should not leak to mem.
Above test is an alternate approach for very likely correct target, yet not what i was personally looing for as SiSandra replacement.
// And it will explain why values are different too. We look at two different questions.
google translate 😉
wen dem so wäre das du dich eingelesen hast, hättest du mindestens:
www.hardwareluxx.de
Ich vergleiche die Memory Werte, das die Cache Werte CPU abhängig sind, ist mir bewusst.[Sammelthread] - Ryzen DDR5 RAM OC Thread
Ich muss mich jetzt doch noch einmal melden: Und zwar geht es um den Benchmark Speedway von 3D Mark. Ram Auto / Default = Speedway läuft Ram auf EXPO I oder EXPO 2 = Speedway instant crash Ich hab auch schon jeweils nur 2x Kits verbaut, gleiches Problem. @Reous Hast du eine Idee? :-/ Danke...
Nur mal als Beispiel, ansonsten wurden dir doch schon einige Tipps gegeben?
Falls es die Read und Copy-Werte sind die dich irritieren, das ist normal für Ryzen mit nur einem CCD, nur Ryzen mit 2 CCDs haben da höhere Werte.
ja EXPO Voreinstellung ist halt nix - das (muss) nur überall laufen. Daher suboptimal eingestellt von den Herstellern
64ns sieht doch schon passend aus. Der Aida ist leider auch sehr abhängig von Hintergrund Prozessen.
UCLK = MCLK
Vergiss den Northbridge Takt, das ist AIDA Unfug. Wird fehlerhaft ausgelesen, Streich den wert einfach.
