v1.9.2 - remove unreliable random slowdown probe

Removed the random-mode silent-slowdown probe

The experimental silent-slowdown probe that shipped in v1.9.0–v1.9.1 has been removed.

It reported false SLOWDOWN events even on a stable / stock config, through every tuning attempt (threshold 15 %→5 %, persist 1→2→3, a fixed warm-up + trailing-window baseline redesign, and cumulative flag counting). The root cause is physical, not a bug: without a temperature / clock sensor the probe cannot separate a real CO clock-stretch from ordinary thermal / boost-clock variance under irregular --random load, where a clean baseline can't be pinned down. Rather than ship a noisy, untrustworthy signal, it was pulled.

What this means

• --transient --random still works exactly as before — real-world bursty load (random 80–2000 ms phases, utilisation wandering 0→100 %). Only the slowdown probe is gone.
• The --slow-pct / --slow-persist options are removed (they are now ignored if present, so old launchers still run fine).
• Errors under random load are still caught by y-cruncher's own math self-check and WHEA.

The v1.9.0 / v1.9.1 releases remain available below as history.

---

Note: y-cruncher is not bundled (separate license). Extract the whole y-cruncher folder into tools\ — see tools\PUT-Y-CRUNCHER-HERE.txt.

v1.9.1 - fix random slowdown probe false-positives (warm-up + trailing baseline)

Fix: random silent-slowdown probe false-positives on a stable config

--slow-persist 1 (and even 2) could report false SLOWDOWN events on a stable / stock config. Two causes in the original probe, both fixed here:

• Baseline was locked from the cold first probes. Normal clock drift as the core warmed over a long run then read as a "slowdown" — and being sustained, no --slow-persist count could filter it.
• Warm-up was too short. A probe right after a long idle phase sometimes timed a still-ramping core and read slow.

What changed

• Fixed-duration warm-up (~40 ms) before timing — the core is always at full boost when measured.
• Trailing-window baseline — each probe is compared to the median of the recent probe window, not a cold-start value. A slowly-warming core drifts the whole window with it, so steady-state heat is no longer flagged; only an abrupt drop (the clock-stretch signature) is logged.

Honest trade-off

The trailing baseline absorbs a very gradual decline by design — it targets abrupt clock-stretch (the game-stutter signature), not a slow creep. Still cannot separate CO clock-stretch from thermal throttle (no temp sensor).

Defaults unchanged: --slow-pct 5, --slow-persist 3. With this fix, --slow-persist 2 is now clean on a stable config.

---

Note: y-cruncher is not bundled (separate license). Extract the whole y-cruncher folder into tools\ — see tools\PUT-Y-CRUNCHER-HERE.txt.

v1.9.0 - random-mode silent-slowdown probe (clock-stretch detector)

Random-mode silent-slowdown probe

--random mode now detects silent performance degradation (clock stretching / throttling) that the per-run wall-time check could never see — random duty-cycling makes wall-time vary by design.

