How to read a tracert and find where the delay actually starts

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

This page is the text version of the video. Every command below was run on a real Windows machine on 6 September 2026 and every line of output is shown exactly as it printed. The only edits: traces run with -d (pathping with -n) so no hostnames print, the provider hop addresses left as printed, which places the machine in its metro and nothing closer, and long output trimmed to the hops that teach, with every trim stated in a note line. The inconvenient results stayed in: the router that ignores ping, the hop that starred out and then answered a direct ping four for four, and the one probe that took 631 ms.

Commands used in this video

In on-screen order. All of them run in Command Prompt or PowerShell, nothing to install.

tracert -d 1.1.1.1

tracert -d 8.8.8.8

tracert -d -h 12 www.microsoft.com

pathping -n -q 10 1.1.1.1

ping -n 4 192.168.0.1

ping -n 4 4.68.38.145

ping -n 10 1.1.1.1

What it actually printed

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

Read it as columns: the hop number is the rung, the three numbers are three separate probes to that rung, then the address of whatever answered. Hop 1 is the router in the next room. Hop 2 is the step out of the house. Hop 4 said nothing at all.

> tracert -d 1.1.1.1
Tracing route to 1.1.1.1 over a maximum of 30 hops
  1     1 ms     1 ms     1 ms  192.168.0.1
  2    15 ms    15 ms    15 ms  216.160.151.254
  3    20 ms    19 ms    19 ms  71.36.254.1
  4     *        *        *     Request timed out.
  one line per rung. three numbers = three separate probes to that rung.
  hop 1: your router. hop 2: out of the house. hop 4: said nothing at all.

Same trace, continuing from hop 4. Hop 5 is on the far side of hop 4, and the only way to reach it is through hop 4, so hop 4 forwards every packet at full speed and simply does not answer about itself.

> tracert -d 1.1.1.1
  4     *        *        *     Request timed out.
  5    21 ms    24 ms    20 ms  4.69.219.74
  6    21 ms    21 ms    20 ms  4.71.42.142
  7    23 ms    22 ms    23 ms  172.68.32.12
  8    22 ms    22 ms    22 ms  1.1.1.1
Trace complete.
  hop 5, past it, answered in 21 ms. hop 4 forwards, it just stays quiet.

The same hop, thirty seconds later on a trace to a different address, answered two of three and gave up its address. Same router, slightly better mood.

> tracert -d 8.8.8.8
  4     *       20 ms    20 ms  4.68.38.145
  trimmed to hop 4 of the next trace: the same hop answered two of three.

A longer ladder to a real website. Hop 7 printed one probe at 631 ms, then three silent rungs, and then the far end answered in 36. If hop 7 were adding 600 ms, hop 11 would have to carry it. It did not.

> tracert -d -h 12 www.microsoft.com
  trimmed to hops 6-11. hops 1-3 as before, hops 4 and 5 timed out.
  6    34 ms    34 ms    34 ms  4.30.70.2
  7    35 ms    35 ms   631 ms  66.198.86.13
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11    36 ms    36 ms    36 ms  184.29.36.91
Trace complete.
  631 at hop 7, then 36 at the far end. the far end did not inherit it.

Ten packets to every rung. Read the columns: hop, round trip, lost/sent from your machine to that rung, the same count for just that rung, then the address. The router is 10 of 10 lost and hop 2 is clean, which is the whole tell.

> pathping -n -q 10 1.1.1.1
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  1  ---      10/  10 =100%    10/  10 =100%  192.168.0.1
  2   18ms     0/  10 =  0%     0/  10 =  0%  216.160.151.254
  3   20ms     0/  10 =  0%     0/  10 =  0%  71.36.254.1
  4   21ms     0/  10 =  0%     0/  10 =  0%  4.68.38.145
  5   25ms     0/  10 =  0%     0/  10 =  0%  4.69.219.74
  6   25ms     0/  10 =  0%     0/  10 =  0%  4.71.42.142
  7   30ms     0/  10 =  0%     0/  10 =  0%  172.68.32.12
  8   26ms     0/  10 =  0%     0/  10 =  0%  1.1.1.1
  trimmed to hops 1-8, the per-hop rows. every link row read 0/ 10 = 0%.

The router, pinged directly: 100% loss, from the same device that answered hop 1 of every trace above in 1 ms.

> ping -n 4 192.168.0.1
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
  the same router that answered hop 1 of every trace in 1 ms, 3 for 3.

The hop that printed * * *, pinged directly: four for four at 20 ms.

> ping -n 4 4.68.38.145
Reply from 4.68.38.145: bytes=32 time=20ms TTL=61
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
  the hop that printed * * * answers a direct ping. stars are not down.

Ten pings to the far end: nine between 22 and 24 ms, one at 50. The trace's last hop said 22. That 22 is your ping.

> ping -n 10 1.1.1.1
Reply from 1.1.1.1: bytes=32 time=50ms TTL=57
    Minimum = 22ms, Maximum = 50ms, Average = 25ms
  one of ten at 50. the trace's last hop said 22. that 22 is your ping.

