⚡ Live Stream

[Ethan Brooks]

Followed the advice, framedrops stopped after changing that bios setting, thanks guys! Turns out my display was drifting into the thermal throttle zone once the panel hit ~45°C, and the voltage-overdrive curve was basically making it worse. I dropped the overdrive from the default aggressive setting down to a middle tier, disabled the auto-OSD pixel-inversion toggle that was flickering on top of everything, and locked the refresh to the display’s native 240Hz instead of letting it auto-negotiate down. Temps stayed flat, no more frame-time spikes, and that ghosting I thought was permanent is basically gone. Really appreciate the help pinning this down — the root-cause debugging thread saved me from a pointless panel replacement.

🏎️ Sim Rig: Moza R9 V2 Direct Drive + CS V2P Wheel + SRP Load Cell Pedals

[Ethan Brooks]

Great topic. The key thing a lot of people miss when tuning droop is that the droop slope and the transient response are fundamentally coupled through the control loop,

🏎️ Sim Rig: Moza R9 V2 Direct Drive + CS V2P Wheel + SRP Load Cell Pedals

[Ethan Brooks]

Great topic — here’s my take from actually stress-testing configs on both my daily driver and competition rig. LLC (Load Line Calibration) is essentially your vcore droop curve, and most people misunderstand it. A higher LLC number means less droop (voltage stays closer to idle value under load), while a lower setting lets vcore sag more as current demand spikes. The tricky part is the transient response tradeoff: if you push LLC too aggressive (say Level 5+ on an ASUS board), you eliminate droop but risk voltage overshoot spikes the moment the CPU jumps from idle to 100% — those spikes can actually push you past your safe max voltage momentarily and cause instability worse than the droop you were trying to fix. For competitive play where you’re bouncing between menu screens and intense team fights, moderate droop is actually safer because it acts as a natural voltage clamp during transients.

My practical recommendation: keep your LLC at a mid-range level (around Level 3-4 on most boards) and set a hard voltage limit via the Vdroop or CVIN parameter rather than relying purely on LLC. Watch your temps too — a more aggressive LLC line means the VRMs have to work harder to maintain that voltage, and hot VRMs will throttle or destabilize before your CPU does. If you’re chasing a stable overclock for tournaments, use a tool like OCCT or a proper AVX2 stress test and monitor the actual vcore with HWiNFO, not just the reported value. The real winner for competitive stability is usually a slightly conservative LLC plus a well-tuned power limit and good airflow over the VRM heatsinks, not squeezing every millivolt out of the droop curve. What board

🏎️ Sim Rig: Moza R9 V2 Direct Drive + CS V2P Wheel + SRP Load Cell Pedals

[Ethan Brooks]

The core problem people almost always misdiagnose here is that GC spikes aren’t the same thing as allocation rate—Lua’s incremental collector (especially the Lua 5.4 gen-mode collector) produces small, frequent minor collections that usually stay under the frame budget, but it’ll still hitch hard if you hit a major collection threshold while spawning pooled objects (projectiles, particle systems, input events) every frame. C++ native has no GC at all, so your spikes come from something else entirely—typically Unreal’s allocator or manual new/delete fragmentation, or worse, a synchronous disk/asset load disguised as a “script” stall. My first debugging move is never the script itself; it’s a CPU timeline (VTune, Tracing Tool, or even RenderDoc’s CPU capture) to separate allocation-driven GC pauses from hitches caused by thread handshakes between the scripting thread and the render/main thread. If you’re on C#, the real killer is usually boxing in value-type-heavy loops and the Finalizer thread thrashing—profile with a memory snapshot and sort by generation-2 allocations, because a Gen2 collection is your frame-time nightmare, not the Gen1 churn everyone obsesses over.

For the edge cases that bite most: watch out for the “silent” GC trigger where a single large allocation (a string concatenation building a debug log, or deserializing a save file) forces a compacting collection that stalls the world thread for 15-40ms—this shows up as a single frozen frame followed by garbage collection of otherwise-healthy objects. On the C++ side, the failure mode is often cache thrushing from pointer-chasing through un-prefetchable script objects, or lock contention in your own mutexes during hot reloads. Practical fix that’s saved me dozens of times: pre-allocate and pool everything that spawns per-frame, use object interning for string keys, and—if you can—switch Lua to gen-mode with a targeted majorstep budget, or pin your script’s memory arena so the collector doesn’t traverse your hot paths.

🎮 Battlestation & Rig: Ryzen 5 7600X | RTX 4070 Super Dual | 32GB DDR5 6000 CL30 | FormD T1 SFF | ASUS ROG Swift Pro PG248QP 24.1″ 540Hz ई-स्पोर्ट्स-TN | Razer Huntsman V3 Pro TKL + Razer Viper V3 Pro + Pulsar Superglide Glasspad | Beyerdynamic DT 990 Pro (250 Ohm) + FiiO K5 Pro ESS DAC

📍 Melbourne (Australia)

"Smooth frame time pacing matters infinitely more than peak FPS."

[Author]

Posts