AMD Ryzen 9 9950X3D 4.3/5.7GHz Box

[jordiqui]

Controlled Super Pi Overclocking Plan

AMD Ryzen 9 9950X3D / ASUS ROG Crosshair X870E Extreme / DDR5 96 GB 5600 CL40
0. Platform Characterisation

The tested system is a high-end AM5 platform built around:

• CPU: AMD Ryzen 9 9950X3D
• Motherboard: ASUS ROG Crosshair X870E Extreme
• Memory: Corsair Vengeance DDR5 5600 MT/s 96 GB, 2 x 48 GB, CL40
• GPU: ASUS TUF Gaming GeForce RTX 5090 OC 32 GB
• PSU: Corsair HX1500i ATX 3.1 / PCIe 5.1, 1500 W, 80 Plus Platinum
• Storage: WD Black SN8100 4 TB PCIe 5.0 NVMe
• Case: HYTE Y70 Touch Infinite
• Cooling: custom hard-tube liquid cooling
• OS: Windows 11 Pro

The Ryzen 9 9950X3D is a 16-core / 32-thread processor with a 4.3 GHz base clock, up to 5.7 GHz boost clock, 128 MB L3 cache, 170 W default TDP, unlocked overclocking support, AMD EXPO support, Precision Boost Overdrive support and Curve Optimizer support. These points are important because Super Pi optimisation should not start with a fixed all-core manual overclock; it should start by preserving and improving effective single-thread boost behaviour.

The ASUS ROG Crosshair X870E Extreme is an appropriate motherboard for this kind of controlled work. ASUS lists it as a flagship AM5 board for Ryzen 9000 processors, with DDR5 support, PCIe 5.0 support, USB4, extensive cooling control, EXPO/AEMP memory tuning support and a high-end VRM design with 20+2+2 power stages.

Super Pi is a Windows benchmark that calculates pi up to 32 million digits and has historically been used in the overclocking community as a benchmark and stability indicator. It is not GPU-bound; therefore, the RTX 5090 should be left at stock for this test path.

1. Benchmark Objective

The target is not general gaming performance. The target is the best reproducible Super Pi result.

Super Pi performance is mainly controlled by:

• 1. Effective single-thread CPU frequency
• 2. Memory latency
• 3. Cache and interconnect behaviour
• 4. Windows scheduling noise
• 5. Thermal stability
• 6. Run-to-run consistency

For this platform, the RTX 5090 is not a performance variable for Super Pi. It can only become a negative variable if GPU heat is dumped into the same liquid loop and increases coolant temperature.

2. Important Limitation: The Installed RAM Kit

The installed memory is:

• DDR5 5600 MT/s
• 96 GB total
• 2 x 48 GB
• CL40

This is a capacity-oriented workstation/gaming kit, not a naturally aggressive Super Pi kit.

Theoretical first-word CAS latency:

DDR5-5600 effective clock = 2800 MHz
CL40 latency = 40 / 2800 MHz = 14.29 ns

That does not mean the kit is bad. It means that for Super Pi 32M, the memory subsystem will probably be the limiting area after CPU boost is optimised.

The correct approach is not to invent DDR5-6400 or DDR5-6600 targets. The correct approach is:

• Step 1: Validate stock 5600 CL40.
• Step 2: Try tighter timings at 5600.
• Step 3: Try moderate frequency increases only if the IMC remains stable.
• Step 4: Compare Super Pi 32M loop consistency, not only boot stability.
• 3. Safety Principle

This should be treated as a controlled benchmark configuration, not a daily-use blind overclock.

Rules:

• Do not change CPU, memory, SoC voltage and timings simultaneously.
• Do not start with manual all-core overclocking.
• Do not use aggressive BCLK changes at the beginning.
• Do not overclock the RTX 5090 for Super Pi.
• Do not judge stability from Super Pi 1M only.
• Do not keep a setting if the score improves once but becomes inconsistent.

The Ryzen 9 9950X3D already has high boost behaviour. A fixed all-core clock can easily reduce the best single-thread boost path. For Super Pi, effective peak core behaviour is usually more important than a visually impressive all-core number.

• Stage A — Evidence Baseline
• Step A1 — BIOS Reset and Documentation

Start from BIOS optimised defaults.

Record:

BIOS version:
AGESA version:
CPU temperature at idle:
Coolant temperature, if sensor exists:
Room temperature:
RAM profile:
VDD:
VDDQ:
SoC voltage:
FCLK:
UCLK:
MCLK:
Windows build:
AMD chipset driver version:
Why

Without this baseline, later improvement cannot be attributed to any specific change.

Step A2 — Stock Super Pi Baseline

Run:

• Super Pi 1M: 5 runs
• Super Pi 32M: 3 runs

Record:

