onion-mc/phase0/P1-windows-7700k-1060.md

# Phase 0 — P1: i7-7700K / GTX 1060 6 GB (Windows)

Setup and measurement procedure for the VRAM-bound machine in the Onion MC client tuning
fleet.

---

## Profile

| | |
| --- | --- |
| CPU | Intel i7-7700K, 4 cores / 8 threads, 4.2 GHz base (Kaby Lake) |
| GPU | NVIDIA GTX 1060, **6 GB VRAM** (Pascal, GP106) |
| RAM | 32 GB — **not a constraint on this machine** |
| OS | **Windows** (the fleet's only Windows box) |
| **Binding constraint** | **VRAM** |
| **What this tier tests** | GPU/VRAM ladder steps with CPU and RAM held non-binding |
| **Expected DH answer** | **On, with quality/distance reduced — VRAM is the wall** |

### Why this machine matters

- **32 GB of RAM removes RAM/GC as a confound**, so this machine isolates pure GPU and
  VRAM effects. That is where DH's quality preset and CTM/texture fidelity live.
- **Its CPU is the same class as P2** (both 4C/8T ~4.2 GHz). Comparing this machine against
  P2 therefore isolates the GPU/VRAM axis while holding CPU-side mod cost roughly constant.
  That pairing is the fleet's built-in control — see the taxonomy self-check at the end.
- **It is the only Windows machine**, so the OS axis is confounded with the GPU axis here.
  A result that differs from P2 could be the GPU or the driver stack, and this rig cannot
  separate them. Record it as a known limitation.

---

## Shared measurement protocol

Applies to every machine in the fleet. Duplicated here so this document stands alone.

1. **Uncapped, vsync off** during measurement. Apply the FPS cap only *after* tuning.
2. **Metric is p99 frametime and 1% low, not average FPS.**
3. **Discard 10–15 s of warmup** per scene — JIT, chunk load, initial GC.
4. **Settle after any render-distance or DH change.**
5. **Three runs per configuration, report median and spread.**
6. **One variable per run.**
7. Guardrails: FPS limiter active, power plan changed, or GPU throttling → invalid run.

---

## Step 1 — Windows power and background load

```powershell
powercfg /list
powercfg /setactive SCHEME_MIN      # High performance
```

- [ ] Power plan set to **High performance** (or Ultimate Performance) and recorded.
- [ ] No pending Windows Update or reboot.
- [ ] **Xbox Game Bar off:** Settings → Gaming → Xbox Game Bar → Off.
- [ ] **Game DVR / background recording off:** Settings → Gaming → Captures →
      *Record in the background while I'm playing* → Off. This is a real frametime cost.
- [ ] Close browsers, Discord, OneDrive, and any streaming/recording software.
- [ ] **Exclude the instance folder from Windows Defender real-time scanning** to remove
      I/O spikes during chunk loading. Record that you did it.

## Step 2 — GPU settings

**NVIDIA Control Panel → Manage 3D settings → Program Settings → (Prism's `javaw.exe`):**

- [ ] Power management mode → **Prefer maximum performance**
- [ ] Vertical sync → **Off**
- [ ] Low Latency Mode → fixed value, recorded (it changes frame pacing — don't vary it)
- [ ] **Threaded Optimization** → fixed value, recorded (it affects OpenGL apps directly)
- [ ] Texture filtering quality → fixed value, recorded

**Hardware-Accelerated GPU Scheduling (HAGS):** Settings → System → Display → Graphics →
*Change default graphics settings*. Record On/Off and **keep it constant**. HAGS changes
frame pacing and will show up in your p99 numbers.

**Fullscreen:** run Minecraft in the **same display mode every session** (fullscreen at
native resolution, or borderless — pick one). Also disable *Fullscreen optimizations* for
`javaw.exe` (right-click → Properties → Compatibility) so Windows doesn't add compositor
work. Record the choice.

## Step 3 — Confirm GPU state

`nvidia-smi` ships with the NVIDIA driver on Windows too. **Use the identical command as
the Linux machine** so both NVIDIA rigs produce the same CSV schema:

```powershell
& "$env:SystemRoot\System32\nvidia-smi.exe" -q -d PERFORMANCE     # check for throttle reasons
New-Item -ItemType Directory -Force ~\mcbench\logs | Out-Null
& "$env:SystemRoot\System32\nvidia-smi.exe" `
  --query-gpu=timestamp,memory.used,clocks.sm,clocks.mem,power.draw,temperature.gpu,utilization.gpu `
  --format=csv -l 1 > ~\mcbench\logs\gpu-$(Get-Date -f yyyy-MM-dd-HHmmss).csv
```

- [ ] No `SW Power Cap` or `HW Slowdown` in the throttle reasons.
- [ ] `memory.used` logging running. **On a 6 GB card this is your headline metric** —
      peak VRAM tells you when DH, CTM and texture fidelity have crossed the line.

## Step 4 — Measurement tooling: PresentMon

MangoHud does not exist on Windows. Use **PresentMon** (open source, ETW-based, and it
covers OpenGL as well as DX/Vulkan).

**Option A — the Frame Time Analysis package** (simplest; download from
<https://boringboredom.github.io/Frame-Time-Analysis/>). It ships a `Run.bat`:

```bat
pushd %~dp0
cd captures
..\presentmon.exe --multi_csv --no_console_stats --hotkey "F10"
```

Run it **as Administrator** (ETW capture requires elevation), then press **F10** to
start/stop each capture. `--multi_csv` writes a new CSV per capture cycle into `captures/`.

**Option B — target the Minecraft process explicitly** so only MC is captured:

```powershell
presentmon.exe --process_name javaw.exe --output_file ~\mcbench\logs\pm.csv --timed 30
```

- [ ] Confirm the process name. Prism launches Minecraft as **`javaw.exe`**; verify in Task
      Manager rather than assuming.
- [ ] PresentMon emits **two CSVs per capture**: the raw per-frame data and a **stats
      summary that already contains average / min / max / percentile FPS**. Use the summary
      for a quick read and the raw file for the real analysis.
- [ ] Verify a capture produces a CSV with a frametime column before collecting real data.

## Step 5 — Analysis: one tool for the whole fleet

Use **Frame Time Analysis** (<https://boringboredom.github.io/Frame-Time-Analysis/>). It
reads CSV from **PresentMon, CapFrameX, OCAT, MangoHud** and FrameView, all in the browser,
with no upload to a third party.

- [ ] Percentiles, **lows (1% / 0.1%)**, box plots, bar charts and summary tables.
- [ ] **Merge multiple CSV files** — this is what lets you put the three runs of one
      configuration, and the MangoHud CSVs from the Linux machines, side by side on one
      chart.
- [ ] Screenshot export for the record.

This tool is the reason the fleet does not need a custom analyzer: raw capture stays
platform-native (MangoHud on Linux, PresentMon on Windows) and analysis is unified.

## Step 6 — Launcher and JVM

Use **Prism Launcher** and launch from a shell so the environment is under your control.

**Java:** 21 — the **same JVM build as the Linux machines** (Temurin 21 is a good choice for
all three). A different JVM build is a confound.

**JVM arguments** (identical across the fleet except `-Xmx`):

```
-Xmx8G
-XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200
-XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC
-XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M
-XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4
-XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90
-XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32
-XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1
```

32 GB means heap is not a variable here. Keep `-Xmx8G` fixed and spend your attention on
VRAM.

## Step 7 — Pin the in-game settings

Controlled variables — set once, record, do not change between runs unless the run is
testing that setting.

- Graphics: Fancy
- Render distance: 8
- Particles: All
- Clouds: Fancy
- Entity shadows: On
- Biome blend: fixed, recorded
- Mipmap levels: 4
- GUI scale: fixed number
- **Max framerate: Unlimited**
- **VSync: Off** (also off in the NVIDIA panel — check both)
- FOV, resolution, fullscreen mode: fixed and recorded

## Step 8 — Verification run

- [ ] PresentMon capture produces a raw CSV **and** a stats summary CSV.
- [ ] `nvidia-smi` VRAM logging is producing a CSV.
- [ ] MangoHud is not expected here — confirm you are actually capturing through PresentMon.
- [ ] Run the same configuration three times and record the spread. Establish this before
      interpreting anything.
- [ ] Confirm peak VRAM is being recorded — it is the whole point of this machine.

## Step 9 — Per-session checklist

- [ ] Power plan = High performance
- [ ] Game Bar and background recording off
- [ ] Defender exclusion in place
- [ ] NVIDIA power mode = prefer max performance; vsync off; HAGS and Threaded Optimization
      unchanged since last session
- [ ] `nvidia-smi` throttle check clean
- [ ] VRAM logging started
- [ ] PresentMon running as Administrator
- [ ] Display mode and resolution unchanged
- [ ] No pending Windows Update

## Step 10 — Recording sheet

| Field | Example |
| --- | --- |
| Date / session | 2026-09-28-a |
| Machine | P1-7700K-1060 |
| Config ID | baseline / dh-low / ctm-off / emf-off / … |
| Scene | A-base / B-terrain / C-gui |
| Run # | 1 / 2 / 3 |
| CSV file (raw + summary) | |
| p50 / p95 / p99 frametime (ms) | |
| 1% low FPS | |
| Avg FPS | |
| **VRAM peak (MB)** | the headline number for this rig |
| Throttle flag | none / SW Power Cap / HW Slowdown |
| Notes | |

---

## Machine-specific caveats

- **VRAM is the binding constraint, so watch for the cliff, not the slope.** On a 6 GB card
  the failure mode is a sharp p99 regression once DH + CTM + texture fidelity exceed
  capacity — not a smooth FPS decline. Record peak VRAM alongside every result.
- **Two vsync switches exist** (in-game and NVIDIA panel). Verify both are off, every
  session. A single missed vsync makes every configuration look like it hits the target.
- **Beware dynamic clocking.** Verify no throttle reasons before and after a block of runs.
- **This is the only Windows machine, and it is also the weakest GPU** — the OS axis is
  confounded with the GPU axis. A divergence from P2 cannot be attributed to the OS.
- **32 GB makes this the fleet's clean tier for GPU-only effects.** If a knob you classified
  as GPU/VRAM shows a large delta here and almost nothing on P2, the taxonomy is confirmed.
  If a knob you classified as CPU-render diverges between this machine and P2 *in direction*,
  the classification is wrong — both share the same CPU class, so CPU-side effects should
  track closely.
- **Windows measurement is ETW-based** (PresentMon) while Linux is MangoHud-based. The two
  do not measure identically, and the fleet has no same-hardware cross-OS pair, so
  **absolute numbers are not cross-comparable between OSes — only within-OS comparisons
  are.** Derive ladder orderings per OS, then check that the *orderings* agree.