Forem: Rasulmmdv

Why Your Internet Speed Test Lies

Rasulmmdv — Sun, 16 Nov 2025 20:17:08 +0000

Speedtest.net vs Fast.com in real life

Your speed test says 400 Mbps.

YouTube still buffers.

Nothing feels more cursed than that.

That happened on my home fiber line.

Speedtest.net proudly showed more than 418 Mbps down, but YouTube sessions still dropped quality or paused to buffer.

The numbers looked great, the experience did not.

The trick is simple: speed tests often measure the best case, while streaming exposes the real case.

Two tests, two different truths

Speedtest.net is built to show what your connection can do when everything is aligned in its favor.

It talks to dedicated, well peered servers and opens several parallel TCP connections to push your link as hard as possible.

The result is a nice high number that represents peak capacity, not necessarily what you get for every service.

Fast.com, from Netflix, is much closer to what your streaming apps feel.

It talks to real CDN infrastructure, pulls real data over a sustained period and focuses on how fast you can actually move video like traffic.

That is why Fast.com often shows a lower number that still explains your YouTube or Netflix experience much better than a single big result from Speedtest.net.

If Speedtest.net is your max horsepower on a dyno, Fast.com is how fast the car actually accelerates on the road.

Protocols: TCP vs QUIC in one glance

Most classic speed tests use TCP.

TCP is reliable, ordered and conservative, and it slowly ramps up how much data it sends until it figures out what the network can handle.

To compensate for that slow start, speed tests usually use several parallel TCP streams to reach your real peak quickly.

Modern streaming platforms lean heavily on QUIC over UDP, also known as HTTP3.

QUIC runs on UDP, adds encryption and reliability, and handles packet loss more gracefully without blocking every stream when one packet goes missing.

ISPs do not always treat TCP and UDP traffic the same way, so your speed test path and your video path can be very different, even on the same line.

You can think of TCP as a careful truck convoy and QUIC as a lot of smaller, nimble cars using partly different roads.

My real world results

Here is what my line looked like on paper.

Local Speedtest.net server in Baku, PASHA Technology:

Download: 418.14 Mbps

Upload: 435.85 Mbps

Ping: 6 ms

Loaded latency (down): 60 ms

Loaded latency (up): 89 ms

Speedtest.net server in Helsinki, GSL Networks:

Download: 390.72 Mbps

Upload: 326.58 Mbps

Ping: 110 ms

Numbers say your connection is a monster.

But when I ran Fast.com, the picture changed.

Fast.com consistently reported noticeably lower speeds that felt much closer to what I saw when YouTube dropped quality or paused.

Speedtest.net showed the theoretical maximum.

Fast.com revealed the practical streaming ceiling.

I also ran a quick traceroute to youtube.com to see how the packets travel.

traceroute youtube.com

The path goes through my home router, across my ISP’s core, then out via a Moscow internet exchange onto Google’s backbone, and finally lands on a YouTube edge in about 60–70 ms. That hop pattern is clean and the latency is low and stable, so routing itself looks fine; the real problem is not “ping” but how much throughput I get for streaming traffic compared to what classic speed tests report.

Why the gap happens

There are three usual suspects.

First, peering and routing.

My ISP clearly has a very clean, well provisioned path to the Speedtest.net servers it picks for me.

The path to the Netflix and YouTube CDNs is different, sometimes longer and sometimes more congested.

Second, traffic treatment.

Generic TCP test traffic looks harmless and small in volume compared to the hours of video people stream every evening.

During busy times, it is easy for an ISP to give streaming traffic lower priority than other things without completely breaking it.

Third, protocol differences.

If the network handles UDP and QUIC slightly worse than TCP, you feel that specifically in streaming, games and real time apps.

On a graph, the TCP path still looks beautiful, while the QUIC path quietly suffers.

How to check your own line quickly

You can reproduce this pattern in a few minutes.

Do one Speedtest.net run to a nearby server.

Note download, upload and ping and glance at the loaded latency while the test is running.

That gives you your lab result.

Then open Fast.com and run it a couple of times, especially during the hour when you actually watch YouTube or Netflix.

If Fast.com is in the same ballpark, your streaming path is probably healthy.

If it is half or less of the Speedtest number, especially in the evening, you are likely seeing congestion, weak peering or some form of video deprioritization.

Small tweaks that actually help

If you control your router, give priority to traffic that hates latency.

Real time calls first, then streaming, then normal browsing, then heavy downloads and torrents.

Smart queue management will not magically increase your Mbps, but it can stop a single download from wrecking a family movie night.

Another quick experiment is to compare Fast.com with and without a VPN.

