How to Check for Packet Loss via CMD: Ping, PathPing & Traceroute Guide (2026)

Share:
How to Check for Packet Loss via CMD: Ping, PathPing & Traceroute Guide (2026)

When diagnosing intermittent internet drops, stuttering Discord audio, or rubber-banding in online multiplayer games, web-based speed tests often fail to catch momentary dropouts because they only run for a few seconds. The most powerful, reliable diagnostic tools are already built directly into your operating system's command line. Using Windows Command Prompt (CMD), you can run continuous ICMP packet loss tests, measure millisecond jitter, and pinpoint the exact network hop where packets are being dropped. Here is the definitive tutorial.

1. The Continuous Ping Test: Measuring Real-Time Packet Loss

The standard ping command only sends four packets. To detect intermittent packet loss over time, use the continuous -t flag:

  1. Press Win + R, type cmd, and press Enter.
  2. Type the following command to ping Cloudflare's ultra-reliable DNS server:
    ping 1.1.1.1 -t
  3. Let the test run for at least 50 to 100 replies (about 1 to 2 minutes).
  4. Press Ctrl + C on your keyboard to terminate the test and view the summary statistics.

Interpreting Your Ping Test Results:

  • 0% Loss (Packets: Sent = 100, Received = 100, Lost = 0): Flawless connection health.
  • 1% to 5% Loss: Minor packet loss (typically caused by Wi-Fi airwave interference or household bufferbloat).
  • >10% Loss: Severe network degradation (indicates bad physical Ethernet cables, failing router, or ISP line fault).

2. The PathPing Command: Pinpointing the Failing Network Hop

If your ping test shows packet loss, how do you determine if the problem is your home router, your ISP's neighborhood node, or the game server host? The pathping command provides deep hop-by-hop packet loss analysis:

pathping -n 8.8.8.8

PathPing will spend roughly 3 to 5 minutes sending 100 pings to every single router along the path between your PC and Google's servers.

Hop Number in PathPing Output Network Infrastructure Layer What Packet Loss at This Hop Indicates
Hop 1 (e.g. 192.168.1.1) Your Local Home Wi-Fi Router Defective Ethernet cable, bad Wi-Fi channel, router CPU crash
Hop 2 (e.g. 10.x.x.x or 100.x.x.x) ISP Neighborhood Node (CMTS / OLT) Physical ISP cable damage, dirty fiber, or neighborhood node overload
Hop 4–7 (e.g. Level3 / Cogent / Telia) Tier-1 Internet Transit Backbone Major regional internet backbone peering congestion
Hop 8+ (Final Destination Server) Target Website or Game Host Game server host is overloaded or DDoS-protected

Why ICMP Rate Limiting by Routers Can Show 'False Positive' Loss

When running a traceroute or PathPing test, you may occasionally see a hop in the middle of the trace showing 100% packet loss (e.g. * * * Request timed out), while subsequent hops show 0% loss and fast response times.

This is ICMP Rate Limiting / ICMP Deprioritization: core internet backbone routers (like Cisco or Juniper border routers) prioritize high-speed customer transit data (TCP/UDP) and intentionally ignore or rate-limit diagnostic ICMP echo requests to protect their control plane CPUs. If the final destination server shows 0% loss, intermediate ICMP timeouts are completely harmless and can be safely ignored.

Measuring Jitter via Command Line (PowerShell Method)

To measure millisecond jitter variance between consecutive packets directly in Windows PowerShell without third-party software, run:

Test-Connection -TargetName 1.1.1.1 -Count 30 | Select-Object Address, ResponseTime

Calculate the difference between the minimum and maximum response times; a difference of less than 3.0ms indicates exceptional line stability.

3. Testing Local Network vs Internet (Isolating the Router)

To definitively prove whether packet loss is happening inside your house or out on your ISP's lines, open two CMD windows side-by-side:

  • In Window 1, ping your router default gateway: ping 192.168.1.1 -t
  • In Window 2, ping an external internet IP: ping 1.1.1.1 -t