Three results that look like problems and are not

Pinging my router returns 100% packet loss. Is the router dead?

No. ping -n 4 192.168.0.1 came back four sent, zero received, 100% loss, from the same router that answered hop 1 of every trace in this session in 1 ms, three for three. It forwards everything and ignores a direct ping, and a lot of home routers do. If you only ran ping you would think your router was dead. The trace is the test. The pathping table says the same thing: 100% at hop 1 and 0% at hop 2, and if the router were really eating packets, hop 2 could not be clean.

A hop shows * * * Request timed out. Is that where the problem is?

Not here. ping -n 4 4.68.38.145, the hop that printed * * * in the first trace, came back four sent, four received, 20 ms, 0% loss. It answered two of three on the next trace and ten of ten in pathping. Stars mean that hop did not answer that probe. They do not mean it is down, and they do not mean it is slow. The rungs after it tell you which.

One ping out of ten took 50 ms. Is my line bad?

No. ping -n 10 1.1.1.1 printed nine replies between 22 and 24 ms and one at 50, for a minimum of 22, a maximum of 50 and an average of 25. The trace's last hop, the same address, said 22, 22, 22. That 22 is your ping. The 50 is one packet out of ten taking a longer road for a moment. It is weather. If it were every packet, the average would say so. Zero loss and an average near the minimum is a healthy line, whatever the maximum says.

The checklist

1. ping -n 10 to where you are going. If the average is small, stop. Nothing in a trace will lower it.
2. tracert -d to the same place. Read the last line first. That number is your ping.
3. Walk up from the bottom. The first rung where the number jumps and every rung below it stays up owns the delay.
4. * * * with the rungs below answering, or stars right up to a far end that still answers, means skip the line.
5. One big number in one column that the next rung does not inherit is one slow reply, not a slow path.
6. Before hop 2, it is yours. Hops 2 and 3, it is your provider, and this screen is what you send them. The last line, it is the far end, and it is theirs.

Chapters

• The question
• A ladder, not a list
• Ping first, trace second
• The first four rungs
• The hop that says nothing
• The far end, and whose problem it is
• Loss per rung: pathping
• Three results that look like problems and are not
• The checklist
• Doing this on six hundred machines

A ladder, not a list

Every packet you send climbs a ladder of routers to get where it is going, and a trace is that ladder printed one rung per line. There are four kinds of rung.

• Your router. Hop 1, about 1 ms. Everything before it is yours: the Wi-Fi, the cable, the router itself. If this number is ever high, thirty or fifty or two hundred, stop reading and go fix the Wi-Fi, because nothing past this rung can be trusted until this one is right.
• Your provider. Hop 2 is the first thing on the far side of your modem and hop 3 is a little deeper into their network. This is where you take one honest step up, because the packet just left the house. On this machine that step is 1 ms to 15 ms, and it is normal.
• The middle of the internet. Hops that belong to nobody you can call. They are allowed to ignore your trace completely and still forward your traffic, and answering traces is the lowest priority job they have.
• The far end. The last line, the server you were actually trying to reach. Its number is the only number on the screen that is your ping. Every other number is how long it took some router in the middle to answer you, and routers in the middle answer when they feel like it.

So the rule is this. Read the last line first. That is your delay. Then walk up the ladder and find the first rung where the number jumps and every rung after it stays up. That rung is where the delay starts. A rung that jumps while the next rung comes back down did not add anything. It was just slow to answer. That is also why a rung can print a bigger number than the rung after it, as hop 7 did in pathping at 30 ms against the far end's 26: each number is how fast that router chose to reply, not a distance.

Ping first, trace second

Before you trace anything, ping the place you are trying to reach ten times and read the average at the bottom. On this machine, to 1.1.1.1, it was 25 ms. If your average is a small number, you are done. Nothing inside a trace can make that number smaller, because the trace's last line is the same measurement. The trace earns its keep only when that average is bad, or when one ping out of ten is bad every single time, and then its job is to tell you which rung raised it. Ping first, trace second. That order saves more time than any command in this video. If your average is high and you want the list of things that raise it, that is Why is my ping so high?.

Whose problem it is

Everything before hop 2 is yours. If the delay starts at hop 1, it is in your house and nobody else can fix it. Hops 2 and 3 are your provider; if the number jumps there and stays up on every rung after, that is what you call them about, with this screen in hand. The far end is the destination's. If every rung is fine until the last one and the last one is high, the server is slow or far away, and no amount of router restarting touches it. Deciding whether the trouble is even on this machine at all is Episode 1.

Loss per rung

A trace shows delay. It does not really show loss, because three probes is not enough to count. pathping is already on your machine and almost nobody uses it: it runs the trace, then sends ten packets to every rung and counts what came back. The rule for loss has the same shape as the rule for delay. Loss that starts at a rung and continues through every rung after it is real; packets are dying there and everything downstream feels it. Loss at one rung only, with 0% at every rung past it, is that rung declining to answer. It is not losing your packets. It is ignoring your questions. For what real loss does to a call or a game, and how to fix it, read What is packet loss?.