Veteranos HL group

jordiqui

@cobito Gracias por la respuesta. Pues esperamos a poder sacar números concretos, para poder extaer conclusiones. Sin datos concretos, no podemos hacerlo. Pero como referido es muy poco, aunque con lo que me cuentas habrá que esperar. Seguimos pues tal como estamos y valoramos con datos verificables reales.

Yorus

Incluso se pueden descargar de la misma web si se prefiere jugar en local, emulando o con máquina real

pos_yo

@cobito Impresionante todo lo que estás implementando solo "for fun". Es un gran trabajo, ¡gracias!

pos_yo

@krampak Éste es el canal... El vídeo es un vídeo muy corto rollo short que explica como desactivar el wifi y poco más pero el canal tiene alguna cosita interesante

pos_yo

@_Neptunno_ Yo me lo jugué en su día. Incluso hice una especie de tutorial para instalarlo en Linux (ahora es incluso más fácil).

A mí me moló y, con respecto a los DLC (me los pillé en su día con puntos de la Epic Store) pues están bien pero tampoco matan. Lo mejor es el juego principal.

@_Neptunno_ said:

• Las "fumadas" de Remedy:

El "musical" es de lo mejor de esas fumadas...

pos_yo

@cobito Le he echado un vistazo rápido (la he probado con wine desde linux) y se ve más moderna y el monitor me parece muy útil... He validado la prueba para compararla con la prueba que hice desde w11 y... bueno... ya me imaginaba que iba a tener menos rendimiento...

jordiqui

@krampak said:

@jordiqui Es raro porque esos servidores enracables son estándard (sólo varia si ocupan 1U o 2U) y siempre van montados en los racks de 19 pulgadas de ancho, lo que sí puede variar es la profundidad y guías, en función de si son LFF o SFF. No se exáctamente qué te vendieron.

Y así es, @krampak me reconocieron el error, pero en aquel momento me empeñé en intentar hacer que funcionara y claro, ya no podía devolverlo. Pero sí, me enviarón el correo con el armario correspondiente compatible, porque como bien dices son 1u o 2u. Pero es pasado, y me lo ha recordado esta imagen el otro día. Ahora, me quité de encima dos y me he quedado con el en mejor condiciones estaba. Un abrazo mi querido amigo.

jordiqui

@cobito said:

@jordiqui Veo que le das mucha importancia a la RAM pero el Ryzen 9 9950X3D tiene 128MB de caché de nivel 3 y 1MB de nivel 2. No sé cuanto consume SuperPi 32M, pero si se sale de los 128MB no será por demasiado. ¿De verdad afecta tanto la RAM? Y si afecta, al ser por cantidades pequeñas y un proceso intensivo de CPU, ¿no sería conveniente apretar las latencias más que la frecuencia? Es más, ¿no sería interesante probar a hacer underclocking a la memora con tal de mejorar las latencias?

Te lo comento porque yo estoy en el extremo contrario con los LLM con consumos enormes de RAM donde el ancho de banda es el cuello de botella predominante y donde tener mucha caché ayuda en cierta medida. Si por mi fuera, sacrificaría las latencias por ancho de banda porque sé que el aumento de rendimiento va a ser prácticamente lineal con cada MT/s que raspe.

Coincido contigo con el ancho de banda, estuve indagando con esta configuración diferentes test, luego viendo el conjunto le pregunté a gpt una recreación de este escenario.

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.

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
1. Memory latency
1. Cache and interconnect behaviour
1. Windows scheduling noise
1. Thermal stability
1. 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.

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.
1. 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:

Use CPU-Z / HWiNFO / Ryzen Master to identify preferred cores.
Run Super Pi 1M pinned to each candidate preferred core.
Repeat each candidate core at least three times.
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
1. CAS latency
1. tRCD / tRP
1. tRAS
1. tRFC
1. Secondary timings
1. 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

jordiqui

I'm looking at this now after doing my research—and I wouldn't have bought it without doing so—and I'm furious at what a well-known online store did. Even though I provided all the details—model, rack size, etc.—they sent me something that was only good for placing those two servers on top of, not for mounting them in a rack... etc...

Veteranos HL

Posts

Controlled Super Pi Overclocking Plan

Step A2 — Stock Super Pi Baseline

Step B2 — Core Affinity Testing

Step C2 — Curve Optimizer Method

Step C3 — Boost Override

Step D2 — Tighten Timings Before Chasing Frequency

Step D3 — Frequency Scaling

Step F2 — Fan and Pump Policy

Final Rule

Member List