SakeTami
1usmus

1usmus

patreon


1usmus posts

đŸ”„ BREAKING NEWS! đŸ”„ Curve Shaper full support? - YES!

View Post

HYDRA 2.1C PRO (build 2121) - RELEASED!

View Post

HYDRA Vanta - Next-Generation GPU Memory Stress Test

View Post

HYDRA NEWS!

View Post

HYDRA 2.1C PRO (build 2120) - RELEASED!

View Post

HYDRA 2.1B PRO (build 2110) - RELEASED!

View Post

HYDRA 2.1A PRO (build 2104, Xmas & New Year update) - RELEASED!

Dear HYDRA Early Access supporters on Patreon, thank you sincerely for standing with us throughout this year.

We’ve overcome a lot: stubborn bugs, hard technical constraints, countless iterations, and relentless real-hardware validation. But thanks to that work - and especially thanks to your feedback - HYDRA has become more stable, more accurate, and more powerful as a tool. You are not “just subscribers.” You are my inspiration and the reason I keep the quality bar as high as possible.

In 2026, we’re planning to deliver many truly exciting things: more capabilities, deeper diagnostics, new workflows, and long-awaited improvements that you’ve been asking for and that we’ve been holding in the roadmap for a while. I want HYDRA to grow in a way that fully matches your trust.

One important note: today’s update is not the final update of this year. There is still one more step coming to close the year properly.

Happy holidays, and thank you for being with HYDRA.

ONLINE-GUIDE (1.8H) :

LINK

CHANGELOG:

  • Improvements to DRAM diagnostics stability, in particular fixing causes of looping, ignoring settings, and support for new AGESA.

  • Added reading and logging of EXPO/XMP profiles for Ryzen processors (temporary only for DDR5). You can find the “READ SPD” button on the DCFR tab.

  • Fixed a bug that prevented users of processors with a single CCD from trying DRAM LAB.

  • Major stability update for RX-TUNER and RTX-TUNER.

  • Support for simultaneous use of different generations of Radeon in RX-TUNER.

  • The PowerPlay table modification works correctly for the RX 6500 - RX 6950 generation of graphics cards (experimental update.).

  • Other improvements to the stability and performance of HYDRA modules. Updated dll's.

  • Improved stability of Phoeinix mode for video card diagnostics (auto-tuning).

  • Improved logging for some modules.

  • Added some tolerance when working with Ryzen SMU for cluttered systems.

  • Added experimental support for 5800X3D, 7800X3D, and 9800X3D, which actually have 2 CCDs.

  • Fixed a bug that prevented the video card performance comparison test between standard and tuned states from running.

  • The APP PACK selection window has been redesigned.

  • Over 40 minor fixes to improve application stability and performance.

  • T-CONTROL improvements, new automatic feature - pushing third-party processes to the second CCD during gameplay (available only for Ryzen 9 users).

  • T-CONTROL has been given process control bar status. 0 - everything is fine.

  • Simplified T-CONTROL interface for greater user comfort.

  • DDR5 diagnostics, updated ProcODT and RTT search phase. It has tremendous flexibility in terms of user configuration.

  • DDR5 diagnostics, "Motherboard" - a new control element that allows you to select the motherboard class. The accuracy of the results depends on the choice.

  • During GPU diagnostics, the artificial delay has been removed to allow the chip to cool down. For some, this micro-phase could have lasted forever.

  • Improved stability when working with RTSS.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

HYDRA DRAM LAB 1.1 - DEEP DIVE INTO DRAM OPTIMIZATION

Why HYDRA DRAM LAB Is a New Standard for Memory Testing

1. The problem with traditional DRAM benchmarks

Most popular memory tests were never designed for gamers. They were built for service tasks and pretty screenshots: maximum GB/s, a single “latency” number, long AVX copies, almost perfectly linear access patterns.

In real games, nothing looks like that:

  • Memory access is small and chaotic, not one giant linear stream.

  • The CPU hits AI, physics, engine systems, streaming, networking, UI all at once, each with its own pattern.

  • What matters is not just “average” values, but the tail of the distribution: P95, P99, stutters, jitter.

  • Ryzen architecture (Zen 3 / Zen 4 / Zen 5) with its CCD layout, Infinity Fabric, bank groups, tFAW, tRRD, refresh behavior behaves very differently from old platforms classical tests were tuned for.

Result:

  • You can have a “nice” latency in a synthetic test and worse smoothness in games.

  • Timings that truly affect stutters and tails are not highlighted separately.

  • Overclocking becomes “feel-based”: you tweak CL/tRCD/REFI, watch AIDA/MaxxMem
 and then wonder why Warzone or Apex feels worse.

HYDRA DRAM LAB was built exactly against that: as a tool that speaks the language of gaming comfort, not just marketing GB/s.

2. The philosophy of HYDRA DRAM LAB

DRAM LAB is not trying to be “just another latency X ns, read Y GB/s” benchmark.
Its goal is to show the behavior of your memory subsystem as a whole, working together with Ryzen instead of in a vacuum.

Core ideas:

  • Game-like scenarios instead of lab vacuum.
    Some tests push memory in a way that resembles what modern games actually do: mixed reads/writes, multithreaded access, contention on the memory controller, chaotic access patterns.

  • Focus on tails and smoothness.
    DRAM LAB exposes not only averages, but P50, P99, Game P99, Game Stut, Jitter, Bank Thrash - the exact things that answer the question:

    “Why do I have 200 FPS and still feel stuttering?”

  • Different access patterns, not one magic number.
    Local / Scattered latency, MLP, R/W Turn, Bank Thrash - these are different facets of the same subsystem.
    They highlight different timing groups: sometimes tRRD/tFAW, sometimes tRFC/REFI, sometimes RD↔WR cross-timings.

  • Deep adaptation to Zen 3/4/5.
    Buffer sizes, access patterns, and load behavior are designed so that:

    • the working set actually leaves L3,

    • prefetchers can’t just “fake” good results,

    • you see the behavior of the memory controller and Infinity Fabric, not just cache tricks.

The algorithms remain a black box: the user sees clean, meaningful metrics, while DRAM LAB’s internals stay unique HYDRA IP.

3. Practical advantages for gamers and overclockers

HYDRA DRAM LAB is built as a tuning lab, not a one-shot “run and forget” tool.

What this means in practice:

  • One run = a full snapshot of your system.
    You get 15 metrics that probe different corners of the memory subsystem:
    from base Lat P50 to Game Stut%, Bank Thrash and MLP Eff.

  • Direct link from “timing” to “feeling in-game”.
    Want to know whether it makes sense to tweak REFI / RFC? Look at Game P99 / Game Stut / Jitter.
    Want to squeeze tRRD/tFAW? Check MLP and Bank Thrash.
    DRAM LAB turns abstract numbers into clear tuning directions.

  • Profile comparison and progress tracking.
    Results can be stored, compared, and shared with other enthusiasts.
    It’s no longer “I feel it’s better”, but:

    “Here are two profiles. This one has lower Game P99 and half the Game Stut - that’s the one worth keeping.”

  • Part of the HYDRA ecosystem.
    DRAM LAB lives in the same world as your smart CPU/GPU OC, monitoring, and tuning logic.
    It’s not a random external utility - it’s a core part of your overclocking workspace.

4. Why it’s “better than anything else out there”

Not because a marketing slide says so, but because DRAM LAB:

  • is focused on real gaming scenarios, not just synthetic benchmarks;

  • speaks the language of P99, stutters, and tails, not just averages;

  • is designed specifically for Ryzen Zen 3/4/5, not just “kind of works” on them;

  • lets overclockers see the impact of specific timings on specific aspects of memory behavior;

  • enables you to build your own DRAM methodology: profiles, tables, comparisons, community references.

HYDRA DRAM LAB is not just “yet another latency number”. It’s a tool that helps you understand why your PC suddenly starts feeling “butter smooth”, instead of just showing that some number dropped by 2 ns.

How to perceive DRAM LAB metrics

Legend for Raw Latency Distribution Histogram

What this chart shows
This is an X-ray of your latency: millions of samples sorted into bins. On the X axis you have latency in nanoseconds. On the Y axis you have how many times such latency was observed.

The more the bars are clustered to the left and tightly packed, the faster and more consistent your memory feels.

The histogram is split into access types:

  • Fast Random (green)
    A “light” scenario - quick random accesses where the memory controller is still comfortable.
    You see the base DRAM latency when nothing major interferes.

  • Standard Random (yellow)
    Typical random access with a mix of row hits and row misses across banks.
    Closer to what an average game does: not ideal, but not a worst-case storm either.

  • Contested Random (orange)
    A scenario where memory is under pressure from multiple threads.
    More bank conflicts, more row opens/closes, more work for the controller.
    This bar shows how parallelism-related timings (RRD, FAW, RDWR/WRRD, etc.) and controller behavior affect the latency tail.

  • Worst Case Hardware Latency (small bar on the far right)
    The “worst 1-2% of life” of your platform: refresh + unlucky bank + conflict + contention all at once.
    It represents the hardware worst-case latency under extreme conditions.

How to read it

  • If Fast Random and Standard Random are tight and far to the left - your baseline latency profile is excellent.

  • If Contested Random is not much further to the right than Standard, your memory holds up well under multi-threaded pressure.

  • If Worst Case Hardware Latency sits far to the right and has a noticeable height - you’ll feel stutters in the tails even with good averages.

Timings / settings that matter most

  • For Fast / Standard Random:

    • Primary: CL, tRCDRD/tRCDWR, tRP, tRAS, tRC

    • Frequencies: MCLK / UCLK / FCLK (1:1 when possible)

  • For Contested Random:

    • Bank-related: tRRD_S, tRRD_L, tFAW, tRC

    • R↔W cross-timings: tRDWR, tWRRD, tWTR_S/L, tWR, tRTP

    • Controller settings that affect parallelism (MLP).

  • For Worst Case Hardware Latency:

    • Refresh: tRFC, tREFI

    • Power / low-power modes: PDM and related options

    • Stability of clocks and voltages: VDIMM, VDDQ, VSOC, MC (unstable OC often inflates this tail first).

Legend for L2-L3-DRAM latency (pointer chasing) Curve

What this chart shows
This curve plots access latency vs working-set size (Sample size, MB):

  • On the left you have small data that fits into caches.

  • On the right you have large data that forces the CPU to go out to DRAM.

X axis - data size in MB.
Y axis - access latency in nanoseconds.

The curve typically has three regions:

  1. L2 plateau - the lowest part. Very small sizes, latency of just a few ns.

  2. L3 plateau - a noticeable step up, but still below DRAM latency.

  3. DRAM region - once the working set exceeds L3 capacity, the curve climbs to a new, higher level.

The “knee” points of the curve show the effective cache boundaries and the point where a game starts to pay the full price of DRAM access.

How to interpret it

  • The lower the DRAM plateau (right side of the curve), the better your baseline memory latency.

  • The smoother the transition from L3 to DRAM, the fewer abrupt latency jumps you’ll see as scenes and working sets grow.

  • The L2→L3 and L3→DRAM steps are what you feel as:

    “As soon as the scene gets heavier / more objects appear, the game starts thinking longer.”

What you can and cannot tune

  • L2 region

    • Mostly defined by core architecture and CPU frequency.

    • DRAM timings hardly affect it.

  • L3 region and the L3→DRAM transition

    • Driven by FCLK, CCD topology, and memory controller behavior.

    • Indirectly responds to MCLK/UCLK and memory settings via interaction with Infinity Fabric.

  • DRAM plateau (right side)
    Here your memory settings truly matter:

    • Primary timings: CL, tRCDRD, tRP, tRAS, tRC

    • Frequencies: MCLK / UCLK / FCLK ratios (1:1 vs 1:2, etc.)

    • Secondary timings that impact row misses and bank behavior (tRRD, tFAW, tRFC/REFI in more extreme scenarios).

The tuner’s goal is to:

  • Push the DRAM plateau as low as possible,

  • smooth out the steps between caches and DRAM,

  • and keep the system stable while doing it.

1. Lat P50 (ns) - Baseline memory latency at idle

What it means
Lat P50 is the median (50th percentile) latency of memory access when the system isn’t heavily loaded. Imagine the game randomly pulling small chunks of data from a big scene - Lat P50 is how long that usually takes, in nanoseconds, once caches are no longer helping.

How it feels in games
Lower Lat P50 = a “tighter” and more responsive system. Menus feel snappier, background OS tasks cause fewer tiny hitches, and the CPU can pull data from DRAM quickly when it needs to.

