# Y2KDASH > Y2KDASH is a continuous-monitoring internet speed test at https://y2kdash.com. Unlike Ookla and Fast.com which run one-shot speed tests, Y2KDASH samples every 60 seconds in the background to capture latency under load, jitter, packet loss, and bufferbloat against Cloudflare edge endpoints. Backed by a dashboard designed for a second monitor rather than a triggered test. ## Network of sibling sites - https://snitchtest.com — SNITCHTEST: forensic browser privacy audit with 18+ client-side tests and server-observed backend probes. - https://piholekiller.com — PIHOLEKILLER: 103-test adversarial ad-blocker audit across 6 pillars and 3 difficulty tiers, with public leaderboard. - https://adbloat.com — ADBLOAT: ad-tech overhead benchmark with composite A-F letter grade against a naked-Chromium baseline. --- # The Speed Test Lie: Why Your 300 Mbps Connection Still Feels Slow Source URL: https://y2kdash.com/the-speed-test-lie.html **Summary:** Ookla says your connection is 300 Mbps. Fast.com agrees. Then Zoom drops a frame, your game rubber-bands, and a page stalls for three seconds. Here's what one-shot speed tests miss — and what a real network monitor measures instead. > field manual · why your dashboard lies # The Speed Test Lie: Why Your 300 Mbps Connection Still Feels Slow Ookla says 312 Mbps down. Fast.com agrees. Then your video call freezes, a game server kicks you for lag, and a blog post takes six seconds to render. The number was real. The number was also useless. Here's the gap between what one-shot speed tests measure and what your connection actually does when you live on it. PUBLISHED 2026-04-19 · ~8 MIN READ · FIELD NOTES FROM Y2KDASH ## 1. A speed test is not a latency test The public conception of "internet speed" is a single number in megabits per second. Marketing departments love this because it's a bigger-is-better benchmark you can slap on a billboard. Every major speed test you've used — Ookla, Fast.com, speed.cloudflare.com — rounds your entire network experience down to that number and one or two sidekicks (ping, jitter) that most users don't look at. But throughput is the easy part. A 40 GB game download will happily eat 300 Mbps for twenty minutes. That's one scenario. Meanwhile, every interactive thing you do all day — typing into a web form, talking on Zoom, clicking a link, opening a Slack message, joining a deathmatch — depends on round-trip latency, and it depends on how that latency behaves when the pipe is actually being used. Ookla measures latency for about one second, at idle, before it starts the download. Then it ignores latency for the rest of the test. So if your link is a Ferrari that pulls into a parking lot every time a packet has to squeeze past someone else's download, the final score still says Ferrari. A one-shot speed test is a dump truck clocking 60 mph on an empty road. Your actual experience is a bike messenger trying to pass the dump truck. ## 2. What Ookla / Fast.com / Cloudflare actually do To understand the blind spot, look at the shape of the test. Every major speed test follows the same three-step structure, and the limits of that structure are the limits of what it can tell you. - A quick ping flight — a handful of ICMP or HTTP probes to the nearest server. Reports as "ping" or "idle latency." Takes <1 second. - A saturating download — one or several concurrent streams pulling bytes as fast as they'll come. Usually 10–15 seconds, sometimes less. The peak throughput during that window is reported as "download speed." - A saturating upload — same idea in reverse. Usually shorter than the download. That's the entire test. Notice what's missing: any probe for how the connection behaves between those phases, any measurement of what happens to latency during the download, any coverage of the long tail of drops and spikes that dominate real experience. Also missing: time. A ten-second dump is over before a lot of the interesting pathology even starts. Your router's queueing behavior, your ISP's traffic shaping, your Wi-Fi's retry loops, the upstream carrier's congestion — those take longer than ten seconds to bite. A speed test that ends before the problem starts can't catch the problem. ## 3. Bufferbloat: the hidden variable The biggest thing one-shot tests don't see is bufferbloat, and bufferbloat is usually the reason "fast" connections feel slow. When data arrives at your router or modem faster than it can send it out, the excess piles up in a buffer. Buffers are necessary — they smooth out bursts — but device manufacturers tend to install enormous buffers, because "never drop a packet" sounds great in a marketing test. The problem is that when the buffer is full of download traffic, every other packet has to wait in line behind it. Your click, your keystroke, your voice packet — all stuck behind a queue that reaches hundreds of milliseconds long. You see this as: the page half-loads instantly, then stalls for a beat. The Zoom call garbles for two seconds every time someone uploads a photo. Your game ping doubles the moment a family member starts a Netflix stream. None of these show up on a speed test, because the test runs in its own protected window. To catch bufferbloat, you measure latency during a saturated download. That number — called loaded latency — is the single most predictive metric for real-world feel. The delta between your idle latency and your loaded latency is the bufferbloat grade. bufferbloat deltagradewhat it feels like < 30 msAcalls, games, everything stays smooth under load 30 – 100 msB / Cnoticeable lag on calls when uploads happen 100 – 300 msDcalls garble, games rubber-band, pages stall > 300 msFthe link is unusable for anything interactive while saturated ## 4. Why five seconds isn't enough There's another reason short tests lie: TCP slow-start. TCP doesn't just fire at full speed the instant a connection opens. It starts small, doubles its congestion window every round-trip, and keeps doubling until it sees packet loss. Only then does it know the ceiling. On a fast link with even modest latency, slow-start can take three or four seconds to reach the real capacity. A test that ends at 10 seconds spends a third of its time ramping up, which drags the reported number below the actual peak. A test that ends at 2 seconds — and some free speed-test widgets are this short — sometimes doesn't reach the ceiling at all. The fix is simple: measure for at least five seconds of saturated transfer, and ideally average across a rolling window so the ramp is diluted. That's what a continuous monitor does. That's what a one-shot "tap the button once, show a big number" UI can't do. ## 5. The metrics a real test measures If throughput is just one dimension, what are the others? Here's the honest list of everything that affects how a connection feels, ranked roughly by how much it matters for interactive use: - Loaded latency — round-trip time during a saturated download. This is the metric bufferbloat shows up in. Lower is better; <80 ms total is a good target. - Unloaded latency (idle ping) — round-trip time to a nearby server when nothing else is happening. Sets the physical floor. Usually dominated by distance. - Jitter — the standard deviation of your ping. A perfectly stable 80 ms link beats a bouncy link that averages 30 ms but swings from 10 to 200. Voice and games hate jitter more than they hate raw latency. - Packet loss — the percentage of probes that vanish. Even 1% loss murders real-time protocols. Under 0.1% is healthy; anything over 1% is a problem you can hear. - Download throughput — sustained Mbps during a multi-second saturated test. Big downloads care. Most interactive traffic doesn't. - Upload throughput — the other side of the same coin. Matters more than people think — video calls, cloud backups, sending screenshots in Slack. - Stability over time — the coefficient of variation of your throughput samples. A link that averages 200 Mbps with 10% swing is nothing like a link that averages 200 Mbps with 60% swing. ## 6. Why one-shot dashboards can't catch it The structural problem with a test you have to trigger is that you only run it when you're paying attention. You run it because something feels off — the video froze, the game hitched — and by the time you click the button, whatever caused it has already ended. You measure the recovery, not the event. The other half is that an active test tells the network, "I am about to pour traffic through you, please behave." The router empties its queues. Other devices back off. Your ISP's QoS kicks in. The number is flattering because the test is conspicuous. A continuous monitor measures while nothing else is going on, while you're browsing, while you're uploading, while someone else in the house is streaming. It catches the thing that caused the hitch fifteen minutes ago, because it was already sampling when the hitch happened. The difference between a benchmark and a monitor is the difference between a dentist's x-ray and a pulse oximeter. Both are useful. One of them tells you what's happening right now. ## 7. How to read an ambient monitor Y2KDASH is a continuous monitor. It samples once per minute in the background, hits Cloudflare's public speed endpoints, and plots everything on a rolling window. You leave it open on a second monitor and look at it the way you look at a weather map — for patterns, not spot readings. A few things worth looking for: - The loaded-latency trace vs. the unloaded trace. If they're separated by more than 100 ms for most of the day, you have a bufferbloat problem. The router's queue management (or lack of it) is the first suspect. - Jitter on the download line. A near-flat horizontal line is a healthy ISP. A ragged sawtooth is a congested ISP or a neighbor saturating your node. - Packet-loss bars clustering at certain times. Loss that correlates with specific hours usually means shared-medium congestion (DOCSIS, cellular, overcommitted fiber PON). Random loss means a flaky segment somewhere. - The grade history. The AIM composite (the single A–F letter the dashboard shows) rolls downloads, uploads, idle, loaded, jitter, loss, protocol, and stability into one number. The interesting thing isn't the current value — it's how much it varies over a week. ## 8. What a good connection actually looks like A healthy residential broadband link, measured continuously, looks like this: metricgoodacceptablebroken download (sustained)> 80% of plan60–80%< 50% upload (sustained)> 80% of plan60–80%< 50% idle latency< 25 ms25–60 ms> 80 ms loaded latency< 80 ms80–180 ms> 250 ms jitter (stdev)< 5 ms5–20 ms> 30 ms packet loss (24h)< 0.1%0.1–1%> 1% Most residential connections pass download and upload and fail loaded latency. That's the industry's dirty secret. The pipe is fat, the queueing is terrible, and nobody tests for it because the tests people use don't measure it. The fix is almost always router-side — enabling a proper queue management algorithm like CAKE, Codel, or FQ-Codel, or replacing the ISP's rental box with something that runs one. Some operators ship with it on by default. Most don't. ## 9. FAQ ### Why is my speed test fast but my internet feels slow? Speed tests measure a short, saturated download to a nearby server. They do not measure latency under load, jitter, or packet loss over time. Most "fast but slow" connections have a bufferbloat problem: their raw throughput is fine, but their latency balloons whenever the link is busy — which is exactly when you are using it for a video call, a game, or a page load. ### What is bufferbloat? Extra latency caused by oversized packet buffers in routers, modems, or ISP equipment. When a download saturates the pipe, every other packet (a click, a voice frame, a game move) queues behind it. The download finishes fine; everything interactive feels awful until it ends. ### How is loaded latency different from ping? Ping measures round-trip time when the link is idle. Loaded latency measures round-trip time while the link is fully busy with a download or upload. Loaded latency is almost always much higher; the difference is the bufferbloat grade. Healthy connections show a delta under 30 ms; bad ones show 200 ms or more. ### Why do short speed tests under-report my real speed? TCP uses a ramp-up algorithm called slow-start. It begins at a small rate and doubles every round-trip until packet loss appears. On a fast connection, slow-start can take 3–4 seconds to reach your real ceiling. A speed test that ends at 2–3 seconds never hits the real number. ### Does Ookla or Fast.com measure bufferbloat? Neither measures loaded latency. Ookla reports ping only before the test starts, never during, so bufferbloat is invisible to it. Waveform measures loaded latency as a one-shot; y2kdash measures it continuously over time. ### What is a good loaded-latency number? Under 80 ms total loaded latency (idle ping + bufferbloat delta combined). Delta alone should be under 30 ms. Above 150 ms total, video calls and games become notably worse. Above 300 ms, they become unusable while the connection is saturated. ### How does a continuous speed test differ from a one-shot test? A one-shot test measures the network in isolation while it is paying attention. A continuous test samples in the background once a minute, recording the connection's behavior while you actually use it. Continuous monitoring is the only reliable way to catch intermittent bufferbloat, packet-loss bursts, or ISP congestion that only appears at certain times of day. ## 10. The short version A one-shot speed test is a trust fall. It tells you your link can do X megabits, once, for a few seconds, when conditions are ideal. It does not tell you what your link does when you actually use it. If your speed test keeps agreeing with your plan but your experience keeps disagreeing with the speed test, the speed test isn't wrong. It's just answering a different question. Measure loaded latency, jitter, and packet loss over time, and the "why does my internet feel slow" mystery usually solves itself inside a day. > field probe Run the ambient monitor Y2KDASH measures everything above continuously and plots it. Leave it open on a second monitor. Come back in an hour and read the ceiling, the floor, and everything in between. > LAUNCH Y2KDASH → --- # How to Actually Fix Bufferbloat: The Router-by-Router Guide Source URL: https://y2kdash.com/how-to-fix-bufferbloat.html **Summary:** Bufferbloat is almost always fixable in under 20 minutes, without buying anything. Here's the exact settings for OpenWRT, ASUS Merlin, pfSense, Ubiquiti, TP-Link, Netgear, ISP-supplied routers — and how to verify the fix with continuous monitoring. > field manual · the 20-minute fix # How to Actually Fix Bufferbloat: The Router-by-Router Guide Bufferbloat is almost always fixable in 20 minutes, on hardware you already own, for $0. The one-line version is: enable a queue manager called CAKE (or failing that, FQ-Codel) on your router, set the shaping limit to about 90% of your measured line speed, verify the fix with a continuous monitor. The rest of this page is the per-router specifics, the common mistakes, and how to tell when you're actually done. PUBLISHED 2026-04-21 · ~9 MIN READ · FIELD NOTES FROM Y2KDASH ## 1. Diagnose first, fix second Before touching anything, confirm that bufferbloat is actually your problem. A lot of "my internet is slow" is really Wi-Fi congestion, DNS, or a neighbor hammering a shared segment. Bufferbloat has a specific signature: idle latency looks fine, loaded latency spikes, and the spike correlates perfectly with anyone in the house hitting play on something big. The direct test is a loaded-latency measurement. Start a sustained download and ping a nearby server at the same time. The difference between your ping during the download and your ping when the link is quiet is the bufferbloat grade. Under 30 ms is clean. Over 100 ms is a problem you will feel on every video call, every game, every page that loads while someone else is streaming. Y2KDASH measures this continuously so you can watch the shape of it instead of catching a single moment; waveform.com/tools/bufferbloat runs a one-shot version. ## 2. Know your real throughput (not your plan number) Every fix below needs a number: your actual sustained download and upload in Mbps. Not the plan sticker, not the Wi-Fi number, not the last Ookla peak — the number your router actually sees coming in and going out on a wired client during a 5-second-or-longer saturated test, repeated a few times. Record both. Most residential plans are asymmetric (e.g. 500 down / 20 up), and bufferbloat on the upload side is often worse because the upstream pipe is smaller and buffers fill faster. Set aside both numbers — you'll plug them into the router. The single most common mistake is setting the shaper to the plan speed. Shape to what your connection actually sustains, not what the billboard says. ## 3. The fix, by router type Below is the practical matrix. If your router isn't in the list, the trick is the same one everywhere: find a menu that says any of SQM, CAKE, FQ-Codel, Adaptive QoS, or Smart Queue, enable it, and set the ingress/egress limits to roughly 90% of your measured line speed. If none of those words appear in the firmware, skip to the "no-knobs router" section. ### OpenWRT (the gold standard) OpenWRT's sqm-scripts with the cake queue discipline is the reference implementation. Everything else on this page is a compromise with it. Setup in the LuCI web UI: - Install the sqm-scripts and luci-app-sqm packages (opkg install luci-app-sqm). - Go to Network → SQM QoS. Add a rule on your WAN interface. - Queue discipline: cake. Queue setup script: piece_of_cake.qos. - Download limit: 90% of measured download. Upload limit: 90% of measured upload. Both in kbit/s. - Link layer adaptation: Ethernet for fiber or cable with a separate modem; ATM for DSL; DOCSIS on DOCSIS if available. - Save + Apply. Reboot the WAN connection. That's it. On a 300/25 cable plan this typically reduces loaded latency from ~250 ms over idle to under 5 ms over idle. The CPU cost on a modern ARM router (GL-MT3000, GL-AXT1800, anything with a dual-core Cortex-A53 at 1+ GHz) is negligible up to a few hundred Mbps. Above 500 Mbps you want hardware with a faster CPU — the common pattern is an x86 mini-PC running OpenWRT or a Banana-Pi-class board. ### ASUS routers with stock firmware Since 2018 most ASUS RT-* routers ship with Adaptive QoS, which is a Trend Micro signature-based classifier plus a shaper. It's not CAKE, but it is useful. Settings: - Adaptive QoS → QoS → Enable QoS: On. - QoS Type: Adaptive QoS. - Download bandwidth: 90% of measured download. Upload bandwidth: 90% of measured upload. - Priority: set "Web Surfing" or "Gaming" higher than "File Downloading" — this is the actual queue-priority behavior. Default order is usually fine. Caveat: Adaptive QoS uses deep packet inspection, so it reduces max throughput slightly on the highest plans. On gigabit fiber the cost is real; on anything under 500 Mbps you won't notice. ### ASUS routers with Asuswrt-Merlin (recommended) Asuswrt-Merlin is a maintained, mostly-stock fork of ASUS firmware that unlocks proper CAKE via the FreshJR_QOS / CAKE-QoS scripts on the Diversion + Scribe / scripts entware stack. On a supported RT-AX86U / RT-AX88U / GT-AX6000 this is as close to OpenWRT's performance as you get without giving up the ASUS UI. Install Merlin, then follow the FreshJR CAKE guide. ### pfSense / OPNsense Use the FairQ + CoDel shaper, or install the CAKE port. pfSense 2.7+ has native CAKE in the traffic shaper wizard. Run the wizard, pick CAKE, set ingress/egress to 90% of measured line speed, done. On OPNsense the same thing is at Services → Traffic Shaper → Pipes. ### Ubiquiti EdgeRouter / UniFi EdgeRouter (ER-X, ERLite, ER-4) supports FQ-Codel natively and CAKE via the shell, but the UniFi Dream Machine line historically doesn't expose queue management in the GUI. On a UDM / UDM-Pro / UDM-SE the workaround is shell-level tc commands after every firmware update. If you're on UniFi, consider whether an EdgeRouter or an OpenWRT box in front of your UDM is the pragmatic move. ### TP-Link, Netgear Nighthawk, Linksys (stock firmware) Most of these expose a "QoS" menu that does not do CAKE. It's usually a priority-by-device or priority-by-port system that ties tightly to the router's chipset shaper. The honest assessment is: it helps, it does not fix the problem. If the menu is there, set your line speeds, set priority for gaming/voice devices, and measure. If the delta is still over 50 ms loaded vs. idle, you are up against the firmware's limit. The paths from here are: flash OpenWRT if your model is supported, replace with a GL.iNet or EdgeRouter, or put an OpenWRT box in series between your ISP device and your existing router. ### ISP-supplied gateways (Xfinity xFi, AT&T BGW, Verizon Fios) Short version: these almost never support CAKE or real SQM. The standard fix is bridge mode (or AT&T's IP-passthrough) with your own CAKE-capable router behind it. On Xfinity xFi this is on the Admin Tool at 10.0.0.1 → Gateway → At a Glance → Bridge Mode. On AT&T BGW210 / BGW320 it's in Firewall → IP Passthrough. On Verizon Fios Gateway it's in Advanced → Network Settings → Network Connections → Broadband → Settings. You lose the ISP's mesh / 2.4-5-6 GHz Wi-Fi, but you gain a router you can actually tune. This is by far the most common upgrade path. ### The "no-knobs" router (Apple AirPort, Google Nest Wifi, Eero) Apple AirPort is discontinued and has no knobs. Google Nest Wifi has basic device prioritization but no CAKE. Eero Pro 6/6E offers "Eero Plus" which is not queue management. For bufferbloat, these platforms require the same fix as the ISP case: put a real router in front, run the no-knobs device in AP-only mode (Eero "Bridge Mode"; Nest Wifi disable gateway). ## 4. The most common setup mistakes - Shaping to the plan speed instead of the measured speed. Your ISP delivers less than the plan number during peak hours. If your shaper is set to the plan, the real bottleneck is upstream, outside your queue. Set to 90% of measured. - Only shaping download. Upload bufferbloat is usually worse and is what kills calls / uploads / screen-sharing. Both directions need limits. - Wrong link-layer setting. On DSL, skipping ATM accounting costs you 8-15% of effective throughput. On DOCSIS, picking DOCSIS overhead is a small but free win. - Running CAKE on a CPU that can't keep up. If your router's CPU pegs at 100% during a saturated download, you'll cap below your line speed. Check CPU load during a 5-second test; replace the router if it can't handle your plan. - Putting the shaper on the wrong interface. SQM goes on the WAN interface (the one facing your modem/ISP), not on the LAN or a wireless interface. ## 5. Verify the fix Immediately after enabling CAKE, run a loaded-latency test for at least 10 continuous minutes. You want to see: metricbefore fixafter fix (target) loaded − unloaded latency> 150 ms< 30 ms download (sustained)varies> 85% of measured cap upload (sustained)varies> 85% of measured cap jitter during saturation> 30 ms< 5 ms The continuous-monitoring view on y2kdash is the fastest way to confirm. Put it on a second monitor, trigger a few family-style mixed workloads (Netflix + Zoom + a big download), and watch the loaded-latency line. With CAKE correctly configured, the line stays flat. ## 6. If it's still broken after CAKE Three things to check, in order: - Are you still behind an ISP gateway? If so, your CAKE is only shaping the link between your router and the gateway. The gateway's own queue is still producing bufferbloat. Bridge mode. - Is your Wi-Fi the actual bottleneck? On a crowded 2.4 GHz band, airtime contention produces effects that look like bufferbloat but live in the AP, not the WAN. Test with a wired client to isolate. - Is your upload cap realistic? Cable upload plans frequently deliver well below the sticker number. Re-measure during peak hours and reset the upload limit. ## 7. FAQ ### What is bufferbloat in simple terms? Bufferbloat is latency that appears only when your connection is busy. When a large download fills your router's packet buffer, every other packet (a click, a voice frame, a game move) waits in line behind it. The result is a fast connection that feels terrible under load. ### How do I know if I have bufferbloat? Run a loaded-latency test and compare your idle ping to your ping during a saturated download. If the difference is more than 100 ms, you have bufferbloat. A healthy connection stays within 30 ms of its idle ping even under full load. ### Does a faster internet plan fix bufferbloat? No. Bufferbloat is a queuing problem, not a throughput problem. A 1 Gbps plan with bufferbloat will still feel laggy under load. Enabling queue management (CAKE, FQ-Codel) on your router is the real fix, and it works on any speed plan. ### What is CAKE and why is it better than regular QoS? CAKE (Common Applications Kept Enhanced) is a modern Linux queue discipline that combines shaping, fair queuing, and active queue management in one policy. Unlike old-school per-application QoS that requires classifying every flow, CAKE just keeps every flow's queue tiny. The effect is that voice, gaming, and browsing traffic stay responsive even when one flow is saturating the link. ### Why do I need to set the bandwidth limit below my ISP speed? Queue management only works if your router is the bottleneck. If you set CAKE to your full line speed, the queue forms at your ISP's router instead, and you get no benefit. Setting the limit to 85-95% of your measured throughput keeps the queue where CAKE can manage it. ### Can I fix bufferbloat on an ISP-supplied router? Usually not directly. Most ISP-supplied routers (Xfinity xFi, AT&T BGW, Verizon Fios Gateway) lack SQM or CAKE in their firmware. The standard workaround is to put the ISP device in bridge or IP-passthrough mode and run your own router with CAKE behind it. ### Is CAKE better than FQ-Codel? CAKE is newer and generally better for home connections because it includes shaping (so you don't need a separate HTB layer) and handles asymmetric links (cable, DSL) cleanly. FQ-Codel is still excellent and is lower overhead on slower CPUs. For CPUs that can handle it, prefer CAKE. > verify your fix run the continuous monitor After you flip on CAKE, let y2kdash run for 10 minutes with a saturated download going. The loaded-latency line shows whether the fix holds under load. > LAUNCH Y2KDASH →