onion-mc/phase0/P2-linux-6700k-1080ti.md

Phase 0 — P2: i7-6700K / GTX 1080 Ti (Linux, Docker present)

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

---

Profile

CPU	Intel i7-6700K, 4 cores / 8 threads, 4.0 GHz base / 4.2 GHz turbo (Skylake)
GPU	NVIDIA GTX 1080 Ti, 11 GB VRAM (Pascal)
RAM	16 GB total, ~8 GB occupied by Docker
OS	Linux
Binding constraint	CPU (main thread) + RAM/GC pressure
What this tier tests	CPU-render and RAM/GC ladder steps on a capable GPU
Expected DH answer	On, with the CPU/thread preset lowered — quality preset stays up

The important inversion

This machine's GPU is the second-strongest in the fleet by a wide margin, and 11 GB of VRAM is more than most current mid-range cards. DH's GPU cost is not the problem here. The constraints are a 4C/8T Skylake main thread and a heap that has to fit in roughly 8 GB.

Consequence: for this tier, turn DH's CPU/thread preset down, not its quality preset. That is the opposite lever from the other two machines, and it is the clearest example of why the ladder cannot be a single global ordering.

Standing constraint for this machine

Do not alter Docker or any other running process for the sake of these measurements. Assume the existing load is constant and consistent, and treat it as a fixed property of this test rig.

That changes the guardrail from "abort if RAM is low" to "record the baseline and verify it stayed constant." See Step 3 and Step 9.

---

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, governor moved, or RAM headroom shifted materially → the run is invalid.

---

Step 1 — Preconditions

• Confirm the proprietary NVIDIA driver is in use. nouveau would invalidate both the performance and the measurements.

  ```bash
  nvidia-smi           # must succeed
  glxinfo -B | grep -E 'OpenGL renderer|OpenGL version'
  ```
  

• Confirm the compositor is not forcing vsync. If on X11/KDE, disable compositing for the measurement session; on Wayland, disable any tearing/queueing control.

• Confirm the display resolution and refresh rate, and record them. Resolution is a bigger GPU lever than most mod settings.

Step 2 — GPU power state and throttling

Do this before every session. A GPU that is power-capped or thermally throttled produces numbers that look like mod effects.

# Prefer maximum performance instead of adaptive clocks
nvidia-settings -a '[gpu:0]/GPUPowerMizerMode=1'

# Check for throttle reasons — SW Power Cap / HW Slowdown must be absent
nvidia-smi -q -d PERFORMANCE

Start background logging of VRAM, clocks, power and temperature. Use this exact command on the Windows machine too — identical tooling on both NVIDIA boxes:

mkdir -p ~/mcbench/logs
nvidia-smi --query-gpu=timestamp,memory.used,clocks.sm,clocks.mem,power.draw,temperature.gpu,utilization.gpu \
  --format=csv -l 1 > ~/mcbench/logs/gpu-$(date +%F-%H%M%S).csv &

memory.used is your VRAM series. On this machine it should stay comfortable; it is the control against the 6 GB machine.

Step 3 — Establish the noise floor (do this first)

Because Docker's load is assumed constant rather than eliminated, you must measure the noise before you can interpret any delta. Otherwise you cannot tell a real 3% mod effect from Docker doing something.

• Run the same configuration, same scene, three times, with no changes at all.
• Record p50/p95/p99 spread across those three runs.
• That spread is your detection threshold. Any later measurement smaller than this spread is not evidence.

If the spread is large, Docker's activity is the first suspect. Record it as a known limitation of this rig rather than trying to fix it.

Step 4 — Record the RAM baseline

Do not change the running load — measure and freeze it.

free -h
cat /proc/meminfo | grep -E 'MemAvailable|SwapTotal|SwapFree'

• Record MemAvailable at session start.

• Repeat the reading before and after each block of runs. If it drifts materially, Docker's footprint changed and the runs are not comparable. That is the check that makes the "constant load" assumption falsifiable instead of merely asserted.

• Confirm no swap is being touched during runs:

  ```bash
  grep -E 'pswpin|pswpout' /proc/vmstat     # before and after; both should not move
  ```
  
  Swapping during a run invalidates the p99 frametime numbers outright.
  

Step 5 — CPU governor

The governor is a system setting, not a running process, and pinning it removes DVFS noise on a 4C/8T Skylake. This is the one system-level change recommended on this machine.