Timings / settings that affect it most

  • Primary timings

    • CL (CAS Latency) - one of the main drivers; lowering CL almost always drags Lat P50 down.

    • tRCDRD / tRCDWR - delay between row activation and read/write; important for random access.

    • tRP - time to precharge (close) a row before opening another; matters when access is not very local.

  • Secondary / tertiary

    • tRAS, tRC - define the minimum open+close cycle for a row; affect average latency when there are many row misses.

    • tRRD_S / tRRD_L, tFAW - limit how quickly new rows can be activated in banks / bank groups, so they slightly touch the median.

  • Platform settings

    • MCLK / UCLK / FCLK - a 1:1 memory–controller link (especially on DDR4 and early DDR5) often gives the lowest latency.

    • CMD rate (1T/2T), GDM, PDM - more aggressive modes (1T, GDM Off) can shave off a bit of latency but may hurt stability.

    • VDIMM, VSOC, memory controller / VDDQ - don’t change latency by themselves, but allow you to hold tighter timings safely.

2. Lat P99 (ns) - The tail of latency, worst 1%

What it means
Lat P99 shows how bad latency gets for the slowest 1% of memory accesses. This is not about “average”, it’s about those rare but painful slow requests - the ones that create micro-stutters.

How it feels in games
High Lat P99 = sudden hitches on top of an otherwise smooth experience. Short visible pauses when loading a texture, a small freeze when a script triggers, or a weird hiccup during quick camera turns.

What it depends on

  • Primary / secondary

    • Everything that affects Lat P50 also affects P99: CL, tRCDRD, tRP, tRAS, tRC.

    • But P99 is especially sensitive to “heavy” timings and DRAM maintenance events:

      • tRFC - refresh cycle time; large tRFC = long periods where DRAM can’t respond.

      • tREFI - refresh interval; smaller tREFI = more frequent refresh → more chances for long spikes.

      • tRRD_S / tRRD_L, tFAW - limit how aggressively you can open rows across banks/bank groups.

  • Platform

    • Background processes and OS scheduler - can push some accesses into the worst 1% zone.

    • MCLK/UCLK/FCLK - unstable or suboptimal combinations (e.g. odd FCLK) can increase the tail even if the median looks fine.

3. Read MT (GB/s) - Game-like multithread read bandwidth

What it means
Read MT shows how many GB/s your system can realistically read from DRAM in a multithreaded scenario with small, scattered blocks of data. This is much closer to what games do than a simple linear STREAM copy.

How it feels in games
This tells you how quickly the game can stream in maps, models, animations, and textures when the CPU is hammering memory from multiple threads. Higher Read MT = fewer situations where the GPU sits waiting for data.

Key influences

  • Frequencies

    • MCLK - base bandwidth; higher and stable is better.

    • UCLK, FCLK - the relationship between memory controller and Infinity Fabric; 1:1 or well-tuned ratios help.

  • Primary / secondary timings

    • tRCDRD, tRP, tRAS, tRC - define how fast the controller can open/close rows during scattered reads.

    • tRRD_S / tRRD_L, tFAW - limit the rate of row activates across banks; very important for parallel read bursts.

    • Read-to-read tertiary timings (RDRDSCL, RDRDSC/SD/DD) - fine-tune transitions between reads in different banks/rows.

  • Other

    • GDM, CMD rate - can slightly help or hurt effective bandwidth at high frequency.

    • VDIMM / VDDQ / MC voltage - allow stable aggressive timings and frequencies.

4. Write MT (GB/s) - Multithread write bandwidth

What it means
Write MT measures how fast your memory can accept data from the CPU when several threads are writing small blocks all over the buffer. This is the “how quickly we can update world state” side of memory performance.

How it feels in games
Low Write MT can show up as hitches during autosaves, heavy streaming, lots of dynamic objects, or anything that involves frequent updates to buffers and world data.

What affects it

  • Primary / secondary

    • tRCDWR, tRCDRD, tRP, tRAS, tRC - core timings for row open/close during write-heavy workloads.

    • tWR (Write Recovery) - how long a row must stay open after a write before it can be precharged; very important for write throughput.

    • tWTR_S / tWTR_L, tWRRD, tRDWR - transitions between writes and reads; even in write-focused workloads, mixed operations still exist.

    • WRWR SC/SD/DD timings - micro-transitions between sequential writes in different banks.

  • Frequencies / other

    • MCLK, UCLK, FCLK - the usual foundation.

    • VDIMM, VDDQ, MC voltage, VSOC - often the difference between being able to tighten write-related timings or not.

5. Local P50 (ns) - Row-hit latency when data is “already open”

What it means
Local P50 measures how fast DRAM responds when access is more local: the controller often hits already open rows (row hits). This is close to a best-case “hot row” scenario.

How it feels in games
Think of this as the “sweet spot” where your workload lines up nicely with the DRAM layout. Lower Local P50 means behavior closer to L3-like smoothness when the working set fits well into caches and into already open DRAM rows.

Most relevant timings / settings

  • Primary

    • CL, tRCDRD - even with a row hit, column latency still matters.

    • tCWL - influences write paths, which indirectly interact with reads in mixed patterns.

  • Tertiary / micro-timings

    • RDRDSCL, RDRDSC/SD/DD - fine-grain timings for sequential reads within “nearby” addresses; very relevant for local patterns.

    • WRWRSCL / WRWRSC/SD/DD - if the game mixes reads and writes in the same region, these show up too.

  • Platform

    • MCLK / UCLK (1:1) - strong impact.

    • CMD rate, GDM - switching from 2T/GDM On to 1T/GDM Off can reduce Local P50 slightly at the cost of stability margin.

6. Scattered P50 (ns) - Row-miss latency when everything is spread out

What it means
Scattered P50 is the median latency when accesses are spread across different rows and banks, forcing the controller to constantly open and close rows. This is much closer to “open-world chaos” than to a neat, local pattern.

How it feels in games
The bigger the gap between Local P50 and Scattered P50, the more your system will suffer in badly cached, wide scenes: huge maps, crowded areas, complex streaming.

Key timings

  • Primary

    • tRP - precharge time; with frequent row misses, this becomes critical.

    • tRCDRD / tRCDWR, tRAS, tRC - define the full open→read/write→close cycle for a new row. This is classic row-miss territory.

  • Secondary

    • tRRD_S / tRRD_L, tFAW - control how often new rows can be activated across banks and bank groups; crucial for scattered access.

    • tRFC, tREFI - refresh events hurt even more when the pattern is already hostile to locality.

  • Platform

    • MCLK/UCLK/FCLK - higher and well-tuned frequencies help DRAM recover faster from chaotic patterns.

7. MLP Eff (%) - Effective Memory-Level Parallelism

What it means
MLP Eff tells you how well the memory controller can keep many independent DRAM requests in flight at once. 100% would mean near-perfect parallel utilization, 50% means half of the potential is wasted on waiting.

How it feels in games
This is about heavy scenes where the CPU hits lots of different data at the same time - AI, physics, streaming, shadows, effects. High MLP Eff means DRAM behaves like a wide multi-lane highway instead of a single-lane road.

What drives MLP Eff

  • Bank / group timings

    • tRRD_S / tRRD_L, tFAW - hard limits on how often you can open new rows in banks and bank groups; the main knobs for parallel activation.

    • tRC - affects how quickly the controller can re-cycle through banks.

    • RDRD / WRWR, RDWR, WRRD* - cross-bank and cross-operation timings that can either help or restrict how many requests are active in parallel.

  • Frequencies / fabric

    • MCLK, UCLK, FCLK - the memory controller and Infinity Fabric must be fast enough to keep the queue full; a weak FCLK or poor ratio can hurt MLP Eff even if raw bandwidth looks fine.

  • Other

    • VSOC, memory-controller voltage, board-specific “OC features” - can be required to push timings and frequencies to the point MLP Eff really shines.

8. R/W Turn (GB/s) — Read/Write turnaround performance

What it means
R/W Turn measures bandwidth in a mixed scenario with frequent read ↔ write switches (roughly 1:1 ratio). This is a realistic model of a game where the engine not only reads data, but also constantly updates buffers, states, and world data.

How it feels in games
If R/W Turn is low, the memory subsystem “chokes” when switching between reads and writes. You might see stutters during intense scenes where everything is being updated and read at once.

Main influences

  • Cross R↔W timings

    • tRDWR / tWRRD - core timings for switching between reading and writing; tightening them boosts R/W Turn if stable.

    • tWTR_S / tWTR_L - write-to-read delays; define how soon you can read after writing.

    • tWR, tRTP - wrap-up timings for write and read operations; part of the turnaround budget.

  • Primary / frequencies

    • tRCD, tRP, tRC - the classic row cycle cost; still important in mixed scenarios.

    • MCLK, UCLK - without enough frequency, aggressive timings can’t compensate.

9. Game P99 (ns) - Latency tail under “game-like” load (worst 1%)

What it means
Game P99 shows how bad memory latency gets under realistic game-style load, where additional worker threads are hammering memory while latency is being measured. This simulates a scenario where DRAM is busy, not idle.

How it feels in games
This is basically “how hard it will hitch in the absolute worst moments”: huge battles, heavy streaming, many background tasks (browser, Discord, recording) - all at once. Lower Game P99 = much more stable experience under stress.

What it reacts to

  • Same timings as Lat P99, but under load:

    • tRFC, tREFI - refresh events are more painful when the controller is already swamped.

    • tRRD_S / tRRD_L, tFAW, tRC - constraints on row activation in heavily loaded bank/bank-group patterns.

    • tRDWR, tWRRD, tWTR_S / tWTR_L - R/W mixing becomes the norm under load, so these matter even more.

  • Frequencies and voltages

    • MCLK/UCLK/FCLK - strong profiles with high, stable frequencies generally push Game P99 down.

    • VDIMM, VSOC, MC/VDDQ - too low voltages can cause “silent” instability manifesting as latency spikes instead of outright errors.

  • OS / background

    • Power saving modes, scheduler behavior, and background software are all visible in this metric.

10. Game Stut (%) - Percentage of “game stutters”

What it means
Game Stut is the percentage of memory accesses under game-like load that qualify as stutters - i.e. they are several times slower than the “normal” latency. The threshold is derived from the median so that only truly bad outliers are counted.

How it feels in games
This is almost a direct numeric measure of “how often the game stutters”.
0.1–0.5% feels very smooth.
2–3% and higher = you’ll notice frequent small freezes even at high FPS.

What influences it

  • Same things as Game P99, plus:

    • tREFI / tRFC - they strongly control how often and how long DRAM is unavailable, which is exactly what generates stutters.

    • GDM, CMD, PDM, vendor-specific power modes - some command/bus/power modes may smooth or worsen the long-tail latency distribution.

  • OC strategy

    • Over-aggressive timings with insufficient voltage often give you beautiful Lat P50 numbers but send Game Stut% into orbit once the system is under real load.

11. Inter-Core (ns) - Core-to-core / CCD-to-CCD latency

What it means
Inter-Core measures how long it takes for a message to travel from one core to another (especially across different CCDs). This is more about Infinity Fabric and CPU interconnect than about DRAM itself.

How it feels in games
In highly multithreaded games (big multiplayer, complex AI, heavy physics), this shows how expensive communication between threads is. High inter-CCD latency can create strange CPU usage patterns and inconsistent frame pacing.

What actually matters here

  • Platform, not DRAM timings

    • FCLK - Infinity Fabric frequency is the main knob; higher FCLK usually means lower core-to-core latency.

    • VSOC - SoC voltage that helps hold higher FCLK stable.

    • Thread scheduling / CCD layout - how Windows distributes threads across CCDs.

  • DRAM timings like CL/tRCD/tRP have almost no direct impact on this metric.
    Treat it more as a CPU/interconnect reference than as a direct DRAM tuning KPI.

12. Jitter RMS (ns) - Latency noise and consistency

What it means
Jitter RMS is the standard deviation of memory access latency at idle. If Lat P50 is the “center” of your latency, jitter shows how much everything wiggles around that center.

How it feels in games
Low jitter means a system that feels predictable: maybe not ultra-fast, but very consistent. High jitter is why a PC can feel “uneven” even when average FPS looks great — you feel the inconsistency, not the mean.

What shakes Jitter

  • Refresh behavior

    • tRFC, tREFI - the more time DRAM spends refreshing, the more the latency distribution gets stretched, especially at the long end.

  • Bank / parallelism settings

    • tRRD_S / tRRD_L, tFAW - conservative values can force the controller to wait more often, creating distinct latency bands.

  • Frequencies / voltages

    • MCLK/UCLK/FCLK - aggressive OC without sufficient voltage can increase jitter because the internal behavior becomes less uniform.

    • VDIMM, VDDQ, VSOC - a cleaner signal often equals less noise in the latency distribution.

13. Bank Thrash (GB/s) - Bandwidth under worst-case bank thrashing

What it means
Bank Thrash (GB/s) is bandwidth measured in a scenario that deliberately makes the memory controller’s life miserable: constant switching between banks, minimal locality, maximum conflicts.

How it feels in games
This models situations where the game accidentally generates a very hostile access pattern: lots of different objects, shaders, and resources all poked in a chaotic way. High Bank Thrash bandwidth means that even in this nightmare the DRAM subsystem doesn’t completely collapse.

