Overview
The objective was straightforward: extract the maximum stable performance from every layer of a high-end AM5 platform built around the AMD Ryzen 9 9950X3D and the MSI RTX 5070 Gaming Trio OC, then validate the result through extended stress testing. A fresh Windows install provided the opportunity to do this from first principles rather than carry forward an accumulated set of ad hoc settings from a previous configuration.
Overclocking is usually treated as a single dial somewhere in a BIOS menu. This project treats it as a systems problem instead. CPU boost behaviour, memory architecture, GPU voltage and frequency curve, AIO cooling, OS-level thread scheduling, and peripheral configuration all interact, and tuning decisions on one layer were made with the others in mind throughout. The clearest example is the relationship between memory controller synchronisation and real-time audio processing; a setting most overclocking guides treat as a gaming-only concern turns out to matter just as much for ASIO buffer stability.
Memory & Fabric Synchronisation
The CPU and memory configuration was established at the BIOS level before any application-level tuning began, since every later layer depends on it. EXPO Profile 1 sets the G.Skill Trident Z5 Neo RGB to its rated 6000 MT/s. The setting that actually matters is UCLK = MCLK, forcing a 1:1 ratio between the memory clock and the unified memory controller clock. AMD defaults to a 1:2 ratio at higher memory frequencies to protect stability, which adds latency the platform does not need to pay if the rest of the configuration can sustain a tighter ratio.
Infinity Fabric frequency was manually set to 2000 MHz to complete a 1:1:1 synchronisation between MCLK (3000 MHz effective), UCLK (3000 MHz effective), and FCLK. This is the single most impactful memory tuning decision on AM5; it minimises inter-die communication latency across the 9950X3D's chiplet architecture, and the effect is not limited to gaming. Real-time audio processing is sensitive to memory controller latency consistency in the same way a render thread is, so the same setting that improves frame pacing also reduces the chance of an ASIO buffer underrun.
MCLK 3000 MHz : UCLK 3000 MHz : FCLK 2000 MHz, 1:1:1 ratio. Validated stable at 1996.4 MHz FCLK across a full overnight stress test with zero PMIC warnings.
PBO and the Curve Optimizer
The 9950X3D is an AMD 3D V-Cache processor, which changes the correct overclocking method rather than just the target numbers. AMD explicitly discourages voltage-based overclocking on X3D SKUs because of the risk of degrading the stacked V-Cache die, so Precision Boost Overdrive combined with the Curve Optimizer is the only tuning vector used here.
PBO was set to Advanced with an 80°C thermal limit at Level 3, acting specifically as a governor for the V-Cache die, which is more heat-sensitive than the base compute die. A -10 Curve Optimizer offset across all cores was the stable operating point found through testing; it lets the processor reach higher boost clocks at lower voltage by telling the boost algorithm this specific silicon can sustain performance at a reduced offset. The Max Boost Clock Override was deliberately left at +0 MHz. On X3D hardware a positive override can push the CPU to chase voltages it cannot sustain at idle power states, trading a small ceiling gain for instability at rest.
Memory sub-timings
| Timing | Value | Why |
|---|---|---|
| tCL | 30 | Primary latency |
| tRCDWR / tRCDRD | 38 / 38 | Write/read to CAS delay |
| tRP | 38 | Precharge time |
| tRAS | 30 | Row active time |
| tREFI | 32768 | Stable equilibrium between refresh latency and thermal desync |
| Gear Down Mode | Enabled | Required for stability at 6000 MT/s |
| PowerDown Mode | Disabled | Removes memory power-state sleep delays |
GPU Tuning — V/F Curve
The GPU side was tuned entirely with MSI Afterburner 4.6.7 Beta, chosen specifically because it is the first version with meaningful GDDR7 memory overclocking support for RTX 50-series cards, unlocking transfer rates up to 36 GT/s against NVIDIA's factory specification of 28 to 30 GT/s.
Initial tuning with a fixed core offset established +400 MHz as the practical ceiling. Independent review data for this specific card shows no measurable gain past +350 MHz, and +400 MHz is roughly where it becomes unstable without curve management. A fixed offset is a blunt instrument though, since the GPU tries to apply it across its entire boost range, including voltage states it cannot actually sustain at that frequency. The fix is a Voltage/Frequency curve rather than a flat number.
The default curve under the +400 offset ramped from roughly 700mV (~580 MHz) to a theoretical 1165mV (~3500 MHz) ceiling. That ceiling is not achievable under sustained load; real-world clocks under gaming load run 300 to 400 MHz below it once power and thermal limits engage, so locking to it would just mean constant downclocking and inconsistent frame pacing.
The actual strategy was a flat lock. Every point on the curve from approximately 1025mV to the right edge was manually dragged to 3200 MHz, creating a hard frequency ceiling above that voltage threshold rather than letting the GPU chase a peak it cannot hold. 3200 MHz was chosen because independent data for this card shows an average sustained overclock of roughly 3144 MHz under real gaming load; the flat lock removes the boost variance that causes micro-stutters and gives a stable target that can be stepped toward 3300 MHz once further validated.
Fan speed initially reported as a fixed 42% instead of responding to temperature. Cause: "Enable user defined software automatic fan control" in Settings > Fan was never switched on by default. A one-toggle fix once found, worth checking first on any fresh Afterburner install rather than assuming the curve editor alone controls fan behaviour.
Final GPU configuration
| Parameter | Final value | Note |
|---|---|---|
| Power Limit | 112% | Maximum allowable on this card |
| Core Voltage | +100% | Unlocks maximum manufacturer-approved headroom |
| Core Clock | V/F curve, flat lock 3200 MHz | Replaces the original fixed +400 MHz offset |
| Memory Clock | +1500 MHz (~15501 MHz) | GDDR7 headroom unlocked by 4.6.7 Beta |
Fan curve
Configured via Settings > Fan, with the update period reduced from the default 5000ms to 1000ms for faster thermal response, and a 2°C hysteresis to prevent rapid fan-speed hunting at threshold temperatures. Passive below 50°C, ramping in 5°C steps to 100% at 80°C and above.
AIO & Case Cooling
The Ryujin III's hardware presets (Silent, Standard, Turbo) were bypassed entirely in favour of custom Smart Mode curves hardcoded against CPU Tctl/Tdie as the tracking source. Presets respond to an averaged or delayed signal; tracking Tctl/Tdie directly means the pump reacts to Zen 5 thermal spikes as they happen rather than after they have already passed.
Pump and micro-fan profiles
| Node | CPU temp | Pump PWM | Micro-fan PWM |
|---|---|---|---|
| 1 | 20°C | 60% (~2460 RPM) | 20%, silent baseline |
| 2 | 55–65°C | 75–90% | 40%, low-noise ramp |
| 3 | 75°C+ | 100% (~3600 RPM) | 60–100%, active to emergency |
The embedded micro-fan cools the VRM phases and the Crucial T705 NVMe directly beneath the socket, and was deliberately speed-restricted; it sits close enough to a desk microphone that an unrestricted curve would raise the ambient noise floor during audio tracking sessions. A 12-second hysteresis window on both the pump and micro-fan prevents either from hunting in response to brief background thread activity.
Case fans
Seven Lian Li SL-Inf 120mm fans (three on the AIO radiator, three intake, one exhaust) run a shared five-point profile through L-Connect 3, the maximum number of points the software allows per custom curve. Temperature source is CPU, start/stop is disabled so fans never fully stop, and MB RPM Sync is enabled so the motherboard reports accurate fan telemetry rather than guessing from PWM duty cycle alone.
Stability Validation
All settings were validated through an extended overnight stress test monitored in HWiNFO64 v8.34. CCD1, the 3D V-Cache die, peaked at 77.5°C against the 80°C PBO thermal cap. Package power peaked at 166.7W against a 170W TDP, confirming the PBO limit is functioning as a real governor rather than a soft suggestion. FCLK held at a confirmed 1996.4 MHz throughout, validating the 1:1:1 synchronisation under sustained load rather than just at idle.
| Metric | Average | Peak |
|---|---|---|
| CCD1 Tdie (V-Cache) | 70.7°C | 77.5°C |
| CPU package power | 151.3W | 166.7W |
| Global frequency | 5281.1 MHz | 5520.0 MHz |
| FCLK | 1996.4 MHz | 1996.4 MHz |
| PPT limit usage | 75.3% | 82.9% |
DDR5 SPD temperatures peaked at 51.5°C against an 85°C+ rating, and no PMIC over-voltage, high-temperature, or under-voltage warnings were recorded across the full session. The system completed the test without a single crash, driver reset, memory error, or thermal event.
Afterburner 4.6.7 Beta's curve editor supports a Shift-drag multi-point selection intended to apply a value to several points at once. In practice it did not reliably apply to every selected point; some points moved, others silently stayed at their previous value with no error or warning shown.
Multi-point selection and batch frequency entry in the curve editor did not reliably apply to all selected points. Several points in the intended flat-lock region were left at stock values without any indication anything had failed.
The fix was the unglamorous one: abandon the batch tool and drag each point from 1025mV to the right edge of the curve individually to 3200 MHz, confirming each one visually before moving to the next. Slower, but deterministic; there is no ambiguity about whether a given point actually moved.
Manual point-by-point adjustment, each point verified individually. A known limitation of the current beta build; a production release should fix the batch path, but the manual method is the one to trust until it does.
After the Windows reinstall, Armory Crate did not detect the Ryujin III AIO at all; no pump, no embedded fan, nothing in the Fan Control dashboard.
A background hardware discovery service failure combined with a desynced SMBus state left over from the clean OS deployment. The AIO was physically fine; the software stack simply never established a session with it.
GIPService and RGBFusionService were restarted cleanly via Task Manager, followed by a firmware layer update through the Armory Crate Update Center to pull the G.Skill and ASUS hardware provider extensions. Both populated correctly afterward.
Pump block and embedded fan now detected and controllable. The broader pattern: a fresh OS install does not guarantee a fresh hardware-discovery state for everything attached to the board. Vendor services that handle SMBus communication can come up desynced and need an explicit restart, not just a reboot.
RGB Profile — Deep Space
A unified Deep Space purple theme was applied across every RGB-capable component, each through its own vendor tool since none of them share a control surface with Afterburner or with each other.
| Component | Software | Colour |
|---|---|---|
| GPU shroud | MSI Center | #6A0DAD |
| GPU logo | MSI Center | #30006E |
| GPU backplate | MSI Center | #9370DB |
| Case fans | L-Connect 3 | #6600CC |
| RAM | Gigabyte Control Center | #4B0082 |
| AIO pump head | Armory Crate | #6A0DAD |
The GPU uses a three-zone gradient: the shroud at a vivid royal purple, the logo at a deeper violet for contrast, and the backplate at a softer lavender, producing a dark-to-light gradient across the card's surface rather than one flat colour.
The Lian Li SL-Inf fans initially read as off-white rather than purple. The fans wash out colour at high brightness, and the active RGBW mode adds a white channel that dilutes saturation further. Fixed by dropping brightness to roughly 65% in L-Connect 3 and pushing saturation up (#6600CC), with lighting mode locked to Static.
OS-Level Thread Scheduling
The Windows 11 scheduler has no awareness of the 9950X3D's asymmetric dual-CCD layout, and left alone it migrates threads freely between the two dies. Every migration that crosses the Infinity Fabric to fetch data from a cache the thread does not currently reside on costs latency the rest of the tuning has been spent trying to remove.
Process Lasso enforces a permanent boundary instead. CCD 0 (cores 0–15) carries the 3D V-Cache and is reserved for anything latency-sensitive: game engines, FL Studio, REAPER, Focusrite Control 2, and the Unreal Editor, treated identically to a game engine so viewport behaviour and local audio testing mirror target deployment. CCD 1 (cores 16–31) takes everything else: launchers, communications, RGB and fan telemetry services, browsers, and security daemons, locked to Below Normal or Idle priority with Efficiency Mode enabled where supported.
Pinning the audio applications to CCD 0 specifically targets ASIO buffer stability; keeping the real-time audio pipeline resident on the V-Cache cores removes the chance of an underrun caused by a thread migrating mid-buffer. Pushing communications and hardware-telemetry processes onto CCD 1 protects the same cores from the opposite direction. L-Connect's fan polling and Discord's voice encoding never get a chance to pollute the cache lanes reserved for gaming or audio.
| Group | Cores | Priority | Efficiency Mode |
|---|---|---|---|
| Games, DAWs, viewports | 0–15 | High | Off |
| Audio driver (Focusrite) | 0–15 | Above Normal | Off |
| Background, launchers, comms | 16–31 | Below Normal | On |
| System services, lighting | 16–31 | Idle | Off |
Outcomes
The system now sustains roughly 3200 MHz GPU core under load against a stock boost of 2610 MHz, with a validated V/F curve and dynamic fan response rather than a fixed offset chasing an unstable peak. CCD1 held within its 80°C protection threshold across a full overnight stress run with zero crashes, driver resets, or memory errors, and the 1:1:1 FCLK/UCLK/MCLK synchronisation held at 6000 MT/s with zero PMIC warnings throughout.
The broader lesson is that overclocking a modern heterogeneous platform is a systems problem, not a per-component one. The Curve Optimizer offset, the memory fabric ratio, the AIO's tracking source, and the OS scheduler's CCD boundary all interact, and tuning any one of them in isolation from the others would have left real performance on the table or introduced instability nothing in that single component's settings could explain. Treating the fresh install as an opportunity to rebuild every layer from first principles, rather than restoring a backup of old settings, is what made it possible to actually understand why each setting mattered instead of just inheriting that it worked.