We Tested the Close Discord Stutter Tip. The Pilot Could Not Answer It

I need to correct the way we framed TEST-001. We recorded six real runs, kept the inconvenient outlier, and rejected PresentMon numbers that we could not reconcile. Those choices were honest. The experiment still could not answer the question.

The question concerned stutter. After the PresentMon trace failed validation, we fell back to the benchmark’s rounded Average FPS, minimum, maximum, and “Low 5th” fields. Those fields can describe the benchmark’s own summary, but they cannot show when a frame-time spike happened, how large it was, or whether closing Discord changed the spike pattern.

So the result is not “Discord does not affect stutter.” The result is: this pilot did not give us a valid stutter comparison.

What the benchmark reported

Condition	Run	Average FPS	Low 5th	Minimum FPS	Maximum FPS
Baseline	1	72	64	26	84
Baseline	2	72	64	48	84
Baseline	3	72	64	52	83
Discord closed	1	72	64	45	84
Discord closed	2	72	64	50	84
Discord closed	3	72	63	51	84

The tool displayed 72 FPS for every average. It displayed Low 5th values of 64 / 64 / 64 at baseline and 64 / 64 / 63 with Discord closed. We found no first-party definition for the tool’s “Low 5th” label, so I will not rename it a 5th percentile or a 1% low.

Why I withdrew the conclusion

We lost the metric that matched the question

PresentMon can capture per-frame timing, displayed time, presented time, CPU and GPU work, and dropped frames. Its capture documentation also makes clear that these metrics describe different parts of the frame pipeline.

Our six CSV files produced far more present events per second than the benchmark’s built-in rendered-FPS result. CAP-001 also covered a shorter target-process window. Until we identify the correct swap chain, event type, and frame filter, I cannot turn those rows into trustworthy percentiles or a spike chart.

The correct response was to stop the stutter claim. We did not stop soon enough.

We never established the bottleneck

The test used an RTX 4060 at 1080p High with DLSS at 66%. That setup might have limited the visibility of a CPU-side background-app effect, but we did not record the data needed to call the route CPU-bound or GPU-bound. I will not infer the bottleneck after seeing the result.

TEST-002 must select a route only after a calibration pass shows where CPU and GPU time sit. If the route cannot expose the intervention, the test has no useful sensitivity.

Run order and condition were tangled together

We ran A, A, A, B, B, B: three baseline runs, then three Discord-closed runs. Time, thermal state, cache state, and background activity all moved forward with the condition. The 26 FPS minimum appeared in baseline run 1 and never repeated, but that does not prove shader compilation, warming, or Discord caused it.

A stronger design counterbalances the order in advance. For three pairs, I would use A-B, B-A, A-B or the reverse sequence, with a separate warm-up that never enters the analysis.

The summaries hid the detection limit

The benchmark rounded its displayed values to integers. Three readings of 72 do not prove that the underlying runs matched exactly, and n=3 per condition does not create a useful confidence interval on its own. We set no smallest detectable effect before the run.

Before TEST-002 starts, a calibration pass must estimate normal route variance. Then the preregistration can state the primary metric, run count, exclusion rule, and smallest effect the setup can distinguish.

We tested a weak Discord condition

Discord and its overlay process stayed open during baseline, but we did not record active voice, screen sharing, notifications, or a repeatable overlay interaction. Closing an otherwise quiet client tests the weakest form of the hypothesis.

The next experiment should isolate one Discord feature. Overlay enabled versus disabled is one question. Active voice versus no voice is another. Combining them would return us to the same bundle-of-tweaks problem.

The display path remained an untested suspect

Windows reported 1920 × 1080 at 180 Hz, VRR not supported, and V-Sync off while the benchmark averaged about 72 FPS. That combination deserves a presentation test, but it does not prove the machine stuttered. We never recorded a synchronized visual observation or a validated displayed-frame trace.

I would test the display path separately. Mixing it into the Discord comparison would only create another confounder.

TEST-002 gate

I will not run the next comparison until these items exist in writing:

1. A validated capture path. We must identify the target swap chain and reconcile the frame count with the application or display path.
2. A route with measured sensitivity. A calibration pass must record CPU and GPU timing before we choose the intervention.
3. One Discord feature. The first comparison will isolate overlay state while voice, screen sharing, hardware acceleration, and notifications stay fixed.
4. Counterbalanced order. We will choose the A/B sequence before capture and exclude a documented warm-up.
5. A primary metric and detection threshold. Calibration variance will determine the run count and smallest effect we can distinguish.
6. Published evidence. A future tested label requires the sanitized raw files, analysis code or formulas, exclusions, and hashes to ship with the article.

The only defensible conclusion

TEST-001 remains useful as a pilot because it exposed the weaknesses in our process. It does not support a recommendation to close Discord, keep Discord open, change sync settings, or blame shader compilation.

That is less satisfying than a fix. It is also the result the evidence can carry.

Houcine B. performed TEST-001 and approved its factual record. AI-assisted tools helped audit the design and prepare this correction; Houcine retains final responsibility for the report.

Sources

1. github.com
2. github.com
3. support.microsoft.com

How we work: Performance claims require reproducible test conditions, buying advice distinguishes hands-on testing from research, and prices carry a checked time.

Read our testing standards →