What’s critical

  • Bank / group architecture

    • tRRD_S / tRRD_L, tFAW - the primary knobs, because they limit the rate of new row activations across banks and groups.

    • tRC, tRAS, tRP - the full row cycle still matters, but the inter-bank limits dominate in this specific pattern.

  • Frequencies / MLP

    • MCLK, UCLK, FCLK - high, stable clocks plus good MLP Eff are the key to surviving thrash patterns.

  • Voltages / stability

    • If you push tRRD_S / tRRD_L / tFAW too far, stability usually dies before bandwidth hits its theoretical maximum.

14. Bank Thrash (ns) - Latency under bank thrashing

What it means
Bank Thrash (ns) is the same hostile scenario as above, but instead of bandwidth it reports the average latency of a single access in this mess.

How it feels in games
This is effectively the opposite of Local P50: it tells you how painful things can get when the game pattern is as unfriendly to the memory subsystem as possible. High Bank Thrash latency means that in certain nasty scenes you can see sharp drops even if other metrics look good.

What affects it

  • Same bank-related timings as Bank Thrash GB/s, but here overly conservative settings directly blow up the latency:

    • tRRD_S / tRRD_L, tFAW, tRC - if you overtighten or overslack these, bandwidth might not change much, but latency can skyrocket.

    • tRFC, tREFI - refresh is extra painful when everything is already thrashing.

  • MCLK, UCLK

    • Higher clocks let the controller chew through the queue faster, even in toxic patterns, as long as the timings are in a sensible range.

15. Idle Stut (per 1M) - Stutters per million accesses at idle

What it means
Idle Stut shows how many “long” memory accesses appear per million operations in an almost idle system. It’s a normalized stutter count derived from the latency histogram in a low-load environment.

How it feels in real use
This is the “mystery” behind why you sometimes feel a tiny hitch even just on the desktop or in a very light game. If you recorded at 240 FPS and watched frame-by-frame, you’d see isolated micro-freezes caused by these outliers.

What changes Idle Stut

  • Refresh timings

    • tRFC, tREFI - the main drivers: too frequent and too long refresh cycles generate the long-tail events that show up as stutters.

  • Power / controller modes

    • PDM and various power-down / sleep states for the memory controller can introduce isolated long-latency events when the controller wakes back up.

  • Frequencies / stability

    • MCLK/UCLK/FCLK - unstable overclocks may not always crash, but they can create rare, extremely slow accesses.

    • VDIMM, VSOC, VDDQ, memory-controller voltage - if you’re on the edge, the first thing you often lose is tail stability, not outright functionality.

Control elements

Red rectangle - the ability to compare experiments with each other. In the left drop-down list, select the latest experiment, and in the right one, the one we plan to compare it with. Please note that after you have made your selection in the left and right drop-down lists, the comparison mode will automatically be activated in the parameters table and results table.

The orange rectangle allows you to select the graph display mode: curve or histogram.

The green rectangle allows you to switch between the experiment history (each experiment is automatically saved) and the trash can icon to delete the selected experiment.

The blue rectangle is a field where you can assign your own name to the experiment (it is saved automatically).

Example of step-by-step DDR5 tuning

EXPO profile, all by default

REFI: 11677 -> 65535 (max for DDR5)
There are very significant changes.

RTP: 23 -> 16 (minimum for DDR5)
RAS: 96 -> 58 (RCDRD + RTP + 4)
RC: 134 -> 96 (RAS + RP)
No significant changes, errors within the margin of error due to background OS activity.

RRDL: 15->8 (min for DDR5)
WR: 90 -> 72
WTRS: 8 -> 7
WTRL: 30 -> 24
No significant changes, errors within the margin of error due to background OS activity.

RDRDSCL: 8- > 5
WRWRSCL: 23 -> 17
RDWR: 21 -> 16
WRRD: 8 -> 4
No significant changes, errors within the margin of error due to background OS activity.

RFC: 884 (295ns) -> 540 (180ns)
There are very significant changes.

Brief conclusions:

1. Extreme timing reductions do not yield any benefits. Forget about the presets of hype YouTubers.

2. The memory controller has the right to change the timings independently, and no diagnostic utility will inform you about this. The AM5 ecosystem is very capricious and as far removed from enthusiasts as possible.

3. All distortions with extreme timings cause ECC On-Die to work more aggressively, thereby negating any performance gains due to instability. ECC On-Die cannot be disabled.

4. REFI and RFC are the only fast and proven ways to improve memory performance. Even changing CL-RCD-RP will not provide the same growth as REFI-RFC.

5. I did not consider DDR4 because it responds perfectly to changes in each timing.

6. The weakest point of AM5 is its low FCLK frequency. You can sacrifice CL-RCD-RP, but try to increase the frequency of MCLK, UCLK, and FCLK.

7. In the Game P99 and Idle Stut results table, your best friend is lower. Less is better.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

HYDRA 2.1A PRO (build 2100) - RELEASED!

I decided not to stick with the SQ AGENT 1.1 update (a personal assistant for configuring and evaluating CPU tuning quality) and...

Stop Guessing. Start Seeing. Introducing DRAM LAB.

We are thrilled to unveil DRAM LAB — a new diagnostic module in HYDRA 2.1A PRO designed to change how you perceive memory tuning.

Most benchmarks only tell you how fast your RAM is. DRAM LAB tells you how healthy and stable it actually is. It’s not just a speedometer; it’s an MRI scan for your memory subsystem.

Key Features:

  • 📊 Raw Latency Histogram: Visualize the physics of your memory access. See the exact breakdown of Page Hits (Green/Ideal), Standard Access (Yellow), and Row Conflicts (Red). If your timings are tight but unstable, the "Red Zone" will reveal what AIDA64 hides.

  • 📉 Pointer Chasing Curve: A precise L1-L2-L3-DRAM latency curve that exposes the true hardware response time, bypassing software prefetchers.

  • ⚡ Signal Quality Metrics: We measure Jitter (RMS) and Stutter Rates. High bandwidth means nothing if your signal is noisy or if you have random latency spikes while gaming.

  • đŸ”„ Stress & Patterns: Test Bank Thrashing and Inter-Core Latency to see how your memory handles worst-case scenarios and cross-CCD communication.

Why use DRAM LAB? To achieve the perfect balance between high bandwidth and rock-solid signal stability. Ensure your overclock isn't just "bootable," but truly efficient.

Available now for testing! Let’s find the limits of physics together.
Detailed instructions will be available within a few days.

ONLINE-GUIDE (1.8H) :

LINK

CHANGELOG:

  • Updated SQ Agent, version 1.1. Improved accuracy, new features, metrics, and bug fixes.

  • New!!! DRAM LAB REPORT 1.0 (TETST tab -> DRAM BENCH btn) - your personal engineering tool that will allow you to configure DRAM as efficiently as possible. Presentation coming soon.

  • Fixed bugs related to Ycruncher refusing to start. Affects all modules.

  • CPU DIAGNOSTIC - a series of improvements and fixes.

  • Updated window with log. Allows for more accurate structuring of information.

  • Fixed some bugs for DRAM DIAGNOSTIC.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

HYDRA 2.0E PRO (build 2042) - RELEASED!

Hello, hardware community!

This update is the final milestone for HYDRA 2.0E PRO. The CPU diagnostics and auto-tuning stack is now in the shape I’ve been aiming for, and I’m ready to share it with you. The algorithms are prepared for serious, long-running sessions without random exceptions or unexpected crashes.

I’ve also made a series of optimizations that reduced HYDRA’s RAM usage by almost 2.5×. On top of that, you can now manually validate both AMD CO and HOC CO values — just head over to the TESTS tab. Another important addition is per-core SMT load monitoring, allowing you to see the utilization of every individual logical thread (double-click on the table with processor metrics).

A more detailed list of changes is provided below.

And we’re not saying goodbye for this month: as previously promised, there will be another interesting update closer to the end of the month.

ONLINE-GUIDE (1.8H) :

LINK

CHANGELOG:

  • Finalized AMD CO diagnostic (auto-tuning) based on SQ AGENT. Updated test sets. Better stability and accuracy. Choosing test sets for some processors.

  • Over 20 minor fixes for SEARCH AMD CO, SEARCH CORE HOC CO, SERACH CCD HOC CO and PROFILE CREATION.

  • Improved stability for HYBRID OC with active MT profile.

  • Added support for multi-monitors with different orientations.

  • Added manual verifications for AMD CO, CORE HOC CO and HOC CO. All 3 mechanisms are available on the TESTS tab.

  • Added monitoring of thread load (T0 and T1) per core. To select monitoring metrics, double-click on the table with processor metrics.

  • HYDRA uses 2.5 times less RAM.

  • Improved overall application stability.

  • Updated some .dll and PresentMon.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

Recommended BIOS options to reduce Zen 5 hard-freezes under overclocking

On many Zen 5 desktop systems, an unstable overclock can result in a complete system freeze with no BSOD, no WHEA error and no automatic reboot.
The BIOS settings below are aimed at:

  • Letting the platform detect serious Data Fabric / SMU faults faster

  • Converting them into a reset or WHEA bugcheck instead of a silent deadlock

  • Disabling some deep power-saving features that can interact badly with high clocks and voltages

These options do not make an unsafe overclock “safe”, but they can make instability easier to catch and debug.

Recommended profile (AMD CBS menu)

  • Platform First Error Handling = Disabled

  • SMU and PSP Debug Mode = Disabled

  • Power Supply Idle Control = Typical Current Idle

  • Disable DF to external downstream IP Sync Flood Propagation = Sync flood enabled

  • Disable DF sync flood propagation = Sync flood enabled

  • Freeze DF module queues on error = Enabled

  • DF Cstates = Disabled

Option-by-option explanation

Platform First Error Handling = Disabled

This option controls who handles certain hardware errors first: the platform firmware (“platform first”) or the operating system.

  • With Platform First enabled, some PCIe / bus / RAS errors may be swallowed or mishandled by firmware, which can sometimes end up as a silent freeze under heavy overclock.

  • With Platform First disabled, more responsibility is pushed to the OS (WHEA on Windows), which tends to result in a visible WHEA error, BSOD, or reboot instead of a complete system lock.

Goal: Prefer a clean bugcheck or reset over a system that simply stops responding with no logs.

SMU and PSP Debug Mode = Disabled

This controls internal debug features of the SMU (System Management Unit) and PSP (Platform Security Processor).

  • Debug modes are useful for internal bring-up and validation, but they can change how asserts and internal errors are handled.

  • For daily overclocking, you want the standard, production error-handling path.

Goal: Make sure SMU/PSP behave like a retail system and do not interfere with normal watchdog / reset behavior during instability.

Power Supply Idle Control = Typical Current Idle

This setting affects how aggressively the CPU drops to very low current states at idle.

  • Low Current Idle can save a bit of power but is known to cause random lockups on some PSUs, especially when the CPU is heavily overclocked and rapidly jumping between idle and boost.

  • Typical Current Idle keeps the rails under a more stable load and avoids edge cases where the PSU briefly misbehaves at extremely low current.

Goal: Reduce random “black screen / freeze at idle or light load” that is actually a PSU + deep C-state interaction.

Disable DF to external downstream IP Sync Flood Propagation = Sync flood enabled

This controls whether a fatal Data Fabric error is propagated as a sync flood to external downstream blocks (for example, I/O IPs).

  • Setting “Sync flood enabled” means we allow catastrophic DF errors to propagate and trigger a global error condition.

  • Instead of some parts of the chip continuing to run on corrupt state, the platform treats it as fatal and can reset.

Goal: Make serious DF errors produce a hard, global fault that the system can actually respond to.

Disable DF sync flood propagation = Sync flood enabled

Similar idea, but for internal propagation of sync flood inside the Data Fabric.

  • “Sync flood enabled” tells the fabric to propagate that fatal condition through the whole internal network.

  • This again favors a deterministic reset / bugcheck over a stuck or partially-dead system.

Goal: If something goes catastrophically wrong in the fabric at high clocks, it should bring the whole system down cleanly, not leave it frozen.

Freeze DF module queues on error = Enabled

This option controls what happens to outstanding traffic in the Data Fabric once an error is detected.

  • With Freeze on error enabled, DF will stop its internal queues when a serious error is seen.

  • That increases the chances that the error-handling path (including sync flood and machine check) actually completes instead of getting lost in a storm of in-flight transactions.

Goal: Make sure DF error handling can run to completion and trigger a reset instead of hanging mid-way.

DF Cstates = Disabled

DF C-states are deep power-saving states for the Data Fabric itself.

  • At high fabric clocks (FCLK) and aggressive overclocks, entering and leaving deep DF power states can become a corner case.

  • Disabling DF C-states keeps the fabric fully awake and responsive, trading a bit of idle power for more predictable behavior.

Goal: Keep the Infinity Fabric in a stable, always-on mode during overclocking to reduce random, hard-to-reproduce lockups.

When to use these settings

  • You are overclocking a Zen 5 desktop CPU and see hard-freezes under load or at idle, with no WHEA logs and no automatic reboot.

  • You prefer a WHEA error / BSOD / reboot over a frozen system that forces a manual power-cycle.

  • You are okay with slightly higher idle power and temperature in exchange for cleaner error behavior.

