Is it the network or the machine? How to tell in 60 seconds

Acutis · plain-English network help · Episode 1 of the Acutis Go tutorial series · updated September 2026

"The internet is slow" is the most common complaint in computing, and the least specific. The slowness you feel is one number — but it's produced by two very different suspects: the network (Wi-Fi, router, cabling, DNS, your ISP) and the machine (CPU, memory, drivers, VPNs, security software). Fixing the wrong one wastes an evening. This page is the fast, honest way to split them.

Below is the text version of the video. Every command was run on a real Windows machine on 4 September 2026 and every line of output is shown exactly as it printed, including the two results that look like problems and are not.

Commands used in this video

In on-screen order. All of these run in Command Prompt or PowerShell on any Windows machine, nothing to install.

ipconfig

ping 192.168.0.1

tracert -d 1.1.1.1

ping 1.1.1.1

ping google.com

ping thishostdoesnotexist.example

What it actually printed

Colour key, the same as the video: green is the healthy line, amber is the line people misread.

Read the Default Gateway line: that address is your router, the first hop out of the house.

> ipconfig
   Default Gateway . . . . . . . . . : 192.168.0.1

Read the loss figure, then remember this machine was online the whole time: most home routers simply do not answer a ping aimed at themselves.

> ping 192.168.0.1
Pinging 192.168.0.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Read hop 1 only. Hop 1 is your router, and the same router that showed 100% loss answers in 1 ms, three for three.

> tracert -d 1.1.1.1
Tracing route to 1.1.1.1 over a maximum of 8 hops
  1     1 ms    <1 ms    <1 ms  192.168.0.1

Read the loss and the average: 0% loss and about 22 ms is what a healthy home connection looks like, and a number was used instead of a name on purpose.

> ping 1.1.1.1
Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=22ms TTL=57
Reply from 1.1.1.1: bytes=32 time=22ms TTL=57
Reply from 1.1.1.1: bytes=32 time=23ms TTL=57
Reply from 1.1.1.1: bytes=32 time=22ms TTL=57
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Minimum = 22ms, Maximum = 23ms, Average = 22ms

Read the address in square brackets on the first line: the name was turned into a number before the first packet left, which means DNS is working.

> ping google.com
Pinging google.com [64.233.179.100] with 32 bytes of data:
Reply from 64.233.179.100: bytes=32 time=33ms TTL=107
Reply from 64.233.179.100: bytes=32 time=34ms TTL=107

Read the wording: this is not a timeout, it never sent anything, and that signature is DNS rather than connectivity.

> ping thishostdoesnotexist.example
Ping request could not find host thishostdoesnotexist.example.
Please check the name and try again.

Read it as a ladder: small inside the house, one honest step up at hop 2, then broadly flat, and a starred hop 4 with healthy hops after it is noise.

> tracert -d 1.1.1.1
  1     1 ms    <1 ms    <1 ms  192.168.0.1
  2    16 ms    17 ms    16 ms  216.160.151.254
  3    21 ms    20 ms    19 ms  71.36.254.1
  4     *        *        *     Request timed out.
  5     *       22 ms    21 ms  4.69.219.74
  6    21 ms    21 ms     *     4.71.42.142
  7    23 ms    23 ms    23 ms  172.68.32.12
  8    23 ms    23 ms    23 ms  1.1.1.1

Three results that look like problems and are not

The video has two of these, and they are the two most common false alarms in home troubleshooting.

Pinging my own router returns 100% packet loss. Is my router down?

Usually not. The router in the video returned four timeouts and 100% loss while the machine was online, downloading and browsing the whole time. A great many home routers are configured not to answer a ping addressed to themselves while forwarding all real traffic normally. Silence here is not evidence of a fault. Ask the router a different way: run tracert -d 1.1.1.1 and read hop 1. Hop 1 is your router, and in the video it answered in 1 ms, three times out of three.

One hop in my tracert shows * * * Request timed out. Is that where the problem is?

Not if the hops after it answer normally. In the video hop 4 timed out with three stars while hops 5 through 8 all answered at normal speed, so traffic clearly went straight through hop 4. Plenty of routers along the way deprioritise or ignore the courtesy replies tracert depends on while forwarding real traffic without hesitation. A starred hop with healthy hops after it is noise. What you are hunting for is a hop where the time jumps up and stays up for every hop after it. That link carries the delay, and where it sits tells you whose problem it is: before your provider's first hop it is yours, after it, it is theirs.

The checklist

1. Second device also bad: look at the network. Second device fine: look at that machine.
2. Router silent to ping: that is normal. Check hop 1 of a tracert instead.
3. Number reachable but name not: that is DNS.
4. Latency that jumps at one hop and stays high: that link owns the delay, and which side of your router it sits on tells you who fixes it.
5. Run those in order and you will land on the right link nearly every time, on any machine, without installing a thing.

Chapters

• The question
• The four links every problem lives on
• The test that needs no tools
• Pinging your own router (and why silence is normal)
• Asking the router a different way: tracert hop 1
• Reaching the internet by number
• Bringing names into it: spotting DNS
• Reading the whole path as a ladder
• The checklist
• Doing this on a fleet

The 60-second method

1. The two-device test. Same speed test (any of them — ours is here), two devices, same Wi-Fi, same spot. Two slow devices can't both be broken the same way — that's the network. One slow device while its neighbor flies — that's the machine.
2. Split the path. Open a terminal and ping your router, then the internet:
   ping 192.168.0.1 (your gateway — find yours with this guide)
   ping 1.1.1.1 (the internet)
   Router fast (1–5 ms, no loss) + internet slow or dropping → the problem is past your router, on the ISP side. Router itself slow or lossy from one machine → the problem is inside the house, or inside that machine.
3. Glance at the machine. Task Manager (Windows) or Activity Monitor (Mac): CPU pinned near 100%? Memory maxed? Disk thrashing? A machine drowning in its own work makes a perfect network look broken.

Symptom table: what it usually means

Say it precisely: the two kinds of fault

Network fault

A failure outside your device: weak Wi-Fi signal or interference, an overloaded router, failing modem, DNS not resolving, or congestion and outages on the ISP side. Fingerprint: more than one device suffers.

Machine fault

A failure inside your device: exhausted CPU or memory, an old or crashing network driver, a VPN or proxy inserted into the path, security software scanning every packet, or failing hardware. Fingerprint: the machine underperforms even on a healthy network.

The split matters because the fixes never overlap. Restarting the router will not fix a driver. Reinstalling Windows will not fix your ISP. Diagnosing first isn't perfectionism — it's the shortcut.

When you need evidence, not a feeling

One good speed test proves almost nothing — networks fail intermittently. The 3 p.m. slowdown that's gone by 3:20 is invisible to any spot check, and it's exactly the case where households blame the laptop, offices blame the "slow computer," and ISPs blame you. What settles arguments is the same checks, repeated over time, with timestamps: speed and latency from more than one device, gateway-vs-internet pings, Wi-Fi signal, and the machine's own vitals, logged across days.

You can do that by hand with a spreadsheet and discipline. Nobody does. That's the gap the tool below closes.

Frequently asked questions