A router with SQM fixed my lag spikes at gigabit. One setting decides whether it costs half your upload.

The Nest, before: a C, and lag spikes the probe can see

Three runs on the Nest, wired, with IPv6 off and auto-tuning normal: the setup video #1 ended on. All three graded C, with +123 to +183 ms added on upload. My probe's packets during the upload typically picked up +52 to +142 ms, 1 in 20 waited +248 ms or more, and the worst waited +418 ms. Two more runs on the morning of router day (Leg 0) graded C again, with 1 in 20 at +200 and +255 ms. This is what the Flint has to beat.

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

A new router by itself isn't the fix

Stock, with SQM off, the Flint already beat my old Nest: a B instead of a C in all three Leg A runs, with 1 in 20 packets waiting +102 to +133 ms during the upload, against the Nest's +200 to +257. But it still lagged: every stock run had packets waiting an extra hundred milliseconds or more (6 to 11 of them per run). SQM is the fix, and it ships turned off.

First, proof the limit is in charge

Before any counted run, I set SQM to cake at 300 down and 150 up and ran Waveform once. Both speeds landed just under their limits, each in the right direction: 294.7 down and 148.5 up, graded A+. If they hadn't, I'd have stopped and fixed the setup before Leg A.

SQM fixes the lag on my line: +102 to +133 ms down to +1 to +3 ms

Leg A alternated stock and SQM on (cake, 900 down and 900 up), three runs each, on the wired PC. The rule, written on Oct 16 before the first run: every SQM-on run's 1 in 20 under +50 ms, and no SQM-on run overlapping any stock run. Stock graded B, B and B, with 1 in 20 packets waiting +102 to +133 ms during the upload. SQM on graded A, A and A+, with 1 in 20 at +1 to +3 ms and the worst packet at +3 to +10. It passed.

My normal ping didn't change: Waveform's idle reading was 8 to 9 ms on the Flint and 8 to 10 on the Nest. SQM only takes out the spikes under load.

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

The catch: with cake, about half my upload was gone

Cake is the Flint's default queue rule. With it on at 900/900, the upload stalled at 430.8 to 503.2 Mbps in all six runs at that limit, against 941.5 to 949.7 stock. Lowering the limit to 600 didn't move the wall (435.8 and 465.3), so the limit isn't what holds it back. GL's own SQM page warns about this. My best guess is the router's processor, since SQM switches off GL's hardware acceleration; I didn't measure its load.

At limits of 600 and up, cake also lagged on the download side in 3 of 8 runs, with 1 in 20 at +63 to +108 ms (the other five: +3 to +20). At a 300 limit both directions were clean, but the download fell to 263.3 to 293.9 Mbps, about two thirds less than stock's 908.3 to 918.1.

One setting got a big chunk back: fq_codel

GL's Queue Rule menu has two options, cake and fq_codel. At the same 900/900 limit, fq_codel kept 612.8 to 735.9 Mbps of upload in all four runs, against cake's 430.8 to 503.2, and the lag stayed just as low: 1 in 20 at +2 to +4 ms (cake: +1 to +3). On the download side it never lagged: 1 in 20 at +1 to +8 ms in all four. Four runs is a strong lead, not proof. It's what I run now: fq_codel at 900 both ways.

No hit on one-connection downloads

Video #1's fix cost me single-connection downloads, so I checked whether SQM does the same. After each PC result, I timed one 100 MB download over a single connection from a Hetzner server in Ashburn, VA (Mbps = bytes × 8 ÷ total time). Stock, it ran 395 to 554 Mbps across 9 runs. With SQM on at a 900 limit, 499 to 718 across 15. No hit; if anything, a little faster. In Leg D, curl went over IPv4 on some runs and IPv6 on others.

curl.exe -s -o NUL -m 20 -w "%{size_download} %{time_total} %{time_connect}" https://ash-speed.hetzner.com/100MB.bin

It fixes IPv6 too

In my last video, IPv6 meant F grades on my old router. On the Flint I turned IPv6 on two ways: GL's default, NAT6, and native (ISP-assigned) IPv6, the way the Nest gave it. Counting only the runs where Chrome's connections were logged going over IPv6: stock graded A, B, B, C and B, never an F, with 1 in 20 packets at +30 to +148 ms during the upload. With fq_codel at 900/900 it got an A or A+ every time, at +3 to +5 ms, and +3 to +14 ms on the download side. D1 and D2 ran before that logger started, so they're listed but not counted.

Source: Video #1's receipts: IPv6 on the old router

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

It can't fix the Wi-Fi on a mesh behind it

My old Nest stayed plugged in behind the Flint, with its own Wi-Fi on. My phone on the Nest's Wi-Fi graded C and C with SQM off, and D and C with fq_codel on: +161 to +210 ms added on upload either way. No better. On the Flint's own Wi-Fi, the same phone got an A every time, SQM off or on (Leg F, next). My best guess is that the lag builds inside the Nest, where the Flint's SQM can't reach; I didn't test that. If you add an SQM router, connect your gaming devices to it directly, wired or on its own Wi-Fi.

Someone else maxing out the internet: couldn't tell

Leg F asked a household question: does SQM protect my wired PC while someone else maxes out the internet? The PC sat idle with the probe running while my phone, on the Flint's own Wi-Fi, ran Waveform. But the phone alone couldn't make the Flint lag. With SQM off it pulled 1,105.1 to 1,122.4 Mbps down, and the idle PC's 1 in 20 stayed at +2 ms (worst +2 to +10). With nothing to fix, there's no verdict: that was the rule, set before the runs.

The phone graded A in all six valid runs. Those results are my read-outs, because the phone's incognito tab blocks screenshots. One side finding: with SQM on, the idle PC picked up small spikes (1 in 20 at +10 to +41 ms) that the stock runs didn't. I can't say why for sure.