Important notes

  • These options do not guarantee stability. If your voltage, clocks or memory timings are too aggressive, the system will still crash.

  • They simply increase the chance that an unstable configuration will fail in a visible, debuggable way instead of a silent hang.

  • Always combine these settings with proper stability testing (stress tests, real-world workloads) and keep in mind that every CPU and board is different.

View Post

HYDRA 2.0E PRO (build 2040) - RELEASED!

Hello super community!

This update has been in development for several months and introduces the long-awaited AMD Curve Optimizer auto-tuning powered by the SQ AGENT algorithm. A few important notes:

  1. Expect different results. AMD CO outcomes will look radically different from what you’ve seen before. The optimizer targets overall performance and energy efficiency rather than “the most negative per-core CO.”

  2. No time wasted on non-critical cores. SQ AGENT skips cores that don’t move the needle. If a core cannot improve performance or efficiency, the algorithm doesn’t search AMD CO for it.

  3. Diagnostics may take longer on some CPUs. Despite 24/7 bench operation, we haven’t covered every processor. On certain models (e.g., 9950X3D and 9900X3D), diagnostics may take longer than ideal.

  4. Build 2040 is not final. Several innovations aren’t included yet. Expect builds 2041 and 2042 over the next two weeks.

  5. About “stability.” There will always be a stress test capable of declaring a system unstable—even at AMD CO +10. The current presets are tuned for real-world usage and should cover ~90% of typical workloads, which is a significant improvement over previous HYDRA releases.

  6. Modernized search flows. The CORE HOC CO, CCD HOC CO, and PROFILE CREATION algorithms have been updated. Coverage is not exhaustive yet. For this build, please limit experiments to AMD CO search—some unblocked features haven’t been fully validated.

  7. Logs welcome. Please share your logs; I’m actively reviewing them.


ZEN 5 EXAMPLES:

Here’s an example of what AMD CO can look like on a given processor. On CCD 0, the spread between some per-core CO values can approach ~20 steps. This is expected: the new search focuses on the aggregate performance of all cores within a CCD, balancing each core so no weak cores remain.

I call the resulting effect “intersection”—when per-core curves within a CCD converge as closely as possible. Why it matters:

  1. Tighter per-core curves. In every CCD, each core’s curve is brought as close to its neighbors as possible—this convergence is the “intersection.”

  2. Fewer boost overshoots, fewer crashes. Intersection reduces the risk of over-boosting caused by an overestimated CO on any single core.

  3. Better thermal uniformity. With cores aligned, CCD thermals become more even.

  4. Faster, smarter CO search. The raw AMD CO phase on a 9950X now takes ~60–90 minutes without sacrificing accuracy. It also avoids “silly” overestimates on cores that don’t improve real performance.

  5. Maximum multi-threaded throughput. Most importantly, intersection prioritizes overall CCD health, translating into higher multi-thread performance.

It may sound ambitious, but HYDRA is moving fast—and intersection is a big step forward.

ONLINE-GUIDE (1.8H) :

LINK

CHANGELOG:

  • New AMD CO diagnostic (auto-tuning) based on SQ AGENT. New presets. Better stability and accuracy. Data set selector.

  • SEARCH CORE HOC CO, SEARCH CCD HOC CO, and PROFILE CREATION search algorithms have also been modernized.

  • Phoenix/Autoloading has received 3 additional triggers. No gaps in the auto-start process.

  • Autoloading is programmed only for the user who launched HYDRA.

  • Minimization/normalization of the HYDRA window by clicking on the icon in the taskbar.

  • Fixed distortion of the HYDRA window shape if the user forcibly turned off the monitor.

  • Fixed a rare bug where a closed previous instance of HYDRA might not allow a new instance to be launched.

  • Users of NVIDIA PRO graphics cards will be able to use most features without restriction (except for GPU/RTX-TUNER auto-overclocking).

  • Correction of the eCLK description; it is now called BCLK and is supported by any motherboard. Safe range up to 103 MHz.

  • Reduced CPU usage of HYDRA for cases when anti-cheat blocked some functions.

  • Windows Defender loyalty has been slightly improved.

  • Fixed some bugs related to Ycruncher's unpredictable behavior during CPU diagnostics.

  • Improved mathematics for processor statistics. It has become more accurate.

  • Performance comparison and single-threaded clock speed measurement functions using Cinebench have received a number of improvements.

  • The sharpness of a number of UI elements has been improved.

  • If Vulkan Memtest does not work on your system for some reason, this will not invalidate the GPU auto-tuning results.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

HYDRA 2.0D PRO (build 2033) - RELEASED!

I’m pleased to present the final release of HYDRA 2.0D PRO (build 2033). This version carefully incorporates your feedback, resulting in three major patches to the base HYDRA 2.0D PRO (build 2030). It delivers numerous improvements and fixes and—as a bonus—introduces a HOTKEYS system:

  • Ctrl + Alt + F1 = HYBRID OC (ON/OFF)

  • Ctrl + Alt + F2 = AMD PBO2 (ON/OFF)

  • Ctrl + Alt + F3 = RTX/RX/GTX-TUNER (ON/OFF)

  • Ctrl + Alt + F5 = T-CONTROL (ON/OFF)

  • Ctrl + Alt + F6 = OVERLAY (ON/OFF)

  • Ctrl + Alt + F7 = HGCI (ON/OFF)

  • Ctrl + Alt + F8 = HGCI LOGGING (ON/OFF)

This is our most stable release to date, and I strongly recommend upgrading.

ONLINE-GUIDE (1.8H) :

LINK

CHANGELOG:

  • Added HOTKEYS!

  • Added compatibility with the latest AMD chipset drivers on systems with X3D processors. CPPC is correctly identified.

  • Fixed a bug that could prevent the application from working correctly with 5800X3D, 7800X3D, and 9800X3D, which physically have 2CCD.

  • Added support for EPYC processors for the AM5 platform.

  • If the anti-cheat partially blocks HYDRA, all functions except HYBRID OC, eCLK and CPU monitoring will work.

  • A number of improvements to T-CONTROL. Simplified UI, new CCD prioritization modes added for "Preserred CCD's for game". New .dll library.

  • Improved HYDRA stability if the user's motherboard has problems with BCLK/eCLK.

  • Fixed an error when Vulkan Memtest could not be launched during GPU auto-tuning (diagnostic).

  • Fixed a few rare bugs that could affect the stability of GPU auto-tuning (diagnostic).

  • Choosing the HYDRA driver version (global settings tab). The old one will be added for users who need MSR features (MCA/X for CPU auto-tuning (diagnostic) and C6 control).

  • Several fixes for Curve Editor (RTX/GTX-TUNER).

  • Fixed a bug where clicking on the core tile in the SQ BENCH tab set the wrong AMD CO.

  • The game trigger now works correctly with Vulkan and OpenGL applications.

  • The game trigger now only activates when the game is in full-screen mode. This approach eliminates false positives.

  • The game trigger now allows a mode where CORE Usage is set to 0. Analysis of whether it is a game is performed only on PresentMon.

  • The game trigger can now keep game profiles enabled in applications where there is flickering load.

  • Fixed a rare false throttling trigger during NVIDIA graphics card auto-tuning (diagnostic).

  • Fixed a bug that prevented T-CONTROL from working after passing some comparison tests from the TESTS tab.

  • Improvements in the accuracy of PresentMon metrics.

  • NVIDIA Autotuner, added a switch that allows diagnostics to be performed without skipping points with Perf Cap triggering. That is, forced testing of each point on the curve.

  • Fixed a bug where HYDRA consumes a lot of CPU time.

  • Maximum antivirus loyality.

  • eCLK specifically works with fractional numbers on all Windows localizations.

  • Improved support for multiple Nvidia graphics cards simultaneously.

  • Improved cleaning of PresentMon sessions.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

PROJECT HYDRA ROADMAP

View Post

HYDRA 2.0D PRO (build 2031) - RELEASED!

This update is a collection of bug fixes and improvements for HYDRA 2.0D PRO (build 2030).

MORE INFO ABOUT HYDRA 2.0D PRO (build 2030) >> HERE <<.

ONLINE-GUIDE (1.8H) :

LINK

CHANGELOG:

  • Significantly reduced latency when ingesting data from PresentMon.

  • A large set of fixes and enhancements to Radeon and NVIDIA GPU diagnostics, improving process stability and the accuracy of results.

  • Improved stability of RTX-TUNER features for curve and memory tuning.

  • Reworked Radeon graphics driver restart mechanism for greater reliability.

  • HGCI: Improved support for monitors with refresh rates above 240 Hz.

  • Security updates: Windows Defender is now more tolerant of HYDRA, resulting in fewer false positives.

  • Improved support for Intel CPUs and AMD Ryzen APUs.

  • Increased overall stability when interacting with eCLK.

  • Added detailed logging for cases where HYDRA cannot detect RTSS.

  • Fixed an issue where Phoenix could terminate within the first few seconds of a diagnostic run following a system reboot.

  • Improved resource cleanup during emergency/crash shutdowns of HYDRA.

  • Fixed an issue on GTX-series GPUs where fan speed control affected only one of multiple fans.

  • Improved CPPC tag reading function, sometimes finds lost tags due to buggy BIOS or AMD chipset driver.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

HYDRA 2.0D PRO (build 2030) - RELEASED!

Hello everyone, as always, I have something to shock you with :)

I'll start with the most important thing—HYDRA is now compatible with Core Isolation + Secure Boot thanks to a number of security improvements. This has also affected the behavior of anti-cheats—they have become more tolerant.

The next important update is HGCI (HYDRA Game Comfort Index).

Imagine this: you fire up a new game, your FPS counter says “80–120,” but some moments feel sticky or uneven. You turn a few knobs, your FPS changes, but the feel doesn’t. That’s the gap HGCI closes.

HGCI (Hybrid Game Comfort Index) is a single, easy‑to‑read score plus five companion metrics in the overlay—S, R, V, H, F—that describe the feel of your session: how smooth it looks, how fast it responds, how well it matches your display, how much stability margin you have, and whether your framerate is broadly “enough.” Under the hood HGCI observes real frame‑by‑frame timing and display‑time signals (via PresentMon v2) and blends them with your monitor context (refresh rate, VRR range, V‑Sync state) to judge comfort on your setup, not a lab screenshot.

Why HGCI is different

  • Comfort, not just speed. FPS alone can’t predict if a fight feels snappy or if a camera pan looks jitter‑free. HGCI treats pacing, latency, and panel behavior as first‑class citizens.

  • Display‑aware by design. Your screen has rules: VRR bounds, near‑ceiling behavior, V‑Sync trade‑offs. HGCI reads that context so advice is grounded and specific. PresentMon

  • Vendor‑agnostic clarity. We speak the common language of PresentMon v2 metrics and, when possible, read VRR/V‑Sync info through GPU vendor APIs—without tying you to a brand. PresentMon

  • Honest about uncertainty. When certain signals are missing (e.g., input‑to‑photon in a given title), HGCI gracefully fuses what’s available and tells a coherent story instead of guessing wildly.

The Five Overlay Metrics (what they mean and how to lift them)

Think of HGCI as a compass: the overall score points the way, but these five letters tell you why the experience feels the way it does and what to fix first.

1) S — Smoothness (how even the motion looks)

Plain meaning: fewer frame‑time spikes, fewer “micro‑hitches,” nicer camera pans.
Raise S with:

  • A gentle FPS cap just under your monitor’s ceiling or VRR‑max to remove “near‑cap” stutter.

  • VRR over strict V‑Sync when your FPS isn’t rock‑solid at refresh rate.

  • Tidy background activity: close heavy apps, recorders, and extra overlays you don’t need.

  • Right‑sized streaming: if a game hitches while loading assets, trim texture/geometry budgets.
    Example: You’re on a 165 Hz VRR panel and see jitter at 164–165 FPS. Cap at 162 FPS → camera pans look buttery, S climbs.

2) R — Response (how quickly your actions become pixels)

Plain meaning: the feel of input—snappiness in shooters, aim confidence, dodge timing.
Raise R with:

  • Stay inside VRR range (especially for competitive play).

  • Avoid stacked limiters that build extra queues; pick one clean cap strategy.

  • Trim the few heaviest effects (e.g., aggressive RT passes) if they stretch your frame time.

  • Prefer flip‑model fullscreen/borderless over legacy blit paths to reduce compositor delay.
    Example: Mouse feels “syrupy” at 70–90 FPS with V‑Sync. Enable VRR, cap at 88 FPS, and tone down a heavy reflection pass—R jumps; aim feels crisp.

3) V — Display‑Fit & Tearing (are you in your panel’s sweet spot?)

Plain meaning: how well your frame cadence matches the monitor and sync mode, plus tear risk.
Raise V with:

  • Beat VRR‑min by a few FPS to avoid LFC flips and their side‑effects.

  • Don’t ride the ceiling: cap just under VRR‑max or refresh.

  • Pick one story: VRR or V‑Sync—avoid messy overlaps.
    Example: You’re at 46–50 FPS on a 48–165 Hz VRR display. Lower a couple of expensive settings to hold 52–60 FPS—V steadies, tearing risk disappears.

