Tachyon v1.2.0

Four additions for render machines, all read-only like before, plus clearer crash and job reports.

A Tachyon-only stop is diagnosed from what happened before it

• When Tachyon stops but the PC keeps running (same boot), only evidence up to the stop counts. Events logged later (an app crashing ten minutes after) go to a separate after_events list ("After the stop · not related") and are never evidence. After a restart, application crashes logged after the stop are set apart the same way; the restart's own reports at the next boot still count.
• No RAM, BIOS, PSU or GPU-overclock causes for a Tachyon-only stop without direct evidence (WHEA hardware errors or GPU driver errors just before): the RAM speed, the BIOS start time and the clock belong to the boot, not to this stop.
• Without a crash of Tachyon (its crash log or a Windows Application Error for tachyon.exe) the verdict is "Tachyon was closed at 21:38. Your PC kept running.", a neutral note, not shown on the main view. A real crash of Tachyon reads "Tachyon crashed at ..."; a GPU driver error just before points to the driver.
• Reports saved by an older version are revised on load with these rules (the 26 Oct 21:38 report, which blamed later CC_Engine_x64.exe crashes and EXPO/BIOS from the earlier boot, now reads "closed, nothing to do").
• New Report::verdict() (what happened, is the PC OK, what to do) and severity() (note / warning / critical).

Layout: verdict first, details on demand

• Crash report: one-sentence verdict, then the top cause as a card with plain words (EXPO/XMP explained) and one action; other causes folded; evidence, peaks and timeline behind one row. Times in their own column, text wrapped (no ellipsis), at most three bullets per block, numbers and units aligned in the peaks grid, colour only for meaning (neutral note, amber warning, red critical). Events after the stop shown apart. Sections give way to "in the export" lines when the screen is short (checked at 100, 125 and 150 % scaling).
• New Job report view (menu "Last marked job report", "Job report ›" on the main view and in History): verdict, the numbers in an aligned grid (GPU, power, VRAM, energy, temperature, power-cap and heat-limit time), the PCIe link in one sentence, VRAM by process with bars (three shown, the rest folded), clock-limit reasons and earlier jobs folded.
• Main view: one type scale (12.5 body, 14 values and verdicts, 9.5 labels), wrapped sentences, the limiter shows its first reason "+N" instead of a cut word, a PCIe link row (neutral when full or saving power at idle, amber when slow), process rows drop whole details that do not fit instead of cutting them. The session timer row gave way to the PCIe link.

Status, comparisons and plain words