Best time:
Median time:
Worst time:
Loop consistency:
Effective CPU clock:
Peak temperature:
Background processes:
Why

Super Pi is sensitive to scheduler noise. The best run alone is not enough. The median run matters because it shows whether the platform is actually stable and repeatable.

Stage B — Operating System Isolation
Step B1 — Windows Benchmark Profile

Create a clean Windows benchmark profile:

Disable unnecessary startup applications.
Disconnect non-essential background software.
Pause Windows Update.
Close RGB control suites during the run if they poll sensors heavily.
Disable overlays.
Disable browser, launchers and cloud sync.
Use a fixed power plan.
Keep the benchmark on local NVMe storage.
Why

Super Pi is a light single-thread workload. Background polling can affect the final result disproportionately.

Step B2 — Core Affinity Testing

Do not assume the best core. Test it.

Procedure:

1. Use CPU-Z / HWiNFO / Ryzen Master to identify preferred cores.
2. Run Super Pi 1M pinned to each candidate preferred core.
3. Repeat each candidate core at least three times.
4. Select the core with the best repeatable median, not only the best one-off run.
   Why

The 9950X3D is a dual-chiplet CPU. Super Pi may prefer the highest effective frequency path rather than the largest cache path. This must be measured, not assumed.

Stage C — CPU Boost Optimisation
Step C1 — Preserve Automatic Boost First

Initial CPU strategy:

• Manual all-core overclock: OFF
• PBO: enabled/advanced only after baseline
• Boost override: initially 0
• Scalar: conservative / Auto
• Thermal limit: documented, not guessed
• Curve Optimizer: disabled for first baseline
  Why

The 9950X3D supports Precision Boost Overdrive and Curve Optimizer. The goal is to improve the existing boost algorithm, not immediately replace it with a fixed manual clock.

Step C2 — Curve Optimizer Method

Use Curve Optimizer incrementally.

Recommended forensic sequence:

• Run 1: Stock / Auto
• Run 2: PBO enabled, no CO
• Run 3: CO negative, very mild all-core offset
• Run 4: CO per-core only after identifying preferred Super Pi core
• Run 5: Tune only the selected benchmark core more aggressively

Do not publish a fixed universal value such as “CO -30” as if it were guaranteed. It is silicon-dependent.

Why

Negative Curve Optimizer can reduce voltage demand and allow higher effective boost, but too much negative offset creates calculation errors, WHEA errors or silent instability. Super Pi 32M is useful here because it exposes marginal instability better than a single short 1M run.

Step C3 — Boost Override

Only after Curve Optimizer is stable:

• Increase boost override in small steps.
• Run Super Pi 1M after each step.
• Run Super Pi 32M after any promising step.
• Monitor effective clock, not only configured clock.
  Why

A configured boost increase is meaningless if effective clock does not rise or if thermal/power limits reduce sustained behaviour.

• Stage D — Memory Optimisation
• Step D1 — Validate DDR5-5600 CL40 First

Before tuning, validate the stock memory profile.

Minimum validation:

• Super Pi 32M: clean pass
• Memory test: clean pass
• No WHEA errors
• No retraining failures
• No cold-boot instability
  Why

The installed kit is 2 x 48 GB. High-capacity DDR5 can be more demanding on the memory controller than smaller benchmark-oriented kits.

Step D2 — Tighten Timings Before Chasing Frequency

First tuning direction:

• Keep DDR5-5600.
• Reduce primary timings carefully.
• Validate each change.
• Record Super Pi 32M loop times.

Suggested tuning order:

• 1. Command rate / memory context behaviour
• 2. CAS latency
• 3. tRCD / tRP
• 4. tRAS
• 5. tRFC
• 6. Secondary timings
• 7. Tertiary timings
     Why

For Super Pi 32M, latency can matter more than raw bandwidth. A lower-frequency profile with tighter timings may outperform a higher-frequency profile with loose timings.

Step D3 — Frequency Scaling

Only after timing work at 5600:

Try the next memory ratio.
Keep timings loose enough to boot.
Validate.
Then tighten again.

Possible test matrix:

• Profile 1: 5600 CL40 stock
• Profile 2: 5600 tightened
• Profile 3: moderate higher-frequency loose
• Profile 4: moderate higher-frequency tightened
  Why

This avoids the common mistake of comparing two variables at once. If frequency and timings both change, the result cannot be interpreted cleanly.

Stage E — FCLK / UCLK / MCLK Control

For each memory profile, record:

• MCLK
• UCLK
• FCLK
• UCLK:MCLK ratio
• Memory training result
• Boot reliability
• Super Pi 32M loop variance
  Why

On AM5, memory performance is not only DDR5 frequency. The relationship between memory clock, memory controller clock and fabric behaviour can change real latency. Super Pi 32M is sensitive to that relationship.