4) H — Headroom (how much safety margin you have)

Plain meaning: resilience to spikes—can your system absorb sudden effects, big fights, heavy weather?
Raise H with:

  • Cut the single longest GPU pass instead of nibbling ten tiny ones.

  • Help the CPU breathe: crowd density, simulation, and mods can nuke headroom.

  • Kill throttling: stable clocks/thermals and sane VRAM usage keep H high.

  • Right‑size your cap: a slightly more conservative cap often buys huge stability.
    Example: In big explosions your frame‑time tail balloons. Dropping shadow resolution one notch and capping 5 FPS lower turns chaotic spikes into tiny ripples—H rises sharply.

5) F — Frame‑Rate Adequacy (is your FPS “enough” for human vision?)

Plain meaning: the “usefulness” of FPS with diminishing returns at very high values.
Raise F with:

  • Aim for meaningful tiers (30→45→60→75→90→120
).

  • Trade a couple of costly settings for 6–8 ms saved per frame; consider upscalers that are stable in your game.

  • Mind CPU limits at high Hz—background tasks and heavy scripts can choke F even when the GPU coasts.
    Example: Jumping from 80 to 120 FPS on a 120–144 Hz panel makes motion clarity pop; HGCI’s F climbs, and your overall label may step up a category.

------------------------------------------------------------------------------------------------------------------

Updated RTSS UI with 6 color skins (main settings tab):

Updated RTX-TUNER tab with new OC features (Core FREQ offset and Rails Overvoltage):

Extended OC range for CURVE EDITOR

(up to 1150mV, if the card's internal limit allows it):

As always, the full list of changes is just below on this page.


ONLINE-GUIDE (1.8H) :

LINK

CHANGELOG (2.0C + 2.0D):

Added

  • New. HYDRA Game Comfort Index (HGCI) in overlay. Logging to a file is also available.

  • Added a system for handling exceptions related to Core Isolation (for future Windows updates and security policy changes).

  • Added a check for available CPPC tags with an attempt to use an alternative source if some tags are missing.

  • Added temporary detailed logging during GPU DIAGNOSTICs.

  • Added new OC features for RTX-TUNER tab.

  • A protection system has been implemented to prevent attempts to use OC on chipsets where it is blocked.

Improved

  • Updated RTX-TUNER UI and extended OC range.

  • GPU DIAGNOSTIC for NVIDIA has received a number of improvements and significant speedup of the process.

  • Improvements to a number of security features; full compatibility with Secure Boot + Core Isolation. Most anti-cheat systems do not react to HYDRA. No impact on performance.

  • RTSS has received color skins and an improved, more comfortable overlay.

  • The Elemental test received an exclusive full-screen mode.

  • Improved reliability of the Phoenix feature.

  • PresentMon has been updated to version 2.4.0 beta. Data retrieval time has been reduced, and the accuracy of key metric calculations has been improved.

  • Improved support for Intel and AMD Ryzen APU processors.

  • Optimization of HYDRA communication with SMU, reduction of processor usage.

Fixed

  • Fixed a critical bug where the application could crash after a forced restart of the NVIDIA driver.

  • Fixed a bug causing voltage to stick on RTX 4090 and RTX 5000 graphics cards during GPU DIAGNOSTIC.

  • Fixed some errors that prevented all resources from being correctly released when closing HYDRA.

  • Fixed a bug where the curve for NVIDIA graphics cards was not applied.

  • Fixed a flickering issue in the Pure test on some systems.

  • The comparative testing mode for RTX 5090 and RTX 4090 graphics cards now correctly displays PPT graphs.

  • A number of minor fixes.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

HGCI (HYDRA Game Comfort Index)

Ever seen 120 FPS
 yet the game still feels off? The motion isn’t quite fluid, aim feels a tad mushy, tiny hitches sneak in here and there.
That’s exactly what HGCI (HYDRA Game Comfort Index) is for. It isn’t “just another number”. HGCI tells you how good the game feels right now—and why: whether motion smoothness is slipping, input response is getting delayed, your FPS clashes with monitor/VRR behavior, the system’s running out of headroom, or your frame rate simply isn’t perceptually high enough.

We distill low‑level telemetry into a single 0–100 comfort score plus five clear components. You get a quick action map: what to turn off, what to dial in, where to cap FPS, whether to lean on VRR, and when to drop VSync. No smoke and mirrors—behind the scenes are real PresentMon signals (frame pacing, display latency, GPU/CPU queuing, flip delay, animation mismatch) and transparent rules you can inspect in the reason log.

Why it matters: average FPS glosses over the moments that break feel—uneven frame pacing, LFC traps in VRR, half‑rate VSync behavior, or hidden GPU queues. HGCI surfaces all of that live in HYDRA’s overlay and—crucially—tells you what to do next.

Who is it for?

Anyone who wants strafes on rails, crosshair that “sticks” exactly where you push it, and a camera that follows your hand without second‑guessing. From esports shooters to sim racing, HGCI shows the shortest path to “this feels perfect.”

What do Early Access Patrons get?

First hands‑on, evolving formulas, a transparent reason log, and a real say in what we improve next. In short, your honest tuning tool—fewer guesses, more confident steps toward a game that not only runs fast, but feels right.

Reading the overlay

The overlay shows six lines: overall score + label, then S, R, V, H, F (each 0–100). A brief “Warm‑up” may appear first while we collect enough live samples for a fair assessment. Labels range from Esports → Smooth → Playable → Compromise → Uncomfortable.

To earn Esports, you need more than a high total: S ≄ 90, R ≄ 100, V ≄ 100, and FPS must be at or above VRR‑min (or ≄ ~90% of your monitor Hz if VRR is off). No accidental badges — only truly elite conditions.

The five components (and what to do)

S — Smoothness. Captures 95th/99th percentiles, jitter, stdev, and AnimationError (animation out of sync with render). High S = fluid motion without micro‑stutter. Fix: stabilize frame pacing (cap into VRR range, reduce spiky effects/CPU load).

R — Response. Reflects end‑to‑end feel: uses DisplayLatency when available, adds GPU queue/FlipDelay, accounts for VSync/VRR mode, and even infers Frame Generation side‑effects when screen FPS overshoots present FPS. Fix: disable VSync, lock into VRR range (avoid LFC), trim heavy rendering, reconsider FG.

V — Display‑fit. Checks how your FPS matches monitor Hz: VRR in‑range, LFC risk, near‑cap behavior, density vs Hz, and tearing likelihood with VSync off. Fix: enable VRR, set a smart cap for your VRR window, or use VSync if needed.

H — Headroom. Your safety margin before hitching: looks at the tail (P99–P95), stability, GPU busy/wait balance, and queuing pressure. Fix: shave costly settings, balance CPU/GPU, smooth workload spikes.

F — Frame‑rate adequacy. A perceptual usefulness curve for FPS: 60 feels good, 90 feels great, 120–144 is near‑peak. Independent of Hz — it’s about what your eyes feel.

Total HGCI is a balanced blend — roughly S 25% + R 25% + V 20% + H 10% + F 20% — so cranking raw FPS without stability or display harmony won’t top the chart. That’s exactly how real comfort works.

Transparency: reason logging

For power users, HGCI can emit a reason NDJSON log: every score comes with the “why” — component breakdowns, VRR/VSync/LFC status, percentiles, jitter, GPU queuing and more. Great for comparing builds and sharing reproducible reports.

When?

The middle of next week.

View Post

HYDRA 2.0B PRO - RELEASED! (BIG UPDATE)

Hello everyone!

Introducing update 2.0B — our largest engineering push this year. It delivers a record volume of new and rewritten code, on par with the total of previous monthly releases. You’ll get the features you’ve been waiting for, plus broad gains in reliability and speed. Core systems were refactored for lower overhead and faster response, and key algorithms were redesigned to run smarter and more efficiently.

Presentations of key innovations can be found here:

Another bonus is significantly updated diagnostics for NVIDIA graphics cards, which, in addition to auto-overclocking, now informs the user about the results and shares tips.

Core VID locking and new sensors are available in RTSS and monitoring.

The tool for creating the ideal curve has also been updated.

As always, the full list of changes is just below on this page.


ONLINE-GUIDE (1.8H) :

LINK

CHANGELOG:

Added

  • SQ AGENT — CPU benchmark and co‑pilot for PBO2 and per‑core Curve Optimizer, focused on maintaining balance within CCDs (TESTS tab).

  • Core VID Lock (NVIDIA) — manually pin the GPU core’s operating VID, mirroring manual overclocking behavior (RTX‑TUNER tab).

  • Experimental Memory Stability Test (NVIDIA) — new stress path for diagnosing memory stability on NVIDIA GPUs (AMD support planned for the next update).

  • Post‑diagnostic summary (NVIDIA) — after auto‑tuning, HYDRA now provides a detailed analysis of the generated curve with actionable recommendations.

  • New RTSS/monitoring sensors (NVIDIA) — added throttling cause and memory controller load.

  • User Profiles (HYBRID OC) — expanded options; everything enthusiasts need in one place.

Improved

  • NVIDIA diagnostic (auto‑tuner) — redesigned for faster runs and higher accuracy.

  • NVIDIA Curve Editor — revamped tool for precise, easy adjustment of the core frequency/voltage curve.

  • HYBRID OC UI — refreshed for clearer visuals and simpler workflows.

  • Resource usage — lower CPU overhead; PresentMon integration now consumes less processor time.

  • Window state handling — more reliable behavior for tray and minimization.

  • Updated libraries — overall stability and fault tolerance improved.

  • Localization compatibility — better support on systems with non‑English OS locales.

  • CPU support — improved handling of processors with disabled CCDs.

  • HYBRID OC custom profiles — consolidated into a single storage file.

  • Profile creation (HYBRID OC) — hardened algorithm; in edge cases profiles are created with a logged warning.

  • AMD GPU diagnostics — improved stability.

  • Conflict Check module — updated logic and messaging (LOGGING tab).

  • CPU diagnostics — minor enhancements and additional anti‑loop safeguards.

  • Driver‑crash resilience — when the graphics driver crashes, HYDRA now restores the Windows Performance Counters used by several features.

Fixed

  • Graphics tests — corrected wrong resolution selection for the Elemental and Pure tests on systems using custom display scaling.

  • Miscellaneous — numerous minor bug fixes and text/tooltip updates.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

HYDRA PROJECT ROADMAP

HYDRA 2.0B PRO - 23.08.2025

  • SQ AGENT — friendly co‑pilot for PBO & per‑core CO tuning that focuses on balance inside CCDs.

  • Extended USER PROFILES for HYBRID OC — PBO limits, manual freq/voltage, per‑CCD boosts, choosing cores for a boost, eCLK, time windows,            and soft core affinity, all in a single place and driven by your process list.

  • Improved HYBRID OC UI for more comfortable and simplified control.

  • Reduction in processor time usage by the application.

  • Improved support for different language localizations of Windows.

  • Automatic restoration of corrupted Windows Performance Counters.

  • Updating a number of libraries to improve application stability.

  • Support for a number of processors has been improved. In particular, versions with one CCD disabled.

  • Various bug fixes.

HYDRA 2.0C PRO - MID OF SEPTEMBER

  • Interim build with fixes for bugs found in version HYDRA 2.0B PRO.

  • Adjustment of coefficients for SQ AGENT.

HYDRA 2.0D PRO - END OF SEPTEMBER

  • Updated MEM BENCH — improved UI, more useful metrics that tell you about the quality of timing settings for gaming applications.

  • Automatic reading of SPD DRAM.

  • An alternative version of AMD CO search based on the work of SQ AGENT.

  • Improvement of automatic GPU tuning(diagnostic) algorithms.

  • Addition of a conveyor and IPC status profiler.


In fact, there are many more new features coming. In my presentation, I only mentioned those that are already in the early testing phase and are showing results that I am proud to present to you.

The fall will be very exciting and interesting, so stay tuned! :)

View Post

New extended USER PROFILES for HYBRID OC!

Today I’m shipping something HYDRA never had before: four fully user‑defined overclocking profiles for HYBRID OC, switching live to match what you’re running.
Names are straightforward — USER#1, USER#2, USER#3, USER#4 — but the control they provide is anything but basic: PBO limits, manual freq/voltage, per‑CCD boosts, choosing cores for a boost, eCLK, time windows, and soft core affinity, all in a single place and driven by your process list.

Launch Cinebench and one set of rules kicks in; start 3DMark or a game and another profile takes over — no reboots, no service restarts, no drama.

What a profile contains ?

