Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Soweit ich mich erinnere, läuft der RAM synchron mit dem CPU. Es gibt/gab eben keinen 2.667er RAM, daher RAM mit etwas höherer Taktung, welcher eben mit 2.667 läuft.
So, nochmal zurück zum CPU. Eben, ich wollte den eigentlich nicht upgraden, weil der Leistungssprung minimal ist. Bei dem GPU bin ich von 1660 Super auf 5060 Ti. Von 6 GB VRAM auf 16 GB VRAM.
Rohleistung +139% lt. UserBenchmark: https://gpu.userbenchmark.com/Compare/Nvidia-RTX-5060-Ti-vs-Nvidia-GTX-1660S-Super/4183vs4056
Dazu ca. 3x Frames durch MFG 4x (außer für die Tests hier, hatte ich MFG immer aktiviert). Dazu +50% Frames durch DLSS Quality vs. nativ.
2,39 x 3 x 1,5 = 10,8-fache Frames (bzw. eben höhere Grafikdetails).
(Meine alte 1660 Super in nativ ohne FrameGen vs 5060 Ti mit DLSS 4 Q und MFG 4x)
An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.
Bei Cyberpunk fällt der 7500F auch mal auf 21FPS als 0,1% Low. Vielleicht bin ich auch insgesamt zu kritisch?
Auch bei Witcher sind gerade am Anfang beim 7500F einige harte Frame Drops (0,1% bei 26; beim 10400F bei 90-93 in der gleichen Szene).
Auf jeden Fall keine 10x-Upgrade (bei der 5060 Ti zum großen Teil durch "Fake Frames" und "Fake Auflösung", völlig klar) und auch nicht frei von Frame Drops.
Daher ja, der Plan war eigentlich nicht, den CPU zu upgraden und ein 7500F wäre ein viel zu geringes Upgrade. Und ein 9800X3D oder was auch immer ein ziemlicher Overkill für eine 5060Ti.
Jetzt noch zu den PCIe Lanes, das wäre ja evtl. der zweite Grund für ein Upgrade. Die 5060 Ti läuft auf x8, mein Motherboard auf PCIe 3.0. Hier wurde eine 4090 auf 2.0 x16 gesetzt (Sollte 3.0 x8 entsprechen) oder gar auf 1.1 x16 (sollte nur die Hälfte von 3.0 x8 sein):
Es werden nur FPS veröffentlicht, keine Min-FPS oder Min-Frametimes, aber ich vermute doch, dass die Tester im Text darauf hingewiesen hätten, wenn nicht allgemein die FPS ein paar Prozent leiden, sondern die weniger FPS durch einige, wenige Micro-Ruckler verursacht worden wären.
Die Webseite User Benchmark kannst du in die Tonne kloppen. Die schaust du dir am besten gar nicht an. Schau dir lieber Tests hier bei CB, techpowerup oder Gamersnexus (einige nur bei YouTube, nicht alles als Text) an.
Bitte bitte nutze niemals Userbenchmark. Das sind absurde Intel-Fanboys, die alles dafür tun, dass Intel besser als AMD dasteht und immer wieder völlig weltfremd an ihrem Benchmark rumschraubenl, um das sicherzustellen.
Wie groß der Sprung ist, kommt aber auch darauf an, auf welche neue CPU du wechselst. Aber das hängt wiederum mit den Kosten zusammen
Ergänzung ()
Fryous schrieb:
Dazu ca. 3x Frames durch MFG 4x (außer für die Tests hier, hatte ich MFG immer aktiviert). Dazu +50% Frames durch DLSS Quality vs. nativ.
2,39 x 3 x 1,5 = 10,8-fache Frames (bzw. eben höhere Grafikdetails).
(Meine alte 1660 Super in nativ ohne FrameGen vs 5060 Ti mit DLSS 4 Q und MFG 4x)
Milchmädchenrechnung. Die 5060ti ist oft gar nicht stark genug damit du in eine FPS Bereich kommst, bei dem sich FG bzw MFG wirklich lohnen würde. Du brauchst von Anfang an mindestens 60 FPS, besser 80-100 FPS. Begründet sich durch die erhöhte Latenz
An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.
Auch mit 2.0 und selbst mit 1.1 gibt es keine extremen Unterschiede, vor allem unten bei UWQHD/4k - vor allem verschieben sich beide Graphen. Also ein beschränkter PCIe-Bus würde nicht zu einzelnen Frame-Drops führen, sondern das Gesamtgefüge (Average FPS und 1% in gleichen Maße) verschieben.
Fazit, oder eben auch nicht: Ich denke auch nicht, dass es am CPU liegt. Oder am PCIe Bus. Aber woran es liegt, weiß ich eben nicht. Ich habe jetzt ALLE Autostart-Programme deaktiviert, also selbst das Microsoft Antivirus Icon usw...
Ergänzung ()
stefan92x schrieb:
Bitte bitte nutze niemals Userbenchmark. Das sind absurde Intel-Fanboys, die alles dafür tun, dass Intel besser als AMD dasteht und immer wieder völlig weltfremd an ihrem Benchmark rumschraubenl, um das sicherzustellen.
Vllt hast du das schon irgendwo erwähnt. Hast du auch Windows nochmal komplett frisch installiert? Wäre eine Maßnahme, auch wenn man das natürlich gerne vermeiden möchte. Aber scheinbar hast du schon viel getestet.
Milchmädchenrechnung. Die 5060ti ist oft gar nicht stark genug damit du in eine FPS Bereich kommst, bei dem sich FG bzw MFG wirklich lohnen würde. Du brauchst von Anfang an mindestens 60 FPS, besser 80-100 FPS. Begründet sich durch die erhöhte Latenz
Das ist eine interessante akademische Diskussion für kompetitive e-Sports-Valorant-Spieler & Co. - für mich komplett irrelevant. Der Input Lag selbst bei 20-30 fps auf 80-120 fps hochskaliert ist mit MFG 4x und Nvidia Reflex geringer als nativ ohne Nvidia Reflex und geringer als bei aktuellen Konsolen (PS5, PS5 Pro).
Bei Sportarten wie Sprint, Schwimmen oder Formel 1 gibt es sog. Mindestreaktionszeiten - die liegt je nach Sportart bei 100 bis 200 ms. Weil schneller kann selbst der genetisch bevorzugteste und am besten trainierteste Mensch der Welt nicht reagieren, d.h. eine Reaktionszeit unter 200 ms ist bspw. in der Formel 1 ein Frühstart. Auch Verstappen braucht über 200 ms. Normale Menschen, die das nicht beruflich machen und trainieren, sind natürlich noch wesentlich schlechter.
Beispiel Video von Digital Foundry (God of War), da hat die PS5 112 ms Latenz, ein normaler PC 124 ms und Nvidia Reflex 47 ms. Bei 60 fps habe ich Frametimes von 17 ms, bei 30 fps habe ich 33 ms und bei 25 fps habe ich 40 ms. Da werden also 16 bis 23 ms Latenz durch geringer Wiederholrate hinzugefügt, was gerade einen Bruchteil vom Unterschied von PS5 zu Nvidia Reflex ausmacht. Und 16 bis 23 ms sind nur Bruchteil der menschlich bestmöglichen Reaktionszeit.
Am Ende kommt es auch bisschen auf die Optimierung des Spiels an, siehe Computerbase Test. Bei Outlaws lt. Computerbase-Test ist komplett ohne MFG die PC Latenz bei 46 ms und mit MFG 4x bei 55 ms. Also gerade mal 9 ms mehr, wobei nativ 105 ms statt 46/55 ms wären und bei der PS5 sind es wahrscheinlich auch deutlich über 100 ms (analog dem God of War Test von Digital Foundry).
TL;DR: Der Input-Lag ist für mich irrelevant als Singleplayer-Casual-Gamer der zu 95% mit dem Gamepad spielt und nur mal Cyberpunk ausnahmsweise mit Maus/Tastatur weil Ego-Perspektive. Ich schaue, dass ich 100 - 165 fps habe unter Nutzung von MFG 4x und für nicht-kompetitive Spiele ist das super und vom Input-Lag immer noch Welten besser als PS5/PS5 Pro oder PC nativ.
Ergänzung ()
So, Shadow of the Tomb Raider habe ich noch hier, da gibt es auch einen Benchmark.
UWQHD, DLSS Q, Ultra + RT Ultra:
Rechts ist ja so ein Frametime-Graph, da sieht man sowohl CPU als auch GPU. Der Graph geht von 0 bis 20 ms und ist eigentlich nie schlechter als 10 ms.
Aber auch dort gibt es im Benchmark diese typischen Aussetzer oder ist das einfach normal!?
Ergänzung ()
Btw: GPU bei 100% - also keine CPU-Limitierung!?
Und der RAM ist mit 9 von 16 GB ja auch nicht voll!?
Ob vielleicht RTSS selbst das Problem ist? Da müsste ich jetzt mal gedanklich rekonstruieren, hatte ich RTSS zuerst oder sind mir zuerst diese Micro-Ruckler aufgefallen... oder mal ein anderes Tool suchen...
Ich rekonstruiere das ganze nochmal. Mein Monitor (DW3423DWF) unterstützt VRR. Also man kann über die Nvidia Systemsteuerung G-Sync Kompatibilität anschalten. Der G-Sync Indikator wird angezeigt, funktioniert also. Gerade in Cyberpunk ist mir aber Ingame (besonders wenn man geduckt ist, merkt man es ja sehr gut) sehr extremes VRR Flickeringaufgefallen. Für die ganzen Tests oben war G-Sync auch wieder aus, aber das spielt keine Rolle.
Habe jetzt nochmal G-Sync wieder aktiviert und RTSS und MSI Afterburner ausgeschaltet und wirklich 0 (!) Hintergrundprogramme laufen und dann nochmal den Tomb Raider Benchmark gestartet. Dort dann nur mittlere Details und ohne Ray Tracing und auch da habe ich das VRR Flickerung sehr deutlich bemerkt. Etwas öfters als einmal pro Sekunde blitzt es hell auf, dann wieder normal. Also es liegt nicht an RTSS, es liegt nicht am GPU und kann eigentlich auch nicht am CPU liegen (Shadow of the Tomb Raider auf mittleren Details aus dem Jahr 2018 - da sollte ein 10400 als Budget-Gaming-CPU aus dem Jahr 2020 keine Probleme haben - besonders nicht solche extremen Frame Drops).
Also, zuerst kam das VRR OLED Flickering, dann kam RTSS und auch bei 2018er Spielen mit mittleren Details kann die Kombination 10400F + 5060 Ti keine konstante Bildrate halten. Der RAM ist nicht voll. BIOS Update auch gestern gemacht. Average FPS sehr toll, aber etwa 1x pro Sekunde oder evtl. bisschen öfters ein einziges Frame, was massiv abfällt und damit VRR OLED Flickering verursacht (falls G-Sync aktiv). Oder sich eben in RTSS massiv bemerkbar macht oder einen einzigen Micro-Ruckler pro Sekunde verursacht.
So, ich habe jetzt meinen Monitor auf HDR mit Modus "DisplayHDR True Black" umgestellt. In Windows HDR aktiviert. G-Sync ist aktiviert und rechts oben wird G-Sync angezeigt, d.h. es funktioniert auch. MSI Afterburner und RTSS gelöscht. Nvidia FrameView installiert (siehe auch hier: https://nvidia.custhelp.com/app/ans...r-may-be-observed-when-using-diagnostic-tools )
In Cyberpunk Hoch eingestellt, DLSS Quality, UWQHD, MFG x3, RT aus, Max FPS in Cyberpunk auf 162 eingestellt.
In FrameView sind die FPS 160-175 (die 162 max werden also nicht immer gehalten, aber so ungefähr). Die 1% Lows schwanken zwischen 80 und 130/140, meistens so 100-120.
VRR Flickering ist weg, Micro-Stuttering ist weg. Das ist wirklich der wichtige Unterschied, ich hatte auch vorher schon mal MSI/RTSS gelöscht bzw. noch gar nicht installiert, und trotzdem hatte ich VRR Flickering und das Micro Stuttering ca. 1x pro Sekunde. Beim VRR Flicker hat man 1x pro Sekunde, besonders in Cyberpunk geduckt (da ist es extra dunkel) diesen Lichtblitz hell gesehen - der ist jetzt komplett weg. Auch das Micro Stuttering, das war bspw. extrem (!) auffällig wenn man in Cyberpunk Auto gefahren ist, ist komplett weg (flüssig wie ein Rennspiel).
Also keine Ahnung woran es jetzt liegt und das werde ich morgen wahrscheinlich weiter ausprobieren, damit ich hoffentlich das Setting finde, was VRR Flickering und Micro Stuttering verursacht hat, aber jetzt zumindest mit diesen Settings ist es komplett weg und extrem flüssig: Cyberpunk Hoch, DLSS Quality, UWQHD, MFG x3, RT aus, Max FPS in Cyberpunk auf 162.
Die PC Latency gibt FrameView mit 43-48 ms an (meistens 43-45 ms). Das ist m.E. ein sehr guter Wert wenn die PS5 oder ein nativer PC normalerweise über 100 ms liegen. Ich kann natürlich nicht sagen, wie genau Nvidia FrameView das überhaupt berechnet, ist aber für mein Casual-Gamer empfinden (der früher mal CS 1.6 gezockt hat, viele, viele Jahre ist es her) kein merkliches Input Lag und ich kann jedenfalls im Single-Player sehr einfach auf Headshots-only gehen (wie damals mit der Scout in CS). Für kompetitives eSports ist MFG natürlich kein Thema, aber ich habe meine 165 fps im Average und kann mit der Maus auch im Kampf im Singleplayer locker auf Headshots zielen ohne merkliches Input Lag. Und für die 95% anderen Titel, die ich mit Gamepad spiele, noch weniger ein Thema.
Edit: Mein Reasoning für MFG x3: Bei 165 Hz was der Monitor schafft bin ich bei 55 fps x 3 und 55 fps ist nun wirklich keine FPS-Rate, welche rucklig oder lagig wäre. Bis vor 2 Wochen hatte ich einen 60 Hz Monitor. Seit 20 Jahren zocke ich 60 Hz oder schlechter (viele Jahre auch Counter-Strike 1.6) und die meisten Konsolen machen, gerade im Single-Player, 30 fps. Filme sind 24/25 fps.
Probiere das mal testweise. Deaktiviere im MSI Afterburner die Leistungsüberwachung.
Im Video hat er sein Problem mit den 1% Lows gelöst.
YouTube
An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.
Einige Hintergrundprozesse oder Treiber (z. B. Audio-Treiber, Netzwerktreiber, RGB-Software) können sogenannte Deferred Procedure Calls (DPCs) verursachen – kurze, aber spürbare Interruptions, die exakt dieses Verhalten erzeugen: normale FPS, aber katastrophale 1% und 0.1% Lows.
Starte es, lass es im Hintergrund laufen, während du ein Spiel spielst. Danach checkst du den Reiter “Drivers” – sieh nach, ob z. B. nvlddmkm.sys, dxgkrnl.sys, ndis.sys oder Audio-Treiber sehr hohe Zeiten haben.
Was spricht gegen die CPU in deinem Fall?
Ständige Frametimespitzen bei allen Spielen, selbst bei niedriger GPU-Auslastung → das deutet auf Scheduling-/CPU-Limitierungen hin
In Spielen mit hohem Draw Call Load (z. B. Assassin’s Creed, Cyberpunk 2077, Star Wars Outlaws) ist die CPU oft hart an der Grenze
Keine Unterstützung für neue Windows 11 Zeitgeber-Features (z. B. Game Mode optimiert für E/P-Kerne)
DLSS Frame Generation benötigt zusätzliche CPU-Kapazität, da ein extra Frame erzeugt und der Frame-Puffer koordiniert werden muss → kann bei älterer CPU zu Mikro-Rucklern führen
Kein Support für Resizable BAR vor BIOS-Update → dies kann auf eine ältere Plattform mit limitiertem Durchsatz hinweisen.
Fazit zur CPU-Leistung:
Für durchschnittliche FPS okay, aber:
Für flüssige Frame-Zeit (1% Lows / 0,1% Lows) in modernen Engines oft nicht mehr ausreichend.
Dein Problem ist nicht die Leistung in FPS, sondern die Stabilität der Frametimes – da zählt jede millisekundengenaue Aufgabe, die die CPU übernehmen muss.
Ergänzung ()
Ah – UWQHD (3440×1440) @ 165 Hz auf einem Dell Alienware DW3423DWF (QD-OLED) – sehr gut, damit kommen wir einer möglichen Ursache tatsächlich näher. Dieses Display kann bei falscher Konfiguration oder Kombination mit G-SYNC/VRR zu exakt den Symptomen führen, die du beschreibst: Mikroruckler, Frame-Timing-Spikes, VRR-Flickering.
Mögliche Probleme durch dein Display / Auflösung / VRR:
1. G-SYNC Kompatibilität / VRR-Flickering
Der DW3423DWF ist kein echtes G-SYNC-Modul, sondern „G-SYNC Compatible“ über Adaptive Sync (DP 1.4).
Dell/Alienware hat Firmware-Probleme und VRR-Flickering bei niedrigen FPS oder Frame Time Spikes → besonders sichtbar bei 40–80 FPS
Mikroruckler entstehen durch fehlerhaftes Pacing im VRR-Modus oder wenn FPS dauerhaft außerhalb der stabilen Range schwanken (z. B. 120–165 vs. 40–80)
2. 165 Hz → Belastung & Instabilität
Höhere Refresh Rates wie 165 Hz verschärfen Frame-Pacing-Probleme – wenn dein System nicht konstant >120 FPS liefert, kommt es zu Pacing-Inkonsistenzen
Besonders kritisch bei aktiviertem G-SYNC + V-SYNC (egal ob im NVCP oder im Spiel)
3. HDR + Windows + VRR → Chaos
Wenn HDR in Windows + VRR + G-SYNC gleichzeitig aktiv ist, produzieren viele Monitore wie der DW3423DWF Stottern / Lags
Der Dell hat aggressives ABL (Automatic Brightness Limiting) → starke Helligkeitsschwankungen = Input-Stutter möglich
Konkrete Tipps für dein Setup:
Monitor & NVIDIA Systemsteuerung
Setze die Bildwiederholrate testweise auf 120 Hz
Weniger Schwankungen = gleichmäßigeres Pacing
Deaktiviere G-SYNC komplett im NVIDIA Control Panel
→ Auch im Monitor-Menü Adaptive Sync aus
Setze V-SYNC auf „Aus“
Sowohl im Spiel als auch im NVCP
Deaktiviere HDR in Windows & Spiel
Optional: NVIDIA Reflex + Frame Cap
Stelle z. B. RivaTuner FPS-Limit auf 116 (bei 120 Hz) oder 158 (bei 165 Hz)
Reflex kann helfen, sollte aber ohne G-SYNC verwendet werden
Teste auf anderem Monitor (Full HD/60 Hz)
Nur um auszuschließen, dass es am Panel/VRR liegt – wenn es da komplett stabil läuft, ist dein Dell-Monitor sehr wahrscheinlich ein Mitverursacher
Fazit:
Ja, dein Monitor (Dell DW3423DWF) kann die Mikroruckler massiv verstärken oder sogar verursachen, vor allem in Verbindung mit VRR, G-SYNC Compatible und hoher Auflösung/Hz-Zahl. Gerade bei Frametimes im Bereich von 7–12 ms (siehe Screenshots) können falsche VRR-Einstellungen und instabiles Pacing zu massiven Problemen.
Ergänzung ()
Einstellung
Wert
Kommentar
Bildwiederholfrequenz bevorzugt
120 Hz (manuell einstellen!)
Weniger Schwankung, stabileres Pacing
Maximale Bildfrequenz (FPS-Limit)
Optional: 120 (NVCP) oder 116 (RTSS)
Für Frame-Pacing – RivaTuner funktioniert am präzisesten
Die scheinbare Taktung der frame time Einbrüche spricht dafür, dass irgendeine Software in regelmäßigen, definierten Abständen irgendwas macht, dass dann zum Problem führt.
Zum Test könntest du in Afterburner einstellen, im welchen Takt die Monitoring Infos abgerufen werden sollen. Teste mal 0,5s, 1s, 2.
Wenn die Frametime Einbrüche sich an den Takt anpassen, hast du eine Antwort.
Ja, im MSI Afterburner beim Logging alle haken raus die nicht gebraucht werden.
Im CPU Limit bist du immer dann, wenn die GPU Auslastung unter 99% ist und kein FPS Limit erreicht wurde.
Die CPU Auslastung im Taskmanager kann hier durchaus eine geringe CPU last anzeigen, selbt wenn ein Thread nur zu 50% oder weniger ausgelastet ist, kann ein Thread ein CPU Limit verursachen, weil die Threads teilweise extrem schnell von Kern zu Kern geschoben werden und Windows nur die durchschnittliche Auslastung innerhalb einer Sekunde zeigt. Kurz gesagt: Die Anzeige zur CPU last in Windows ist völlig unbrauchbar um zu sagen, ob man im CPU Limit ist. Die GPU Auslastung ist verlässlich.
ABER, auch im CPU limit hast du niemals so regelmäßige ausreißer. CPU Limit oder nicht ist also für dieses Problem hier völlig irrelevant. Den Punkt kann man abhaken.
Fryous schrieb:
Mal sind die Micro-Ruckler da, mal sind sie weg. Ich sehe kein Muster. Hier mal ein paar Daten von CapFrameX, evtl. kann jemand draus etwas lesen?
Wenn ich mich recht erinnere gabs doch kürzlich Auslesefehler diesbezüglich. Die wurden aber mittlerweile mit dem aktuellen Treiber behoben.
Daher mal ganz blöd gefragt: Hast du den aktuellsten Treiber vom 30. April drauf? Gerade da es aktuell unzählige Probleme mit den RTX50 Karten gibt sollte man hier immer sofort updaten. https://www.nvidia.com/de-de/geforce/drivers/results/245382/
Da es zuletzt auch Probleme mit dem Windows Stand-By gab (der in form des Hybriden Stand By auch dann aktiv ist, wenn man auf "Herunterfahren" klickt), würde ich dir empfehlen, nach dem Treiberupdate den PC auch mal via "Neu Starten" Button im Startmenü neuzustarten. Das macht zumindest wenn man den Hybriden Stand By in Windows nicht manuell deaktiviert hat, definitiv einen Unterschied verglichen zum Herunterfahren und den PC anschließend starten.
Wenn das deaktiviert ist, verhalten sich Neustart und Herunterfahren identisch und der PC wird nach dem Herunterfahren und Starten auch tatsächlich komplett neu gebootet.
Ist der Schnellstart aktiv wird nach dem Herunterfahren und Starten nur ein RAM Abbild von der SSD geladen. Windows startet dann zwar minimal schneller, effektiv wird Windows so aber nie vollständig rebootet, was hin und wieder für Probleme sorgt.
Schnellstart deaktiviert.
Nochmal mit DDU im abgesicherten Modus Treiber deinstalliert und wieder installiert (ganz aktuelle, nur Treiber sonst nichts).
MSI Afterburner und RTSS habe ich auch schon längst gelöscht und jetzt CapFrameX.
Auch dort das Logging aller Sensor-Daten deaktiviert.
G-Sync an/aus, V-Sync an/aus, kein Sync - alles durchprobiert.
DLSS an/aus; FG an/aus alles durchprobiert.
Es bessert sich nichts.
So wie anbei sieht es aus, die Ausschläge sind extrem regelmäßig. Aber die Micro-Ruckler sind eben auch spürbar, wenn alle Capture-Programme gelöscht sind.
Ergänzung ()
Ich habe mal Cyberpunk auf 1024x768 gstellt, alles auf LOW, DLSS Ultra-Performance und MFG 4x, auch da sind die Micro-Ruckler spürbar trotz 400-500 fps im Schnitt. Anbei noch der Screenshot vom LatencyMon, was sagt mir das?
Ergänzung ()
_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One or more DPC routines that belong to a driver running in your system appear to be executing for too long. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
LatencyMon has been analyzing your system for 0:01:03 (h:mm:ss) on all processors.
_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: DESKTOP-2020
OS version: Windows 11, 10.0, version 2009, build: 26100 (x64)
Hardware: MS-7C88, Micro-Star International Co., Ltd.
BIOS: 1.A0
CPU: GenuineIntel Intel(R) Core(TM) i5-10400 CPU @ 2.90GHz
Logical processors: 12
Processor groups: 1
Processor group size: 12
RAM: 32706 MB total
_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed (WMI): 2904 MHz
Reported CPU speed (registry): 2904 MHz
Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.
_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.
Highest measured interrupt to process latency (µs): 3316,80
Average measured interrupt to process latency (µs): 21,987037
Highest measured interrupt to DPC latency (µs): 3307,40
Average measured interrupt to DPC latency (µs): 15,438144
_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.
Highest ISR routine execution time (µs): 4,860537
Driver with highest ISR routine execution time: Wdf01000.sys - Kernelmodustreiber-Frameworklaufzeit, Microsoft Corporation
Highest reported total ISR routine time (%): 0,000029
Driver with highest ISR total time: Wdf01000.sys - Kernelmodustreiber-Frameworklaufzeit, Microsoft Corporation
Total time spent in ISRs (%) 0,000029
ISR count (execution time <250 µs): 81
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-1000 µs): 0
ISR count (execution time 1000-2000 µs): 0
ISR count (execution time 2000-4000 µs): 0
ISR count (execution time >=4000 µs): 0
_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.
Highest DPC routine execution time (µs): 3337,064394
Driver with highest DPC routine execution time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation
Highest reported total DPC routine time (%): 0,615281
Driver with highest DPC total execution time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation
Total time spent in DPCs (%) 0,950932
DPC count (execution time <250 µs): 325105
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 2207
DPC count (execution time 1000-2000 µs): 0
DPC count (execution time 2000-4000 µs): 30
DPC count (execution time >=4000 µs): 0
_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.
NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.
Process with highest pagefault count: msmpeng.exe
Total number of hard pagefaults 187
Hard pagefault count of hardest hit process: 164
Number of processes hit: 3
_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 13,259423
CPU 0 ISR highest execution time (µs): 4,860537
CPU 0 ISR total execution time (s): 0,000219
CPU 0 ISR count: 81
CPU 0 DPC highest execution time (µs): 3337,064394
CPU 0 DPC total execution time (s): 7,195130
CPU 0 DPC count: 311322
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 1,111194
CPU 1 ISR highest execution time (µs): 0,0
CPU 1 ISR total execution time (s): 0,0
CPU 1 ISR count: 0
CPU 1 DPC highest execution time (µs): 49,182163
CPU 1 DPC total execution time (s): 0,004238
CPU 1 DPC count: 1473
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 1,902344
CPU 2 ISR highest execution time (µs): 0,0
CPU 2 ISR total execution time (s): 0,0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 170,263774
CPU 2 DPC total execution time (s): 0,019096
CPU 2 DPC count: 2721
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 1,206927
CPU 3 ISR highest execution time (µs): 0,0
CPU 3 ISR total execution time (s): 0,0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 49,876377
CPU 3 DPC total execution time (s): 0,002504
CPU 3 DPC count: 656
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 1,203330
CPU 4 ISR highest execution time (µs): 0,0
CPU 4 ISR total execution time (s): 0,0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 277,250
CPU 4 DPC total execution time (s): 0,003961
CPU 4 DPC count: 1198
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 1,127157
CPU 5 ISR highest execution time (µs): 0,0
CPU 5 ISR total execution time (s): 0,0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 40,905647
CPU 5 DPC total execution time (s): 0,002731
CPU 5 DPC count: 802
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 1,174659
CPU 6 ISR highest execution time (µs): 0,0
CPU 6 ISR total execution time (s): 0,0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 157,202135
CPU 6 DPC total execution time (s): 0,00560
CPU 6 DPC count: 1634
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 1,086023
CPU 7 ISR highest execution time (µs): 0,0
CPU 7 ISR total execution time (s): 0,0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 59,292355
CPU 7 DPC total execution time (s): 0,004117
CPU 7 DPC count: 1346
_________________________________________________________________________________________________________
CPU 8 Interrupt cycle time (s): 1,184750
CPU 8 ISR highest execution time (µs): 0,0
CPU 8 ISR total execution time (s): 0,0
CPU 8 ISR count: 0
CPU 8 DPC highest execution time (µs): 35,013085
CPU 8 DPC total execution time (s): 0,004410
CPU 8 DPC count: 1586
_________________________________________________________________________________________________________
CPU 9 Interrupt cycle time (s): 1,093156
CPU 9 ISR highest execution time (µs): 0,0
CPU 9 ISR total execution time (s): 0,0
CPU 9 ISR count: 0
CPU 9 DPC highest execution time (µs): 25,481405
CPU 9 DPC total execution time (s): 0,00240
CPU 9 DPC count: 962
_________________________________________________________________________________________________________
CPU 10 Interrupt cycle time (s): 1,167328
CPU 10 ISR highest execution time (µs): 0,0
CPU 10 ISR total execution time (s): 0,0
CPU 10 ISR count: 0
CPU 10 DPC highest execution time (µs): 26,988981
CPU 10 DPC total execution time (s): 0,008096
CPU 10 DPC count: 2361
_________________________________________________________________________________________________________
CPU 11 Interrupt cycle time (s): 1,151754
CPU 11 ISR highest execution time (µs): 0,0
CPU 11 ISR total execution time (s): 0,0
CPU 11 ISR count: 0
CPU 11 DPC highest execution time (µs): 45,539601
CPU 11 DPC total execution time (s): 0,006256
CPU 11 DPC count: 1281
Ergänzung ()
Hier nochmal bei 1024x768, DLSS Ultra, MFG 4x usw... 477,9 fps im Average und die 1% LOWs bei 68,4 fps.
(MSI Afterburner, RTSS gelöscht - in CapFrameX alle Sensor-Daten deaktiviert).
Abstand der Micro-Ruckler dürfte wohl relativ nah bei 500ms sein.
Vermutlich wird dir nichts über bleiben, als entweder deine Einstellungen und Wünsche zu reduzieren, oder aber an der Hardware etwas zu verändern.
Dein Mainboard bietet PCI-e 3.0 x16 für die Grafikkarte an. Die Karte hat PCI-e 5.0 x8. Heißt bei dir im Endeffekt daß du die Geschwindigkeit von PCI-e 2.0 x16 hast.
Und wenn man PCIe 4.0x16 als Standart ansehen möchte und sich daran orientiert, dann hast du mit PCIe 3.0x8 (soweit ich weiß) 25% der maximalen Bandbreite vom PCIe 4.0.
Hälfte durch 3.0 statt 4.0. Und davon nochmal die Hälfte durch x8 statt x16.
Trotzdem würde ich stark annehmen, dass es in diesem Fall nicht an der GPU, sondern am RAM und/oder CPU liegt.
Die eindeutige Taktung auf 500ms spricht meine Meinung nach für Hintergrundprozesse, die in dem Takt etwas machen.
Weiter weiß ich leider auch nicht. Windows vllt komplett neu aufsetzen oder anderes MB, CPU und RAM kaufen.
Bei Cyberpunk fällt der 7500F auch mal auf 21FPS als 0,1% Low. Vielleicht bin ich auch insgesamt zu kritisch?
