The lag fix everyone copies works. Here's the price your speed test won't show.

A gigabit fiber line can still get an F

Before I changed anything, Waveform's free bufferbloat test gave my 1 Gig fiber connection an F. Sitting idle, it answered in 7 ms. While uploading, the delay went up by 492 ms, almost half a second. Waveform's own verdict: "Calls and games will struggle while anything downloads." The test measures how much extra delay piles up when the line is busy. It is not your ping to a game server.

Turning off Nagle's algorithm did nothing

A one-click "optimize network" button took me from F to C (+492 to +121 ms). One test before and one after isn't proof, so I switched just Nagle's algorithm (and delayed ACKs) on and off for seven more runs, the last after a full reboot. All seven were C. Tweak on averaged +139 ms (Runs 1-3), tweak off +131 ms (Runs 4-6), and the reboot run was the best of all at +87 ms. The run-to-run noise was bigger than any on/off difference. The button changed other settings too, and those stayed on, so this rules out Nagle, not the whole button.

Network card power saving wasn't it either

Resetting my network settings to Windows defaults brought the F straight back (Runs 8 and 10: +503 and +917 ms) and roughly halved my upload speed, from about 436 to about 225 Mbps. That let me put things back one at a time. First suspect: the network card's power saving. I turned off the 4 visible settings, then all 14 values plus a reboot. Four more F's (Runs 11-14, +404 to +606 ms). Run 9 graded A but is invalid; see the run table.

Turning off IPv6 moved it from F to C/D, on my line

The reset had also switched IPv6 back on (it had been switched off on my network card before). I unchecked it again: next test a C, and upload speed back near 400 Mbps. Then I flipped it back and forth. IPv6 on: 9 of 9 F, upload +404 to +917 ms. IPv6 off: 5 of 5 C or D, +129 to +285 ms. The two ranges never overlap. During the flip runs (17-22) a traffic logger confirmed which protocol each test actually used. Microsoft warns against this: "We don't recommend that you disable IPv6 or IPv6 components or unbind IPv6 from interfaces. If you do, some Windows components might not function." It's a non-standard setup, so test it and undo it if it doesn't help.

Source: Microsoft Learn: Configure IPv6 for advanced users

Microsoft's recommended alternative didn't fix it, in Chrome

Microsoft recommends setting Windows to prefer IPv4 instead of switching IPv6 off. I set it and confirmed it took effect after a reboot. Still an F (Run 23, +448 ms). Waveform's test runs against speed.cloudflare.com, which has both IPv4 and IPv6 addresses, and Chrome's connection log showed it connecting over IPv6 (2606:4700:7::da) anyway. Chrome picks its own address and didn't follow the Windows setting. Only one run under this setting is valid (Run 24 stalled), so the log carries this one: it shows why it failed, not just that it did. That traffic log isn't in the downloads below; its readings are summarized here.

Source: Microsoft Learn: Configure IPv6 for advanced users

Disabling TCP auto-tuning: an A in 9 of 9 runs

The fix that kept showing up in the comment sections, in 4 of the 8 I read: netsh int tcp set global autotuninglevel=disabled. I tested it the same way as everything else, alternating, three runs each. Normal: D, C, C (+83 to +201 ms). Disabled: A, A, A (+0 to +9 ms). In those runs Waveform's own download speed didn't drop (852 to 880 Mbps disabled vs. 712 to 791 normal). It swung more in later runs (381 to 836 Mbps disabled), and upload speed varied throughout. Counting every run I did with it disabled, IPv6 on or off: 9 of 9 A.

netsh int tcp set global autotuninglevel=disabled

The "keeps your speed" version, highlyrestricted, did nothing

Some commenters say to use highlyrestricted instead, because it supposedly keeps your speed. Three runs, three C's (+111 to +126 ms), right inside the normal setting's range. No better than doing nothing.

It's not the test being fooled

Waveform grades itself, so I ran my own check during 12 of the runs. A small probe on my PC sent tiny UDP DNS queries and pings to Cloudflare (1.1.1.1, or its IPv6 address with IPv6 on) about 4.5 times a second and timed every one. It goes through the same router queue. During the upload phase with IPv6 off and auto-tuning normal, packets typically picked up +48 to +62 ms, about 1 in 4 (68 of 292) got more than +100, and the worst got stuck for +310 to +435. With it disabled, typically +6 to +11, and out of 408 packets the very worst was +31. With IPv6 on, the worst packets on normal waited +764 to +960 ms, almost a full second; disabled, the worst of 417 was +36. Even the worst packet with the fix beat the typical packet without it, on both IPv6 settings. The typical (median) delay fell by 42 to 51 ms with IPv6 off. That's just under the 50 ms bar I set before testing in 2 of 3 pairs, so on the median alone the honest verdict is "couldn't tell." The spikes, which are what you feel as lag, are the clean result. The table also gives each run's 95th percentile (the 1-in-20 bad packet). Limitation: Cloudflare isn't a game server.

Added delay in ms during the upload phase. p95 = the 1-in-20 bad packet. n = packets timed in that phase.

The price: single-connection downloads get 13 to 21 times slower

One of the videos I watched warns this command limits your bandwidth. I wanted to know which downloads, and by how much. So I downloaded a 100 MB file over a single connection with curl (20-second cap), auto-tuning normal and then disabled, alternating, from servers at three distances. Disabled caps every single-connection download, and the farther away the server, the lower the cap. Every pair repeated almost exactly. The full curl output wasn't saved; the speeds below are from the test log. A Cloudflare server was also tried and refused curl (HTTP 403), so it isn't counted.

Why your speed test doesn't show the price

During one Waveform run I logged Chrome's open connections every half second. The test held 6 to 7 connections at once to speed.cloudflare.com, 13 in total over about a minute. Spread across several connections to a nearby server, a per-connection cap barely shows. A lot of big downloads use just one connection, and that's where you pay.

Do you need both fixes? For lag, no

Every valid run since the network reset, sorted by the two settings (the Nagle-era runs and the prefer-IPv4 and highlyrestricted runs are left out). Auto-tuning disabled alone took an IPv6-on F to an A. IPv6 off still matters when auto-tuning is back on normal: that's the difference between an F and a C or D. What I run now: auto-tuning disabled before I play, normal after, through two desktop shortcuts. Credit to a commenter under another bufferbloat video who suggested exactly this toggle; I just measured whether it's worth it. I don't know why a setting for incoming data fixes upload lag. I tested that it does, and I'm not going to make up a reason.