Each of the four profiles is a scenario that becomes active when HYDRA detects your chosen processes:

  • Process list — 1 to 9 executables that should trigger the profile.

  • Control mode:

    • H / PBO ON → manual frequency & voltage control.

    • H / PBO OFF → PBO2 limits mode.

  • AMD PBO2 limits (PPT/TDC/EDC) when you prefer limit‑driven behavior.

  • eCLK (BCLK‑like, if your board supports it) for fine frequency granularity.

  • Active time window — “from → to”; disable it if you want the profile 24/7.

  • Per‑core selection (and SMT) for boosting — choose exactly where the work lands.

  • Force affinity mask — enforces “soft” affinity so the selected boost cores stay isolated.

  • Per‑CCD target boost frequencies — tailor multi‑CCD parts precisely.

  • Voltage (VID) — set realistic ceilings without vendor “autoboost” constraints.

UI logic: parameters that are in effect are white/colored; unused ones are grayed out. VID column uses a color accent for understand what range you are in (green - safe, red - requires attention).

Live switching engine

HYBRID OC includes a real‑time process analyzer. It constantly matches what’s running against what you defined in the profiles. On match, the profile activates instantly. This gives you context‑aware overclocking instead of one‑size‑fits‑all boosting.

Why it matters?

  1. Soft affinity & isolation.
    Boost cores are cleanly separated; stability remains high because we guide Windows rather than fight it. The target frequency will only be on selected cores, while cores that are not selected will have a reduced frequency of 1000 - 2000 MHz.

  2. No “autoboost ceiling.”
    Your frequencies and voltages define the envelope — not marketing presets.

  3. All the knobs, one place.
    PBO limits, eCLK, timer, affinity mask, per‑CCD manual frequency, manual VID — combined. You won’t find this blend elsewhere.

  4. Everyday simplicity.
    HYDRA can auto‑start with Windows and auto‑enable HYBRID OC. You focus on the workload; profiles switch themselves.

Use‑case sketches

  • USER#1 — Bench: Cinebench/3DMark, aggressive per‑CCD boosts, tight VID, Force affinity mask for reproducibility.

  • USER#2 — Game: multiple game EXEs, slightly relaxed VID, best‑latency CCD prioritized, partial SMT.

  • USER#3 — Render/Compile: PBO2‑driven, SMT everywhere, eCLK +0.5% (if available), long time window.

  • USER#4 — Night/Background: strict timer (e.g., 23:00–07:00), low limits for silence and efficiency.

My example

My goal is to run a lightly‑threaded benchmark on the best cores I’ve selected, effectively bypassing the factory CPPC “preferred cores” ranking.

I opted for manual control of voltage and frequency (the checkbox in the H / PBO column is enabled). I set the voltage to 1350 mV, and configured frequencies of 5750 MHz and 4200 MHz for the first and second CCD, respectively. I didn’t touch any PBO settings—they’re greyed out, which means they don’t participate in this profile.

By clicking the status button labeled USER#1, I opened the advanced settings. There, I:

  • Selected the specific processes of interest from the list.

  • Specified in the table which cores must run at the fixed frequency set on the previous tab.

  • Disabled SMT for those cores.

  • Forced application of the CPU affinity mask for the chosen processes.

  • I left the timer at its default (00:00 - 00:00)—Always On.

The final step was to activate the profile by pressing the Activate button on the bottom bar, next to OK and Cancel.



View Post

HYDRA SQ AGENT — benchmark assistant for PBO2 and CO tuning!

What if a benchmark could tell you exactly which cores to nudge and by how much? That’s the idea behind SQ Agent. It’s a friendly co‑pilot for PBO2 & per‑core CO tuning that focuses on balance inside CCDs, not just raw thermals or max watts.

Run it once and, in about a minute, you get a clear picture of how your sample behaves under an all‑core load — where the VF curves converge, where they drift apart, and which knobs to turn next.

  • One click, one glance, one verdict. A global CPU score and CCD scorecards show whether the current tune is better or worse. Does your friend have the same processor? Check who has configured their processor better.

  • Actionable color map. Red tiles mean a core is already riding above the pack (CO likely saturated); blue tiles hint it wants a more negative CO.

  • No stress to your hardware. Safe warm‑up to steady state and a short measurement window make it gentle for modest coolers and VRM.

Why misalignment is bad (and why CCD frequency drops):

  • Shared voltage & limits. In an all‑core load the SMU must pick a common VID and keep PPT/EDC/temperature in check. The worst core (the one needing more V for the same f) dictates the VID or forces a lower f for the whole CCD.

  • Hotspots. A few hot cores raise ΔT inside the CCD. Thermal/FIT guards react earlier, so the CCD loses frequency sooner.

  • Efficiency loss. If VID is set by a weak core, other cores are effectively over‑volted for that moment — more watts for the same work, lower MHz/W, lower total score.

  • Stability & jitter. The SMU keeps chasing limits, so frequency/voltage wobble grows — you feel it as small dips or micro‑stutter.

Aligning VF curves lets the CCD run a higher, steadier all‑core frequency at safer voltages and power.

What it measures

  • Thermal, voltage and frequency consistency per CCD. The agent looks for VF‑curve convergence across cores during an all‑core workload.

  • Two levels of results. A global CPU Total score and individual CCD scores show overall health and where misalignment lives.

  • CPPC awareness. It reports how CPPC ranks match the actual per‑core performance under load.

  • Safe for weak coolers or VRMs. The run uses moderate y‑cruncher load, a dynamic warm‑up until dT/dt ≈ 0, and a short 30s measurement window.

  • Focuses on the AMD PBO2 tab. The score reacts exactly to PPT/EDC/TDC/THM/Fmax/eCLK and to your per‑core CO values.

Note: global scores correlate within the same CPU architecture. Do not compare Zen 3 with Zen 5 one‑to‑one; a cross‑gen preset will arrive later.

Color map: where to tighten CO

Each core’s tile is tinted by ΔEF/1V (its effective frequency per volt vs the median of its CCD). Red means the core’s VF curve sits notably above its siblings — CO is likely already saturated here. Blue means the core underperforms per volt and usually benefits from a more negative CO. Neutral gray means curves are aligned well.

Real examples : Ryzen 9 7950X — default

Under a 194 W all‑core load the agent finds very strong CPPC alignment (ρ≈0.877 → 93.9)* but a clear CCD imbalance: CCD0 ΔT ≈ 8.9°C (score 80.8) vs CCD1 ΔT ≈ 14.0°C (score 71.1). Core #10 reaches 75.2°C while others run cooler — a sign of uneven paste/contact or even a potential RMA case.

* Detailed statistics can be found in the LOGGING tab.

Real examples : Ryzen 9 9950X — before vs after tuning

Default: the CPU is hard (PPT limit ≈ 99.9%) and CCD0 shows poor VID uniformity; Overal Score ≈ 77.5. Tuned (CO + PBO2): frequency stability improves (CV 0.27% → 0.05%)*, efficiency rises (412.6 → 448.0 MHz/W)*, PPT limiting disappears (6.7% of time), and Overal Score climbs to 87. Some cores still need light CO rebalancing, which the color map highlights.

* Detailed statistics can be found in the LOGGING tab.

Release date: end of next week.

View Post

HYDRA 2.0A PRO - RELEASED!

Hello everyone!

This update is dedicated to a new level of stability for all HYDRA functions, higher-quality CPU testing, and the resolution of very rare but painful bugs.



A monumental effort has been made to create entirely new configuration files that determine which tests will be used in CPU diagnostics—ensuring they are effective at uncovering errors without halting diagnostics due to high temperatures on systems with limited cooling. This forms the foundation for the stable operation of both HYBRID OC and standard AMD PBO2. There is, however, a downside: for example, my 7950X is stable on the first CCD only with positive AMD CO. In other words, users accustomed to seeing astronomical AMD CO values may no longer see them after this update. The real benefit, though, is overall system stability.

The next focus of my work was the revamped PROFILE CREATION mechanism—designed to increase the percentage of users for whom HYBRID OC proves useful. A serious emphasis has been placed on the stable operation of HYDRA and the entire system under high-intensity loads. On a five-point scale, where previously I’d rate profile readiness at about 3.5, I would now rate it between 4.2 and 4.5. Naturally, this may slightly affect the frequencies you observe compared to the last build (they might be a bit lower—or maybe not), but you’re still free to tweak HOC CO manually to adjust your final boost.

The third area of improvement was the HYBRID OC algorithms themselves. We’ve enhanced the transition to the IDLE state, improved the maintenance of the core group ready to boost under light-threaded loads (the LT profile), and increased flexibility by exposing individual settings—such as “Max CORES for LT profile” and “Extra boost for MT profile”—for finer control.

CPU/GPU PROFILE COMPATIBILITY WITH THE PREVIOUS VERSION?

  1. IT IS RECOMMENDED TO RUN THE CPU DIAGNOSTICS AGAIN

  2. ALWAYS LOAD PROFILES INTO HYDRA USING THE IMPORT BUTTON

ONLINE-GUIDE (1.8H) :

LINK

CHANGELOG:

  • Improved "AUTO ODT" for DDR5 diagnostics (auto-tuning).

  • Updated configuration files for CPU diagnostics responsible for test selection. Zen 4 X3D is still in the process of being updated.

  • Updated presets for CPU diagnostics, with particular attention to systems with weak cooling (preventing diagnostics from stopping due to high temperature).

  • Fixed a rare bug causing CPU diagnostics to loop indefinitely.

  • Fixed a rare bug that made "Phoenix" believe CPU diagnostic files were lost or corrupted.

  • Improved flexibility of CPU diagnostics: now "CORE HOC CO" and "CCD HOC CO" searches have individual control over maximum allowable temperatures.

  • Unlocked frequency and voltage limits for "HYBRID OC".

  • Several algorithm improvements for "HYBRID OC", enhancing stability and performance.

  • "HYBRID OC" received new settings: "Max CORES for LT profile" and "Extra boost for MT profile" (global settings tab).

  • Fixed a bug that incorrectly set AMD PBO values in CPU diagnostics when the user used the pause button or system sleep.

  • Fixed errors and updated configuration settings for "PROFILE CREATION" (CPU diagnostics). In particular, the "GAME" profile is now created correctly.

  • For easier evaluation of CPU diagnostic test efficiency, introduced encoding for test names. Some additional information has been added to the log.

  • Fixed an error where HYDRA could report that the processor is not supported and crash—for example, with Ryzen APU G8000 processors.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

HYDRA 1.9G PRO - RELEASED!

Hello everyone!

I want to congratulate you, HYDRA 1.9G PRO is one step away from HYDRA 2.0(!!!). This update continues to build on the improvements and fixes for the updated "HYBRID OC" and "T-CONTROL" that I introduced last month. For example, among the tangible innovations in "HYBRID OC" is a dianmic VID for "GAME" and "MT" profiles (range of +-125mV). Improved “HYBRID OC” stability problem fixing assistant (after crash system). Also "HYDRA ASSISTANT" is able to notify what can be wrong when creating profiles (look in the log).

"T-CONTROL" now knows how to fight anti-cheats that try to tie the game to CPU cores in their own way. Also added an API switch that can help with situations when a process refuses to accept a new mask. Turning off the "New mask API" will force the process to be bound to the required cores (you didn't hear that, it's the old API that can do this).

Added support for updated PresentMon 2.3.1 and added new performance metrics such as: FPS-Present (measures how often frames are presented to the GPU), FPS-Display (captures the rate at which frames are actually shown on screen), and CCD Usage(%).

Improved HYDRA interaction with RTSS and updated some CPU diagnostic presets (overall readiness in the neighborhood of 75%).

And of course, as always, a batch of bug fixes.

CPU/GPU PROFILE COMPATIBILITY WITH THE PREVIOUS VERSION?

IT IS RECOMMENDED TO RUN THE CPU DIAGNOSTICS AGAIN

ONLINE-GUIDE (1.8H) :

LINK

CHANGELOG:

  • *A series of improvements for "HYBRID OC" that significantly enhance stability and performance.

  • The "GAME" and "MT" profiles in "HYBRID OC" now feature a redesigned dynamic VID mechanism with an expanded range (it’s working again).

  • The "IDLE" profile parameters for "HYBRID OC" have been adjusted for greater stability and lower temperatures.

  • Various enhancements to the "HYDRA ASSISTANT" that appears after a system crash with "HYBRID OC" enabled.

  • Added support for PresentMon 2.3.1, updated the archive, and implemented new sensors: FPS-Present (measures how often frames are presented to the GPU), FPS-Display (captures the rate at which frames are actually shown on screen), and CCD Usage.

  • Several fixes for working with CPU profiles (reset, export and import).

  • "T-CONTROL" now includes an API toggle for applying the mask, improving performance in certain games.

  • Fixed buttons that were intended to open web pages.

  • Updated presets for diagnostics of certain processors.

  • DRAM diagnostics: the ODT-search mode now validates AGESA’s automatic values before iterating through hard-coded settings.

  • Some fixes for HYDRA’s save-location system before shutdown.

  • A set of fixes enabling HYDRA to safely close itself before an initiated system reboot.

  • Improved integration with RTSS.

  • Fixed HYDRA crashes when using an unsupported AMD GPU or one with no installed driver.

  • Refined the PROFILE CREATION mechanism to generate safe profiles for HYBRID OC or log a notification if something prevents it.

  • Other minor enhancements and bug fixes.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