• Stage F — Thermal Control
• Step F1 — Liquid Loop Stabilisation

Before each serious run:

• Allow coolant temperature to stabilise.
• Record room temperature.
• Record coolant temperature if available.
• Run the same warm-up procedure.
• Start Super Pi from the same thermal condition.
  Why

A custom hard-tube loop gives strong thermal capacity, but if the GPU and CPU are in the same loop, residual GPU heat can pollute CPU benchmark results. For Super Pi, the GPU should be idle.

Step F2 — Fan and Pump Policy

Use fixed fan and pump settings during benchmark runs.

Pump: fixed high-performance setting
Radiator fans: fixed RPM or fixed curve
Case fans: fixed profile
GPU: stock / idle
Why

Changing fan curves during a run can change coolant temperature and introduce run-to-run variation.

Stage G — Final Benchmark Profiles

Use three final profiles.

• Profile 1 — Reference Stock
• BIOS defaults
• EXPO/XMP as delivered
• No PBO tuning
• No CO tuning
• No manual memory tuning

Purpose:

• Official baseline.
• Profile 2 — Safe Daily Optimised
• PBO tuned conservatively
• Curve Optimizer validated
• Memory stable and modestly tightened
• No aggressive voltage
• No BCLK tuning
• No GPU overclock

Purpose:

• Best practical configuration without sacrificing reliability.
• Profile 3 — Benchmark-Only Super Pi Profile
• Pinned best core
• Clean Windows session
• Aggressive but validated Curve Optimizer
• Best validated memory timing profile
• Fixed cooling behaviour
• Documented ambient/coolant temperature

Purpose:

Best Super Pi result under controlled conditions.
Required Evidence for Forum Publication

Final result should include:

• CPU-Z CPU tab
• CPU-Z Mainboard tab
• CPU-Z Memory tab
• ZenTimings screenshot
• HWiNFO effective clock screenshot
• Super Pi final screenshot
• Ambient temperature
• Coolant temperature if available
• BIOS version
• Windows build
• AMD chipset driver version
• Exact BIOS settings changed
• Number of runs
• Best / median / worst time
• Engineering Interpretation

This platform is extremely strong, but for Super Pi the limiting factors are not the same as for gaming.

The strengths are:

• High single-thread boost potential
• Excellent motherboard for AM5 tuning
• Strong PSU headroom
• Strong cooling potential
• Fast NVMe storage

The main limitation for Super Pi is likely:

DDR5 5600 CL40 96 GB memory latency

That RAM configuration is excellent for heavy multitasking, content creation and workstation usage, but it is not an obvious Super Pi 32M-optimised memory profile. Therefore, the highest-impact controlled work after CPU boost tuning will probably be memory timing optimisation.

Final Rule

No result should be considered valid unless it is:

• Repeatable
• Screenshot-documented
• Thermally documented
• Free of WHEA errors
• Stable in Super Pi 32M
• Compared against a clean stock baseline

[cobito]

@jordiqui I see you place a lot of importance on RAM, but the Ryzen 9 9950X3D has 128MB of L3 cache and 1MB of L2 cache. I don't know how much RAM SuperPi 32M uses, but if it exceeds 128MB, it won't be by much. Does RAM really have that much of an impact? And if it does, given that it works with small data sizes and is a CPU-intensive process, wouldn't it make more sense to focus on lowering latencies rather than frequency? In fact, wouldn't it be worth trying to underclock the memory just to improve the latencies?

I'm bringing this up because I'm on the opposite end of the spectrum with LLMs, which have massive RAM consumption where bandwidth is the primary bottleneck and where having a large cache only helps to a certain extent. If it were up to me, I'd sacrifice latency for bandwidth because I know the performance gain will be practically linear with every MT/s I can squeeze out.

[jordiqui]

@cobito said:

@jordiqui I see you place a lot of importance on RAM, but the Ryzen 9 9950X3D has 128MB of L3 cache and 1MB of L2 cache. I don't know how much SuperPi 32M uses, but if it exceeds the 128MB, it won't be by much. Does RAM really have that much of an impact? And if it does, given that it involves small data amounts and a CPU-intensive process, wouldn't it be better to reduce latencies rather than focus on frequency? In fact, wouldn't it be interesting to try underclocking the memory just to improve latencies?

I'm mentioning this because I'm on the opposite end of the spectrum with LLMs, which have massive RAM consumption where bandwidth is the main bottleneck and where having a lot of cache helps to a certain extent. If it were up to me, I'd sacrifice latency for bandwidth because I know the performance increase will be practically linear with every MT/s I can squeeze out.

I agree with you regarding bandwidth. I was looking into different tests with this configuration, and after seeing the full picture, I asked GPT to recreate this scenario.