• One status scale for every verdict (status.rs): all fine (green dot), worth a look (amber), act now (red), always with its words ("ALL FINE") next to the dot. Crash reports, job reports, the pre-render check, the bottleneck line and the PCIe link use the same mapping.
• Cause shares are percentages only when two or more causes compete (the second has 20 % or more and the top one is under 80 %); otherwise a word: certain, likely or possible. No share bar for a single cause. The voice line follows the same rule.
• The job report compares with the previous run of the same job only (same name, run counters ignored; never a different job): speed, average GPU, VRAM peak, average power and energy as deltas, or "First run, nothing to compare." Also in History and in get_job_reports (vs_previous, compared_with).
• Plain words: "At power limit 55%" (share of the job's time, normal under full load) instead of "power cap 169 s"; "slowed by heat"; clock-limit reasons explained in one sentence each; the PCIe link glossed ("Gen5 x16 (PCIe 5.0, 16 lanes)"). The limiter on the main view says "power limit" in plain text (normal), heat or a power brake in amber.
• The "Tachyon only reads..." note sits behind a small (i) in the evidence.
• Job report: "What held the clocks back" and "Earlier marked jobs" are two folds.
• History lists marked jobs; the automatic GPU session recorded for the same work is dropped (marked job wins, also in get_history and while running). Long names wrap instead of being cut.
• A crash report that says "nothing to do" in its verdict does not repeat it in the card.
• get_process_vram: avg_mb is the average over the time the process was running (running_s), not over the whole window.
• Job reports: the lowest PCIe link counts only readings under load. The idle power-saving link (Gen1/Gen2) just before a job, still read in its first 100 ms samples, made a full-speed job read "Between Gen2 x16 and Gen5 x16" (live test on the RTX 5080, 29 Oct). Reports saved by the 1.2 test builds are revised on load (no degraded event: the lowest under load is the best link).

Fast sampling (100 ms) for the moments before a stop

• A small thread of its own reads the SM and memory clocks, power and power limit, temperature, GPU load, the clock-limit (throttle) reasons and the PCIe link every 100 ms (fast_ms, 50-1000) into a second fixed-size ring next to the flight recorder: blackbox/fast_a.bin / fast_b.bin (TACHYFS1, 40-byte records with a checksum), 15 minutes by default (fast_minutes, 1-60), about 352 KB per session. Written every second, flushed every 5 s, so a power cut loses at most a few seconds. fast_sampling = false turns it off.
• diagnose_crash adds last_seconds: the 30 s before the stop at 100 ms (power against the limit, the biggest one-reading power jump, time at the limit, temperature, SM clock and its biggest drop, each clock-limit reason with how long it was set, the PCIe link, the last reading to the millisecond). Power spikes of +100 W within one reading, power brake, hardware slowdown or a hardware temperature limit become diagnosis.hints.
• Job reports keep the 100 ms peaks (peak power, time at the power limit, clock-limited time) without storing the samples.

PCIe link history

• The link's generation and width against the best this GPU and slot can do (the lower of the GPU's and the system's maximum generation, and the maximum width).
• NVIDIA cards drop to Gen1/Gen2 when idle; that is counted as normal power saving and written now and then. A link narrower than the slot (after 3 s) or below its generation under load (GPU 50%+ for 5 s) is a degraded event, always written, as is the recovery. history/pcie_link.jsonl, rotated at 1 MB.
• get_status.pcie_link, the new MCP tool get_pcie_link (now, the changes of the last days, degraded count), and the bottleneck explainer: an evidence line with the link, and a PCIe verdict says when the link itself runs below its best.

VRAM per process over time

• Every 5 s (proc_vram_secs, 0 = off) the VRAM each process holds. On Windows NVML answers "N/A" for every process under WDDM, so Tachyon reads the per-process dedicated GPU memory Task Manager shows (\GPU Process Memory(*)\Dedicated Usage, pdh.dll from System32, on the adapter whose total matches the NVIDIA card).
• A line goes to history/proc_vram.jsonl when a process changes by 64 MB or more, comes or goes, or at least once a minute (largest 16 above 16 MB; rotated at 4 MB).
• The process list now shows each process's VRAM on Windows too; graphics-only processes are listed from 256 MB (they used to be listed with any known VRAM).
• New MCP tool get_process_vram (minutes, since/until, name, top): peak, time-weighted average and last value per process name, first and last seen, a short timeline for the top five, and the reading now.

Render job markers

• tachyon mark start --job NAME and tachyon mark end --job NAME append one line to markers/markers.jsonl in the data folder and exit (0 written, 1 could not write, 2 wrong arguments; the line is printed to the console it was started from). Nothing else is touched.
• The running Tachyon follows the file and builds a report per job: duration, average and peak GPU load, memory controller load, VRAM at start / peak / end, average and peak power (100 ms), energy (and cost with price_per_kwh), temperature, SM clock range, seconds clock-limited by power and by heat and at the power limit, the clock-limit reasons, the PCIe link at start and end, the lowest under load and degraded events, the processes holding the most VRAM and the most common bottleneck. Jobs started before Tachyon was running are picked up (with covered_s saying how much was recorded); a job with no end marker is closed after 48 h; at most 16 open.
• Reports go to history/marked_jobs.jsonl; get_status.marked_jobs (open, last, notes) and the new read-only MCP tool get_job_reports (n, name). The MCP server stays read-only: it never writes markers.

Measured on the RTX 5080 (Windows 11, 32 threads), whole Tachyon process, companion mode, 60 s windows

• Idle, back to back on the same desktop: 1.1.0 1.35% of one core; 1.2 with fast sampling and per-process VRAM off 1.25%; 1.2 with the defaults 1.67% and 1.22% (two runs), and 1.09% in an earlier run. The run-to-run spread (about ±0.3 points, Windows counts CPU time in 15.6 ms ticks) is larger than what 1.2 adds; the fast thread's own time stayed below one tick per minute. Under GPU load: 1.42%. All of it is 0.03-0.05% of the 32-thread CPU. Working set 5-6 MB; private memory 31.5 MB with the defaults vs 28.3 MB for 1.1.0; one extra thread.
• A marked 60 s GPU job (RIG test render, 1080p CUDA + NVENC): 81% average GPU, 2.3 GB VRAM peak, 247 W average, 262 W peak (100 ms), 4.1 Wh, Gen5 x16 throughout.
• After Tachyon was killed, the fast ring's last reading was 0.35 s before the kill (the 1 s recorder's last sample 4.4 s before).

Build and tests

• 198 tests on Linux and 202 under wine (169 and 172 in 1.1.0): status scale and percentage rule, same-job comparison, marked jobs over automatic sessions, the lowest PCIe link under load only (the real 29 Oct A2 pattern), the fast ring (wrap-around, damaged records, the thread writing and stopping), the last-seconds summary and hints, the link states (idle dance, degraded width and generation, recovery), the per-process VRAM log and summary, the marker CLI and job reports, the three new MCP tools and diagnose_crash with 100 ms data.