Latency is the time a packet takes to make a round trip. Jitter is the variation between those times, and packet loss means expected packets never returned. Windows includes enough tools to locate many problems if you test from the local gateway outward.
Prepare a Controlled Test
Pause downloads, synchronization, streaming, and updates. Record whether the computer uses Ethernet, 2.4 GHz Wi-Fi, 5/6 GHz Wi-Fi, cellular, or a VPN. Run several tests at different times because congestion may be intermittent. Never compare one Wi-Fi result with one Ethernet result and call it an ISP trend.
Test the Local Gateway First
ipconfig
ping -n 100 192.168.1.1Use the actual default gateway shown by ipconfig. On Ethernet, latency should normally be low and stable. Wireless spikes or loss here point to signal, interference, roaming, adapter power saving, driver, or router load. The ISP is not involved in this first hop.
Test a Stable Internet Target
ping -n 100 1.1.1.1
ping -n 100 8.8.8.8If the gateway is clean but internet targets show loss, the problem lies farther along the path. Test more than one target because a host can rate-limit ICMP. Calculate loss from sent and received counts and compare average plus maximum latency. Averages can hide disruptive spikes.
Inspect the Route
tracert 1.1.1.1
pathping 1.1.1.1tracert shows the sequence of responding routers. pathping samples for longer and estimates loss. A router that appears to drop probes but is followed by clean later hops is probably deprioritizing diagnostics. Suspect a hop when the degradation continues through subsequent hops and the destination.
Measure Jitter for Real Applications
Voice, games, and remote desktops suffer when latency varies even if no packets are lost. Record a long ping while reproducing the problem. Compare idle and loaded conditions. If latency rises dramatically during an upload, the connection or router may have an unmanaged queue. Limit the competing upload or use supported smart-queue features on the gateway.
Compare VPN and Direct Paths
Repeat identical tests with the VPN disconnected and connected to a nearby endpoint. The VPN adds distance and processing, but local-gateway loss remains a local problem. If only one endpoint is poor, choose another and report the exact endpoint and timestamps. Our slow VPN guide covers protocol, MTU, CPU, and DNS isolation.
Document Evidence for the ISP
Capture date, time zone, connection type, router test, two internet targets, route output, and whether other devices were affected. Test by Ethernet directly through the normal supported gateway when possible. Redact public addresses if posting publicly, but provide full evidence privately to authorized support.
Common Fixes by Layer
- Local Wi-Fi: reposition, use a cleaner band, update drivers, and test Ethernet.
- Router under load: stop competing transfers, update firmware, review CPU and queue policy.
- One destination: check its service status and route; do not reconfigure the LAN.
- VPN only: compare endpoints and protocols, then investigate MTU.
- All devices: inspect modem signal and provider incidents.
Frequently Asked Questions
Is one percent packet loss bad?
It can noticeably affect voice, games, and TCP throughput, but confirm with repeated destination tests because ICMP treatment varies.
Why does one hop show loss but the destination does not?
That router is likely limiting replies to diagnostic probes while forwarding transit traffic normally.
What latency is good?
It depends on the application and distance. Stability and comparison with a known baseline are more useful than one universal threshold.
Final Diagnosis
Move outward in order: computer to gateway, gateway to internet, route, destination, then VPN or application. The first layer where clean results become poor is the best place to investigate.