sudo cpupower frequency-set -g performance
# or:
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

• Record the governor value before and after, and keep it identical across sessions.
• Revert to your normal governor when the measurement work is done.

Also worth noting for the tier guide, independent of this benchmarking: a mild overclock on this CPU is a larger and cheaper win than most mod tuning. Measure at stock first so the baseline is comparable.

Step 6 — MangoHud

sudo pacman -S --needed mangohud   # or your distro's package

Config lives at ~/.config/MangoHud/MangoHud.conf. Start from the packaged example (pacman -Ql mangohud | grep MangoHud.conf to locate it) rather than a transcription, then set:

output_folder=/home/<user>/mcbench/logs
autostart_log=1
log_duration=30
fps_limit=0
frametime=1
frame_timing=1
# percentiles — confirm the exact key/syntax in the packaged example

Step 7 — Launcher and JVM

Use Prism Launcher (or ATLauncher) and launch from a terminal so the environment is under your control.

Java: 21 — the same JVM build as the other two machines, to avoid a confound.

Wrapper command — Prism → Edit Instance → Settings → Custom Commands → Wrapper command:

mangohud

Fallback if it fails to hook: mangohud --dlsym.

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

-Xmx6G
-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

Heap sizing rule for this machine: -Xmx = min(6 GB, MemAvailable − 2 GB). With ~8 GB available that lands at 6 G; if the baseline reading is lower, lower the heap.

Omit -XX:+AlwaysPreTouch on this machine. It commits the entire heap up front, which is exactly the wrong thing when Docker already holds half the RAM.

Read this before interpreting GC results. Because heap is capped by Docker's footprint, GC pressure on this rig will be higher than on an otherwise identical machine without Docker running. This rig is therefore expected to over-weight the RAM/GC ladder steps and to show worse p99 lows than the same hardware would in the wild. Record it as a property of the rig; do not attribute it to a mod.

Step 8 — 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
• FOV, resolution, fullscreen mode: fixed and recorded

Step 9 — Verification run

• Launch, confirm the MangoHud overlay appears over Minecraft.
• Confirm a CSV lands in ~/mcbench/logs with a frametime column.
• Confirm nvidia-smi logging is producing a CSV.
• Run the Step 3 noise-floor test and record the spread.
• Confirm MemAvailable and swap counters are stable across the three runs.

Step 10 — Per-session checklist

• nvidia-smi works; power mizer set to max performance; no throttle reasons
• nvidia-smi background logging started
• Governor recorded (and pinned to performance if using that policy)
• MemAvailable recorded; swap counters checked
• Compositor vsync disabled
• MangoHud overlay visible, CSV output folder writable
• Noise floor re-established if the session is a new day

Step 11 — Recording sheet

Field	Example
Date / session	2026-09-28-a
Machine	P2-6700K-1080Ti
Config ID	baseline / dh-cpu-preset-low / emf-off / …
Scene	A-base / B-terrain / C-gui
Run #	1 / 2 / 3
CSV file
p50 / p95 / p99 frametime (ms)
1% low FPS
Avg FPS
VRAM peak (MB)
Throttle flag	none / SW Power Cap / HW Slowdown
MemAvailable before / after
Swap delta	must be 0
Notes

---

Machine-specific caveats

• Docker is not removed, so RAM is a live variable that must be monitored, not assumed away. The Step 4 before/after check is what keeps the results honest.
• This rig will over-weight RAM/GC ladder steps relative to identical hardware without Docker. Documented, not corrected.
• Establish the noise floor before interpreting anything. With a constant-but-unknown background load, small deltas are unreadable until you know the spread.
• CPU is the bottleneck, so CPU-side ladder steps are expected to show their largest deltas here — EMF/ETF and Fresh Animations, DH's thread preset, Sound Physics reverb, LambDynamicLights. GPU-side steps may show almost nothing, and that is a real result, not a failed measurement.
• Pascal is a legacy driver branch. Verify the driver is still current before drawing comparisons against newer hardware.
• 11 GB VRAM means this is the fleet's control for "VRAM is not the constraint." Comparing this machine against the 6 GB GTX 1060 isolates GPU/VRAM effects, because both machines share the same 4C/8T CPU class. If a knob you classified as CPU-render diverges between the two, your classification is wrong — that is the taxonomy self-check.