A fixed-work AVX2-FMA probe runs on the pinned core every ~10 s: it briefly suspends the y-cruncher worker, times a constant-instruction-count kernel (so the time depends only on the core's effective throughput), and flags a SLOWDOWN when the probe runs slower than a baseline locked from the first probes. This is the most game-relevant signal — real gaming load is bursty like --random, and a marginal Curve Optimizer core's failure there is often a silent stutter / FPS drop, not a crash.

New options

• --slow-pct N (default 5) — flag when the probe is ≥ N% slower than baseline.
• --slow-persist N (default 3) — consecutive slow probes required before logging.

Honest limit

With no temperature sensor it cannot separate CO clock-stretching from ordinary thermal throttling, and the isolated probe draws less current than the real AVX-512 load — so it is a degradation indicator, not proof of instability.

Docs

README now leads with a Recommended workflow: per-core single-core 100% (targeted --core N, or a slower full sweep) → always an all-core verification → finally a --random verification.

---

Note: y-cruncher is not bundled (separate license). Extract the whole y-cruncher folder into tools\ — see tools\PUT-Y-CRUNCHER-HERE.txt.

v1.8.0 - single-test launcher (run only VT3, etc.)

What's new in v1.8.0

"Single test" launcher — run only one y-cruncher test (e.g. VT3)

If your CPU crashes reliably on one specific test, you can now skip the rest for faster reproduction. New launcher core-cycler (single test).bat exposes the existing --yc-tests flag:

• Edit TESTS at the top — default VT3 (or e.g. VT3 N63). Valid: BKT BBP SFTv4 SNT SVT FFTv4 NTT63 N63 VSTv3 VT3.
• Edit CORES to pick which core(s) — blank = sweep all.
• The progress tick (~15 s) shows which test is currently running.

From the CLI: ycruncher-monitor.exe --single --yc-tests VT3

No engine changes — this is a convenience launcher over the --yc-tests option that already existed.

Download

Grab Rynez-Stability-Monitor-v1.8.0-win-x64.zip, extract it, then drop your own y-cruncher into tools\.

v1.7.0 - total time-limit mode (--minutes)

What's new in v1.7.0

Total time-limit mode (--minutes N)

You could already bound a run by passes (--cycles) or per-test seconds (--seconds), but not by a simple wall-clock budget. --minutes N auto-stops the whole run cleanly after N minutes:

• The in-progress run is ended and counted as cancelled, not a fault (no false positive).
• The final summary notes the run finished its time window.
• 0 = no limit (default, unchanged behaviour).

Handy for a fixed soak, e.g. a 2-hour pass:

ycruncher-monitor.exe --core 0 --minutes 120        # soak core 0, auto-stop after 2h
ycruncher-monitor.exe --transient --random --minutes 120   # real-world random, 2h
ycruncher-monitor.exe --minutes 120                  # all-core, 2h

Download

Grab Rynez-Stability-Monitor-v1.7.0-win-x64.zip (exe + all launchers + tools\ placeholder, no .NET install needed), extract it, then drop your own y-cruncher into tools\.

v1.6.1 - fix false performance-drop in random mode

v1.6.1 — bugfix

Fixed a false positive in --random mode. The real-world random transient duty-cycles the worker for a random fraction of each run, so wall-time naturally varies run-to-run — a longer run just means more idle stretches that pass, not a fault. The sensor-free silent-slowdown check was comparing each run to the running average and firing a "possible performance drop" message on the naturally-longer random runs.

The slowdown check is now skipped in --random mode (it stays active for steady and fixed-transient runs, where wall-time is consistent and the signal is valid).

No behaviour change to any other mode. Re-download if you use core-cycler (transient random).bat / --random.

v1.6.0 - real-world random transient mode (--random)

What's new in v1.6.0

Real-world random transient mode (--random)

A fixed burst/idle metronome holds a core at one average load — over Task Manager's ~1s sample window the ms-scale cycles average out, so the utilisation graph sits at a flat band and looks nothing like real use.

--random replaces the metronome with random phases: each a random 80–2000 ms stretch at a random 0–100% target load (delivered by fast ~10 ms micro-duty). Because a phase is on the order of the sample window, the reported utilisation actually wanders the full 0→100% range like real-world use — idle stretches (the clock fully drops), full-load stretches, and partial stretches with fast idle→boost edges. A 0%→100% phase boundary is also the deepest possible idle→full-load Vmin step.

It exercises Curve Optimizer faults across many load levels and transition timings in one run instead of betting on a single fixed swing.

• New launcher: core-cycler (transient random).bat (edit CORES, or leave blank to sweep all).
• CLI: ycruncher-monitor.exe --transient --random (optionally --core N). --burst-ms / --idle-ms are ignored in this mode.

⚠️ Needs the Balanced power plan (Minimum processor state ≈ 5%) so the clock can actually drop during the idle stretches.

Download

Grab Rynez-Stability-Monitor-v1.6.0-win-x64.zip (exe + all launchers + tools\ placeholder, no .NET install needed), extract it, then drop your own y-cruncher into tools\ (y-cruncher is not bundled; separate license).

v1.5.0 - core-0 transient launchers (boost-cycling + max-shake)

What's new in v1.5.0

Two ready-made core-0 transient (boost-cycling) launchers — no editing needed:

• core-cycler (core0 transient).bat — transient mode hard-pinned to core 0 (default 5/5 duty).
• core-cycler (core0 max-shake).bat — core 0 tuned for the biggest clock swing (2/3 duty: the deepest idle → full-boost transition, the one that pops Curve Optimizer undervolts).

⚠️ The max-shake / transient swing only works on the Balanced power plan (Minimum processor state ≈ 5%). On High performance / min-state 100% the clock stays pinned high in the idle gap, so there is no idle→boost swing left to stress.

README updated to document both launchers and the Balanced-plan requirement.

Download

Grab Rynez-Stability-Monitor-v1.5.0-win-x64.zip (exe + all launchers + tools\ placeholder, no .NET install needed), extract it, then drop your own y-cruncher into tools\ (see the .txt there — y-cruncher is not bundled; separate license).

v1.4.0 - transient (boost-cycling) single-core mode

New: Transient / boost-cycling single-core mode (--transient)

Steady 100% load holds a core at one operating point. A meaningful class of Curve Optimizer faults on Zen only shows up in the transient regime — the rapid idle→load boost ramps where the requested clock jumps faster than the voltage rail settles. Peak clock matters less than how fast the boost clock swings.

--transient targets that. It runs the single-core pin (so the core boosts to its ceiling) and duty-cycles the worker on top: a high-priority thread suspends the y-cruncher worker for --idle-ms (core drops its clock), then resumes it for --burst-ms (core ramps back to boost), over and over. Suspend/resume is transparent to y-cruncher, so its own math self-check still runs — silent compute errors are still caught; you just also get the boost-swing stress a steady load can't produce.

New launcher: core-cycler (transient boost).bat (edit BURST / IDLE ms, optional CORES).

ycruncher-monitor.exe --transient                                  # sweep every core, boost-cycling
ycruncher-monitor.exe --transient --core 0 --burst-ms 5 --idle-ms 5  # soak one core

Honest limitation

Windows scheduler/timer granularity is ~0.5–2 ms, not sub-millisecond. This cannot reproduce the sub-1 ms boost residency a dedicated Linux tool can. What it honestly is: meaningful boost-cycling that exposes more transient behaviour than steady load, within what Windows timing allows. Use it as a complement to the steady single-core and all-core runs, not a replacement. If the worker child can't be found or suspended, the run falls back to steady single-core load (still a valid test).

---

Download: grab Rynez-Stability-Monitor-v1.4.0-win-x64.zip (exe + launchers + tools\ placeholder; self-contained, no .NET install needed), extract, drop your own y-cruncher into tools\.

v1.3.1 - keep display on / block sleep+screensaver during tests

Keeps the display on and blocks sleep/screensaver during a test — no more editing your power plan or screensaver settings each time.

New: keep-awake during the run (on by default)

While testing, the tool now holds the system awake and the display on, and suppresses the
screensaver, via SetThreadExecutionState — without changing your power plan or screensaver
settings, and it is reverted automatically on exit.

• You can still switch the monitor off physically.
• This also removes the screensaver / display-off / idle-animated-screensaver micro-freeze
  false positives at the source (the case input-gating couldn't catch).
• Opt out with --allow-sleep if you want the system to sleep / screensaver to run.

Combined with the existing input-gating (hitches within ~2 s of keyboard/mouse input are ignored),
you no longer need to disable the screensaver or touch the power plan before each run — just don't
run heavy foreground apps/video during a single-core test.

Download

Rynez-Stability-Monitor-v1.3.1-win-x64.zip — ready-to-use: exe + all five launchers

• a tools\ folder. Self-contained Windows x64, no .NET install required.

Setup (y-cruncher is NOT bundled)

1. Extract the zip.
2. Download the latest y-cruncher from http://www.numberworld.org/y-cruncher/ and extract its WHOLE folder into tools so that both tools\y-cruncher.exe and tools\Binaries\ exist.
3. Run a launcher (auto-requests Administrator).

Overclocking / undervolting is entirely at your own risk. This tool only reports / classifies; it does not change any BIOS setting.