If Window 1 has 0% loss (< 1ms ping) while Window 2 has 8% loss, your home network is 100% healthy, and the fault lies entirely with your internet service provider's external lines.

Using PowerShell to Graph Continuous Packet Latency

For network engineers and power users who want more detailed metrics than basic CMD, PowerShell allows you to output millisecond timestamps and calculate standard deviation jitter:

1..50 | ForEach-Object {
    $p = Test-Connection 1.1.1.1 -Count 1
    [PSCustomObject]@{
        Time = (Get-Date).ToString("HH:mm:ss.fff")
        Ping = $p.ResponseTime
        Status = if ($p.ResponseTime -ne $null) { "OK" } else { "LOST" }
    }
    Start-Sleep -Milliseconds 500
} | Format-Table -AutoSize

This script executes 50 ping queries every 500 milliseconds, displaying exact microsecond timestamps to capture momentary packet drops during live Zoom calls or gaming matches.

Understanding MTU Packet Fragmentation with Ping (-f -l Flags)

If your internet connection drops packets during heavy downloads, your Maximum Transmission Unit (MTU) may be misconfigured, causing packets larger than your ISP's buffer to be fragmented or discarded. You can test for MTU fragmentation directly in CMD using the -f (Do Not Fragment) and -l (Packet Size in Bytes) flags:

ping 1.1.1.1 -f -l 1472

If you receive 'Packet needs to be fragmented but DF set', lower the byte number (e.g. 1460, 1450) until packets pass with 0% loss. Add 28 bytes (IP/ICMP header) to find your optimal network MTU size.

Summary Checklist: Diagnosing Packet Loss via Command Line

  1. Run ping 1.1.1.1 -t for 50 packets to measure general loss percentage.
  2. Run ping 192.168.1.1 -t to isolate whether packet loss is on your local router or external ISP line.
  3. Run pathping -n 8.8.8.8 to pinpoint the specific failing intermediate routing hop.
  4. Verify line stability with a live bufferbloat test on DCSpeedTest.

Why Continuous ICMP Telemetry Outperforms Browser Speed Tests

Browser-based speed tests only measure bandwidth for a brief 8-second window. By running a continuous CMD ping test over 100 to 200 packets while you perform your normal daily tasks, you capture momentary dropouts, power line interference, and neighborhood node congestion that short speed tests completely miss, giving you definitive proof when contacting ISP technical support.

Why Regular Command-Line Audits Keep ISPs Accountable

When internet service providers receive customer support tickets, front-line representatives often claim 'everything looks green on our end'. By maintaining documented CMD ping and PathPing log outputs showing exact percentage loss at specific hop IP addresses, you provide undeniable technical evidence that obligates your ISP to escalate your ticket to Level 3 network engineering.

⚡ Benchmark Your Internet Connection Now

Measure your true download & upload bandwidth, latency jitter, and bufferbloat in real-time with zero ads slowing down your test.

Run Free Speed Test ➔

Frequently Asked Questions

What is the command to test continuous packet loss in Windows CMD?

Open Command Prompt and type 'ping 1.1.1.1 -t'. This continuously sends 32-byte ICMP packets. Press Ctrl + C after 50 packets to see your exact packet loss percentage and latency summary.

What is the difference between Tracert and PathPing?

Tracert lists the route hops between your PC and the server, showing latency to each router. PathPing does a full traceroute and then tests each intermediate hop over a 5-minute period, reporting exact packet loss percentages per hop.

What does 'Request Timed Out' mean in a CMD ping test?

It means the target server or an intermediate router failed to return an ICMP Echo Reply within the timeout window (typically 4,000 ms), indicating packet loss, severe congestion, or an ICMP-filtering firewall.

Sources & References

See our research methodology for measurement limitations and our standards for reproducible evidence.

About the Author

Dalto Cardoso is the founder of DCSpeedTest, an IT network engineer teaching command-line telemetry diagnostics, ICMP protocol testing, and packet loss troubleshooting.