If speeds suddenly jump when you tunnel out through a decent nearby VPN, it is a strong hint that your provider is treating some destinations or protocols less kindly than others.

In that case you can either live with it, complain with data in hand or lean on the VPN for the services that suffer most.

The real meaning of “418 Mbps”

That 418 Mbps Speedtest result on my connection is not a lie.

It is just telling a very specific story: how fast my line can go to a friendly server over TCP under ideal conditions.

YouTube buffering and lower Fast.com numbers tell the rest of the story:

how my ISP peers with big CDNs,

how QUIC over UDP is routed,

how streaming traffic is handled when the network is busy.

So the takeaway is simple.

Use more than one test.

Treat big Speedtest.net numbers as best case, not a guarantee.

For streaming, the less glamorous Fast.com style results are often closer to what your eyes and ears actually feel.

The Friendly Guide: "Why WSL is Eating My C: Drive (and How to Get it Back)"

Rasulmmdv — Sat, 06 Sep 2025 18:24:00 +0000

If you've ever used the Windows Subsystem for Linux (WSL) with tools like Docker or Node.js, you may have been horrified to see your C: drive space rapidly vanish. Even more confusing, a tool like tree might show a file named \\wsl.localhost\Ubuntu\proc\kcore taking up a ridiculous amount of space—like 120TB!

This is a common and incredibly misleading problem. I recently went through this myself, and here's the straightforward guide to understanding what's happening and how to fix it.

💡 The Big Secret: The 120TB Is an Illusion

First, let's clear up the biggest piece of misinformation:

The kcore file is not real. It's a virtual file that represents a memory map of the Linux kernel. Its reported size (120TB or more) is a theoretical limit for a 64-bit system, not actual disk usage. It's the equivalent of a ghost in the machine—it's there, but it's not taking up any space.
The real culprit is the WSL virtual hard disk (.vhdx). All of your WSL data—your Linux files, Docker images, npm packages, everything—is stored in a single, large virtual hard disk file on your C: drive. This file grows as you add more data, and crucially, it never shrinks on its own when you delete files.

This is why you can run a docker system prune, free up space inside WSL, and yet see no change on your Windows C: drive.

🛠️ The Fix: The Two-Step "Clean & Shrink" Method

To reclaim your lost disk space, you must do two things:

Clean up the unnecessary files inside your WSL environment.
Compact the virtual hard disk file to return the freed-up space to Windows.

Let's dive in.

Step 1: Clean Up Inside WSL (Deleting the Bloat)

This is about identifying and removing the largest files from your Linux environment.

Remove Docker Bloat:
Even if docker system prune reclaimed 0B, large images you're not using might be the problem.

# List all Docker images by size
docker images -a --format "{{.ID}}\t{{.Repository}}\t{{.Tag}}\t{{.Size}}" | sort -k4 -h

# Identify and remove any large, unused images by their ID
docker rmi <image_id_1> <image_id_2>

Find and Delete node_modules Folders:
node_modules folders are notorious for their size. Navigate to old projects and simply delete them.
```
# Example:
cd ~/my-old-project/
rm -rf node_modules
```
Use ncdu to find the largest directories:
This is my favorite trick. ncdu is a fantastic command-line tool that lets you navigate and find the biggest directories quickly.
```
# Install if you don't have it
sudo apt install ncdu

# Run it to scan your entire file system.
# Be patient, this might take a minute!
sudo ncdu /
```
Once the scan is complete, you can use your arrow keys to navigate and find the largest folders to investigate and clean up.

Step 2: Compact the VHDX File (The Magic Trick)

Now that you've deleted files inside WSL, you must tell Windows to physically shrink the container file on your C: drive.

Locate Your WSL Disk File:
This file is buried deep in your AppData folder. The path will look something like this:
```
C:\Users\<YourUsername>\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_...\LocalState\ext4.vhdx
```
The folder name with CanonicalGroupLimited.UbuntuonWindows_ will have a unique string of characters for your system.
Shut Down WSL:
This is the most critical step. You must terminate all running WSL processes.

  * Open **PowerShell** or **Command Prompt** as an **Administrator**.
  * Run the shutdown command:

    ```bash
    wsl --shutdown
    ```

Run the Compacting Utility:

  * In the same **Administrator** window, start the disk utility:

    ```bash
    diskpart
    ```

  * Now, select your WSL disk file (paste the full path you found in Step 1):

    ```bash
    select vdisk file="<FULL_PATH_TO_YOUR_EXT4.VHDX>"
    ```

  * Finally, run the compact command:

    ```bash
    compact vdisk
    ```

This process will take a few minutes, depending on the size of your file. Once it's complete, check your C: drive. You should see your free space magically restored!