HYDRA 1.9F PRO - RELEASED!

Hello everyone!

It might seem that this update doesn’t contain any headline-grabbing items, but that’s not the case. A tremendous amount of work has gone into updating the core, refactoring, and overhauling nearly all of the most important features you care about in this project. The new framework has reduced resource usage, fixed a number of longstanding painful bugs, and will make it much easier to implement further global features down the road.

In this release, I have completely rewritten "HYBRID OC" from the ground up in order to deliver a significant boost in both stability and performance (which also required a new CPU diagnostics routine). I really love how "HYBRID OC" works now on the Ryzen 7 9800X3D—it delivers a boost well beyond the standard 5225 MHz. At a VID of 1225 mV, I’m getting almost 5600 MHz on nearly all cores, and that’s genuinely awesome. I also really like how this update performs on the older Ryzen 5 7600X. All users with single-CCD processors will notice the difference. As for dual-CCD CPUs, my work isn’t finished yet, so I’m holding off on any bold claims.

I have also tested and refined "T-CONTROL" for gaming so that even the most finicky engines now obey HYDRA’s directives and parallelize tasks exactly as intended. Furthermore, on dual-CCD processors, when a game is running HYDRA will shift background processes onto cores that aren’t running the game, ensuring maximum responsiveness. This update delivers peak comfort and performance in games and shows special consideration for streamers—any streaming service will no longer interfere with gameplay.

This update is the foundation that will form the basis of HYDRA 2.0, which we’ve been working toward for so long.


CPU/GPU PROFILE COMPATIBILITY WITH THE PREVIOUS VERSION?

- TECHNICALLY YES, BUT RECOMMENDED TO RECOGNIZE FROM ZERO

ONLINE-GUIDE (1.8H) :

LINK

CHANGELOG:

  • First version on new kernel (.NET Framework 4.8.1 -> .Net 8.0) with updated versions of all nested libraries (for UI too).

  • "HYBRID OC" has been rewritten from scratch. It offers more performance and stability. I really like how it works on single-CCD processors.

  • "SEARCH CCD HOC CO" has been rewritten from scratch.

  • "SEARCH CORE HOC CO" includes a number of changes that do not affect the testing process itself but do affect the final results.

  • Presets and CPU diagnostic settings have been modified.

  • "PROFILE CREATION" has received a series of fixes and enhancements.

  • Improved application parallelism and reduced CPU usage for its own needs.

  • Improved interaction with RTSS.

  • "T-CONTROL" functionality has been substantially improved, especially for gaming applications. A number of bugs have been fixed.

  • Added logging of critical events when HYDRA crashes.

  • Improved communication with SMU; added SMU cleanup in case a command gets “stuck” in it.

  • Improved function of logging data from processor sensors (located on the "LOGGING" tab, button labeled LOG). Particular attention was paid to the point that HYDRA background work is almost invisible in the log itself.

  • Improved stability of "DEFAULT vs HYBRID OC" and "DEFAULT vs AMD PBO2" tests.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

HYDRA 1.9D PRO - RELEASED!

Hello everyone!


This month has proven to be exceptionally intense and demanding. The reason isn’t just the shelling, but also the wealth of new knowledge that I was desperate to put into this update. Since the project already encompasses so many different areas, I had to devote proper attention to updating HYDRA’s key libraries in order to boost performance (HYDRA now consumes less CPU time), stability, and inter-module communication.

This update introduces new low-level communication technologies with the processor, known as MSR, which allow you to access unique diagnostic metrics (I’ll share more details soon) and gain control over Ryzen-specific developer features and functions—such as MCA (for Zen 5 + MCAX) and frame-time stretching.

We’ve improved several modules (yes, again—progress never stops): game‐detection, HYBRID OC, T-CONTROL, RTSS, and diagnostics.

Perhaps the most visually striking addition in this release is the Game Analyzer, which works alongside RTSS to inform the user how comfortable the frame rate is by analyzing five metrics (Jitter, StdDev, P95 FT, >16.7 ms, and >33.3 ms).

I know it’s not always possible to deliver an update as reliable as I’d like, but I am incredibly grateful for your trust and support. Thank you, and I bow deeply.

CPU/GPU PROFILE COMPATIBILITY WITH THE PREVIOUS VERSION?

- YES, ANY VERSION

ONLINE-GUIDE (1.8H) :

LINK

CHANGELOG:

  • A number of fixes and improvements for "RTSS".

  • There is a new option in the settings ("SETTINGS" tab) called “Rolling window (s)”. It controls the size of the temporary window for which the frame-time metrics are calculated.

  • Low-level optimization of HYDRA to reduce its own CPU usage. Most of the included DLLs have been updated.

  • "HYBRID OC" received several stability-focused improvements. I began modifying it further, but not all changes made it into this release.

  • "HYBRID OC" now includes protection against setting frequencies below the base clock—values can no longer drop under the baseline.

  • CPPC tags are now retrieved via MSR.

  • Various enhancements to the CPU diagnostic algorithm: each cycle now triggers a system reboot, and the verification interval has been significantly adjusted.

  • Added optimized "AMD CO" search presets for the 9950X3D and 9900X3D. "HOC search" is not ready yet.

  • Implemented a dedicated CCD verification test for previously discovered "AMD CO" values("TESTS tab").

  • Added support for "C6" state management on Zen 5.

  • Added an MSR-based check for low-level CPU errors (MCA) during per-core "AMD CO" searches.

  • Added an MSR-based check for frame-time stretching during per-core "AMD CO" searches (e.g. logs now show “STR: 1.300”).

  • Several improvements to the game trigger feature.

  • Enhanced "T-CONTROL" for dual-CCD processors—non-game processes will attempt to run on the unused CCD during gameplay, rather than on the one running the game.

  • Introduced "Game Analyzer", which tracks five key metrics in-game via "RTSS" to inform the user about frame-rate smoothness.

  • Fixed bugs in the comparative tests "DEFAULT vs HYBRID OC" and "DEFAULT vs AMD PBO2".

  • Improved NVIDIA GPU diagnostics—each cycle now runs two tests, prioritizing curve identification first, then VRAM stability.

  • Finally resolved the issue where "eCLK" (if supported by the motherboard) could not be set for CPU diagnostics.

  • Fixed a visual bug where eCLK adjustments could inadvertently affect MEMCLK or UCLK.

  • Enhanced detection of conflicts with other applications ("LOGS" tab).

  • Corrected various typos and description errors. Global refactoring.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

HYDRA 1.9C PRO (RTSS, PresentMon, ADLX and more) - RELEASED!

Hello everyone!


Ladies and gentlemen. This month I have added RTSS (overlay to 3D apps) to HYDRA. Everything works automatically, you don't need to search or run anything manually. The main condition is that you have RTSS installed (standard path), HYDRA will do the rest. In the upper left corner you can see the information overlay.



Information from the processor and video card sensors. Information about enabled technologies and their status. System performance statistics (PresentMon). If for some reason you don't like a lot of information in the overlay - you can turn it off in the global settings.



Other important changes:

  • Improved support for new X3D processors and 9070 graphics cards.

  • Extended VID range for RTX GPUs and X3D CPUs.

  • Added new API ADLX for Radeon RX. Better control, speed and safety.

  • Updated 3D app detector (used for RTSS, T-CONTROL and HYBRID OC).

  • A number of stability improvements for T-CONTROL, RTX-TUNER, RX-TUNER and GPU DIAGNOSTIC.

CPU/GPU PROFILE COMPATIBILITY WITH THE PREVIOUS VERSION?

- YES, ANY VERSION

ONLINE-GUIDE (1.8H) :

LINK

CHANGELOG:

  • Added an informational overlay for 3D applications displaying sensor data, technology status, and performance metrics. RTSS must be installed for it to work.

  • Overlay customization added to global settings.

  • Integrated "PresentMon 2.3.0 for the overlay system and GPU diagnostics.

  • Implemented a live performance stats system for games, operating with a rolling 60-second interval.

  • GPU DIAGNOSTIC" now include an additional algorithm to detect throttling due to over-overclocking.

  • Replaced the legacy "ADL API" with the new "ADLX API" for Radeon RX GPUs. This resolved several issues related to the GPU fan curve and power limits, and improved overall application performance.

  • Improved support for Ryzen 9 9950X3D and Ryzen 9 9900X3D. Compatibility research is ongoing.

  • Improved support for Radeon RX 9070 / XT. Compatibility research is ongoing.

  • Enhanced stability of "T-CONTROL", "RX-TUNER", "RTX-TUNER", and "GPU DIAGNOSTIC".

  • Improved detection of game applications, especially those lacking standard fullscreen modes or using exotic fullscreen implementations.

  • Better detection of certain Radeon RX GPUs.

  • Fixed issues related to minimizing/restoring the window from the tray or taskbar.

  • Fixed a bug where HYDRA would forget the last window position before closing.

  • Removed the GPU monitoring switch. Monitoring now focuses solely on the primary GPU connected to the display.

  • Added a button in global settings to unlock the full VID range for Zen 5 X3D CPUs.

  • Unlocked overclocking range for RTX GPUs up to 1100mV, provided the card’s TDP allows it.

  • Added ECC error counter for diagnosing RTX GPUs (if supported and enabled on the card).

  • Updated several CPU and GPU presets used in the diagnostics module.

  • Disabled certain spammy MSR messages.

  • Fixed an issue preventing the use of APP PACK when located in directories without proper access permissions.

  • Added the ability to select timing types for Radeon "GPU DIAGNOSTIC". Using a non-default option may cause a one-time screen blink.

  • Corrected some of the descriptions.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

HYDRA 1.9B PRO (NEW GPU AUTO-TUNER) - RELEASED!

Hello everyone!

This time I won't bore you with a lengthy explanation of what has been done this month.

There are currently 5 important events:

  • Full support for the new RX 9000 and RTX 5000 graphics cards.

  • A completely new, more refined auto-tuner for all graphics cards: RX 9000, RX 7000, RX 6000, RTX 5000, RTX 4000, RTX 3000, RTX 2000, and GTX 1000. Yes, we evolve every month. In the role of the new graphics test is Elemental, built on UE4. According to the results of my internal research, it loads all domains of the video card and ROP in particular in a more balanced way.

  • I have almost finished a new tutorial, it is currently 90% complete and I will be opening access to it in the coming days. It is located at the old link and is available to everyone.

  • By popular demand – I have added the option for an annual subscription with the maximum DISCOUNT (-20%!!!) that allows you to support on Patreon.

  • Bug fixing.

CPU/GPU PROFILE COMPATIBILITY WITH THE PREVIOUS VERSION?

- YES, ANY VERSION

ONLINE-GUIDE (1.8H) :

LINK

CHANGELOG 1.9A

  • The new manual is 90% complete and will soon be available.

  • Added new "GPU DIAGNOSTIC" (auto-tuning) with a new test called "Elemental".

  • Added full support for RTX 5000.

  • Added full support for RX 9000.

  • Fixed bug when "Windows Performance Counter" could not be used.

  • Fixed bug when the user in "T-CONTROL" incorrectly changed the sequence of best cores, resulting in a "T-CONTROL" crash.

  • Fixed bug when on X3D processors the automatic launch of "Assistant" could cause a HYDRA crash.

  • Improved the stability of "RX-TUNER" and "RTX-RUNER" during video card driver crashes.

  • Fixed bug where values set by the user in the "GPU DIAGNOSTIC CENTER" could be ignored or not saved.

  • "GPU DIAGNOSTIC CENTER" and "EASY DIAGNOSTIC" (GPU) received adjustments to presets.

  • Changed the order of settings for the "FAN curve" on Radeon video cards, now resembling the "Adrenalin" interface.

  • During DRAM benchmarking, the system will not turn off the screen or go to sleep.

  • Removed "RMP" as the proposed presets were often unstable due to the low quality of the video card silicon.

  • The "Phoenix" diagnostics recovery system has received stability improvements.

  • Improved the system for detecting the primary video card in the system.

  • Fixed bug where in "ĐĄPU DIAGNOSTIC" the user-defined "eCLK" value could be ignored.

  • Blocked GTX video card users from running the RTX benchmark due to complete incompatibility of the technologies.

  • Fixed bug where after system sleep with X3D processors, spam log messages were generated indicating that "HYBRID OC" could not be enabled.

  • The step of changing the curve frequency for NVIDIA video cards using the function keys with the up and down icons became 15 instead of 10.

  • Corrected some descriptions and minor bugs.

CHANGELOG 1.9B (HOT FIX FOR 1.9A):

  • A number of fixes and improvements for "GPU DIAGNOSTIC" (auto-tuning). The final version.

  • "T-CONTROL" stability improvement.

  • Improved game application launch detection.

  • Fixes a bug where GPU profile could be completely overwritten even if user selected only MEM diagnostics or only CORE diagnostics .

  • In "GPU DIAGNOSTIC" for NVIDIA graphics cards, an additional RTX test has been added for the verification phase.

  • Elemental tech demo is hidden if the user's screen resolution is smaller than the render resolution.

  • Added exception handling for requests to the processor's MSR (C6, C6 Package and Performance Bias).

  • Other minor adjustments to the application's default settings.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

HYDRA 1.9A PRO (NEW GPU AUTO-TUNER) - RELEASED!

Hello everyone!

This time I won't bore you with a lengthy explanation of what has been done this month.

There are currently 5 important events:

  • Full support for the new RX 9000 and RTX 5000 graphics cards.

  • A completely new, more refined auto-tuner for all graphics cards: RX 9000, RX 7000, RX 6000, RTX 5000, RTX 4000, RTX 3000, RTX 2000, and GTX 1000. Yes, we evolve every month. In the role of the new graphics test is Elemental, built on UE4. According to the results of my internal research, it loads all domains of the video card and ROP in particular in a more balanced way.

  • I have almost finished a new tutorial, it is currently 90% complete and I will be opening access to it in the coming days. It is located at the old link and is available to everyone.

  • By popular demand – I have added the option for an annual subscription with the maximum discount (-20%!!!) that allows you to support on Patreon.

  • Bug fixing.

CPU/GPU PROFILE COMPATIBILITY WITH THE PREVIOUS VERSION?

- YES, ANY VERSION

ONLINE-GUIDE (1.8H) :

LINK

CHANGELOG:

  • The new manual is 90% complete and will soon be available.

  • Added new "GPU DIAGNOSTIC" (auto-tuning) with a new test called "Elemental".

  • Added full support for RTX 5000.

  • Added full support for RX 9000.

  • Fixed bug when "Windows Performance Counter" could not be used.

  • Fixed bug when the user in "T-CONTROL" incorrectly changed the sequence of best cores, resulting in a "T-CONTROL" crash.

  • Fixed bug when on X3D processors the automatic launch of "Assistant" could cause a HYDRA crash.

  • Improved the stability of "RX-TUNER" and "RTX-RUNER" during video card driver crashes.

  • Fixed bug where values set by the user in the "GPU DIAGNOSTIC CENTER" could be ignored or not saved.

  • "GPU DIAGNOSTIC CENTER" and "EASY DIAGNOSTIC" (GPU) received adjustments to presets.

  • Changed the order of settings for the "FAN curve" on Radeon video cards, now resembling the "Adrenalin" interface.

  • During DRAM benchmarking, the system will not turn off the screen or go to sleep.

  • Removed "RMP" as the proposed presets were often unstable due to the low quality of the video card silicon.

  • The "Phoenix" diagnostics recovery system has received stability improvements.

  • Improved the system for detecting the primary video card in the system.

  • Fixed bug where in "ĐĄPU DIAGNOSTIC" the user-defined "eCLK" value could be ignored.

  • Blocked GTX video card users from running the RTX benchmark due to complete incompatibility of the technologies.

  • Fixed bug where after system sleep with X3D processors, spam log messages were generated indicating that "HYBRID OC" could not be enabled.

  • The step of changing the curve frequency for NVIDIA video cards using the function keys with the up and down icons became 15 instead of 10.

  • Corrected some descriptions and minor bugs.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post

NEW HYDRA GUIDE 2.0 ? - YES!

 Ladies and gentlemen, I've started a NEW HYDRA GUIDE 2.0 that will:

  • General information about the features of all HYDRA modules (presentation).

  • Step by step description of interaction with this or that module.

  • TIPS for each module.

  • FAQ for each module.

  • Of course a list of supported devices and a table of contents for quick navigation. Access for everyone (no changes here).

  • Solutions to compatibility and startup problems.

It will take a few weeks and most likely you will see the first part in a week (I want you to figure out for yourself what and why). Your suggestions are welcome in the comments.

View Post

HYDRA 1.8H PRO (BIG UPDATE) - RELEASED!

Hey, everybody! :)
Glad to present the biggest monthly update ever. Thousands of lines of code and hundreds of hours of testing. The list of changes is over 50 items and I'm sure I've forgotten something.

So, let's get started.

1. DRAM diagnostics for DDR5 have significantly evolved. Tables and guidelines have been developed that provide users with starting values for a range of settings. For example, for timings, there is a dependency on the DRAM IC, MT/s, and DRAM VDD. By changing one of these settings, HYDRA offers suggestions on which settings to begin searching for optimal timings. Additionally, HYDRA knows the theoretical limits of the timings based on the currently selected DRAM VDD. By adjusting the MT/s, you can see how the FCLK frequency and Nitro values change. This highly flexible system is designed to simplify the lives of both novice and experienced overclockers.

Never done timing optimization? With HYDRA, it will be simple. Reset the BIOS settings to Auto and disable Context Restore. Then, in the HYDRA main menu, navigate to SCAN (where diagnostics for various system components are located). Select the DRAM IC (the type of chips in your memory), set the desired MT/s, and choose the DRAM VDD. Everything else will be handled automatically.

During the timing optimization process, the system will continuously reboot. This is normal. In case of instability, HYDRA will revert to stable values and continue the optimization process for the next group of timings.

As a result of the procedure, all components of the memory subsystem will undergo undervolting, provided you have not disabled this feature in the diagnostics settings.

2. Have you completed DRAM diagnostics or found a new preset on the forum? Great, then let's test its effectiveness. To do this, I have updated the built-in benchmark called DRAM BENCH (located on the TESTS page of the main menu). Unlike AIDA and other benchmarks we are accustomed to using, the set of tests in DRAM BENCH is capable of assessing real performance, not just theoretical.

Let me give you an example. I had an tweaked EXPO, but I became curious whether performance would change if I further tuned the timings. Running tests in AIDA, I obtained identical latency and bandwidth, which might disappoint anyone. But is that really the case? By benchmarking two presets in HYDRA, I achieved results that were actually surprising.

MemBench demonstrated a 6.75% performance increase, meaning that certain sequences of tasks executed by the processor were faster.

Bandwidth metrics for a single core improved slightly, but the copy value for an entire CCD changed significantly. Will this affect games? Absolutely.

You can also see a substantial change in Random Access Rd/Wr metrics, which will also impact, for example, frame rate smoothness in games. By the way, this is a new benchmark that evaluates the performance of random accesses to DRAM when working with data volumes that exceed the cache memory.

A few words about the interface. In the center of the screen is a graph showing the core's access time to different memory regions, ranging from cache memory to DRAM. For ease of understanding, the regions are separated by different colors. At the top of the page are the current memory settings. At the bottom of the page are the test results. If you see a value filled with color, it means you have entered the comparison mode between the current and selected experiment. If desired, you can scroll through experiments using the up and down arrows. Alternatively, you can simply delete the experiment data by clicking on the trash can icon. It's all quite simple—just give it a try.

3. Another equally interesting test suite introduced in this update is PING PONG. It is designed to evaluate inter-core communication, specifically how quickly a core from one CCD can communicate with a neighboring core or with a core residing on another CCD. This test suite can highlight architectural weaknesses that affect the utilization of all cores under high-intensity workloads or simply the quality of FCLK-CPU overclocking.


The interface is very similar to DRAM BENCH, but in this case, instead of selecting an expert, you can select metrics.

4. A significant amount of time has been spent improving existing modules and functions; you can find the complete list in the changelog. From this list, I would like to highlight that NVIDIA GPU diagnostics have received an improved algorithm that generates curves more accurately. APPE now features multilingual localization, a conflict search function with PCI mutex, and enhanced file storage. Consequently, due to the improved file integrity of Phoenix, diagnostics for any component have become more reliable.

CPU/GPU PROFILE COMPATIBILITY WITH THE PREVIOUS VERSION?

- YES, ANY VERSION

ONLINE-GUIDE (1.6A) :

LINK

CHANGELOG:

* "Check conflict" ("LOGGING" tab) now detects more processes and services blocking the "PCI mutex".
* Experimental support for RTX 5000 series.
* Added "Nitro" control on the "DCFR" page for DDR5.
* Improved the storage system for all types of HYDRA files, including "phoenix".
* Added "Performance Bias" control via Windows (on the "Settings" page).
* HYDRA has removed a number of drivers written by third-party developers (now using only its own).
* CPU diagnostics: "Target VID" does not want to accept the value.
* CPU diagnostics: Fixed a rare bug that could cause a boot loop.
* CPU diagnostics: Some CPU were not allowed to be diagnosed. Fixed.
* GPU diagnostics (NVIDIA): Added a dual "non-RT/RT" test with automatic resolution adaptation to the main screen for more accurate results.
* GPU diagnostics (NVIDIA): Various improvements related to curve building.
* GPU diagnostics (AMD/NVIDIA): Fixed a bug where user changes in "GPU DIAGNOSTIC CENTER" could be ignored.
* CPU and DRAM (DDR5/DDR4) diagnostics: Improved system for pausing/resuming diagnostic processes.
* CPU and DRAM (DDR4/DDR5) diagnostics: Improved recovery of processes from "phoenix" files.
* CPU and DRAM (DDR4/DDR5) diagnostics: Improved failure type detection and "phoenix" branching after different types of failures.
* DRAM (DDR4/DDR5) diagnostics: Added "VT3" test to diagnostics for more accurate results.
* DRAM (DDR4/DDR5) diagnostics: Fixed a bug where diagnostics could end prematurely.
* DRAM (DDR4/DDR5) diagnostics: Fixed a bug where the HCI test completion percentage was displayed incorrectly.
* DRAM (DDR5) diagnostics: Added an automatic tuning option for "ProcODT" and "DramDqDs".
* DRAM (DDR5) diagnostics: Added an undervolting option for "MC VDDIO".
* DRAM (DDR5) diagnostics: Extended "DRAM MT/s" range to 8800 in 1:2 mode and 6800 in 1:1 mode.
* DRAM (DDR5) diagnostics: Extended "MEM VDD" range to 1.55V.
* DRAM (DDR5) diagnostics: Extended "MEM VDDQ" range to 1.45V.
* DRAM (DDR5) diagnostics: Extended "SOC VDDCR" range to 1.3V.
* DRAM (DDR5) diagnostics: Extended "MC VDDIO" range to 1.4V.
* DRAM (DDR5) diagnostics: Extended "CLDO VDDP" range to 1.15V.
* DRAM (DDR5) diagnostics: Added "Nitro" settings (presets for best performance/latency or stability).
* DRAM (DDR5) diagnostics: Added automatic "ODT" search (ProcODT/ProcODT PU and DramDqDs).
* DRAM (DDR5) diagnostics: Automatic adjustment of start timings for any "DRAM MT/s", "MEM VDD", and "DRAM IC" (all dependencies are taken into account).
* DRAM (DDR5) diagnostics: Updated performance tests for each tuning step (optional).
* DRAM (DDR5) diagnostics: A number of bug fixes and start value adjustments.
* DRAM (DDR5) diagnostics: Added new tips.
* DRAM (DDR5) diagnostics: When the user selects "DRAM MT/s", a number of additional settings affecting stability are also changed (HYDRA suggestion).
* DRAM (DDR5) diagnostics: Modified UI for faster selection of new values and settings.
* DRAM (DDR5) diagnostics: Warning system for unsafe voltage use.
* DRAM BENCH: Added infinite history (file-based storage).
* DRAM BENCH: Added timing and configuration information.
* DRAM BENCH: Added the ability to compare settings and results between different experiments (user selects from a dropdown list).
* DRAM BENCH: Added the ability to browse experiment history and delete selected entries.
* DRAM BENCH: Added the "Random Access Rd/Wr" sub-test.
* DRAM BENCH: Added the "CCD DRAM Rd/Wr/Cp" sub-test.
* DRAM BENCH: Adjusted the "MemBench" sub-test starting values for 12-core and 6-core processors.
* Added the "PING PONG" test ("TESTS" page) with various metrics (MIN/MED/AVG/P95/P99/MAX), which measures the real latency of communication between cores.
* "CHECK MY MEM" ("TESTS" page) received an additional "VT3" test for DRAM stability checking.
* "CORE C6" and "PACKAGE C6" settings ("Settings" page) no longer require restarting the application.
* "T-CONTROL" now also manages the C6 state of cores, improving performance and particularly reducing P95/P99 events.
* Added an alternative method for determining CPPC core labels for Zen 3.
* "HYBRID OC" received minor stability improvements.
* Fixed a bug that prevented HYDRA from launching if there were no dGPU in the system aside from iGPU.
* "APPE" now has multilingual support.
* Added support for 4-byte settings in "APPE".
* Other minor fixes, stability improvements, and refactoring.
* "CMD_FAILED 51 0" - you will still see this message, but it will not stop any process.
* CPU monitoring on some systems did not work properly and therefore everything broke down because of it. Fixed.
* Increased the maximum "VID" threshold for the 9800X3D, it is now 1325 for the "LT profile" and 1225 for the "MT profile". The reason for such a strict limitation is that I don't consider AMD's standard limit to be safe.
* Further protects "Profiles Table" from a user attempting to enter a "VID" value that is too high.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK

View Post