Troubleshooting
What Is Packet Loss and How Do You Spot It?
Packet loss means sent packets do not reach their destination. Compare devices, connections and repeatable tests; missing ping replies alone do not identify the fault.
Packet loss occurs when a sent packet does not reach its destination. Broken speech, jumps in a game or stalled transfers can fit, but also have other causes such as device processing or an application fault. High download speed does not rule out intermittent loss. The VMAXCHECK speed test does not provide a direct packet-loss measurement; its speed or latency result cannot confirm this diagnosis.
Start with a controlled comparison
- Record the time, duration, affected application and whether several devices have trouble together. If the app offers network statistics, note the reported loss and direction, following its own explanation.
- Compare Wi-Fi and Ethernet on the same device shortly apart. Pause your large transfers and backups for the baseline, then observe separately under the conditions that normally trigger the problem.
- Repeat in a quiet period and during the fault. Keep the same destination and settings; one clean test does not exclude an intermittent problem. An evening pattern alone does not prove congestion.
- Compare another device and another service. Only one app failing calls for an app or service check as well. Improvement over Ethernet points toward the wireless path or device, but does not prove Wi-Fi dropped frames.
Use bounded ping tests and record the conditions
On Windows, ping /n 50 1.1.1.1 sends 50 ICMP echo requests to a public destination. Use a destination that responds; it is not necessarily your application's server. Also test the local router address shown in your network settings, replacing the destination with that address. Keep the two results separate. Record sent and received counts, missing replies and round-trip times. Repeat with the same count, timeout, packet size and address family. Do not shorten timeouts drastically or use rapid flood tests; waiting for missing replies can make a test take several minutes.
Interpret missing replies carefully
- Two missing replies from 50 requests are 4% missing ICMP replies in that sample. This is not a reliable estimate for all application traffic. A router or destination can limit or block ICMP, and the request or its reply may fail on different parts of the round trip.
- Missing router replies together with application problems justify checking the local path first. A nonresponding router without matching symptoms is not enough to declare the local connection faulty.
- If the router keeps responding while several Internet destinations and apps fail, investigate the router's Internet side, access connection and wider path. These results do not isolate the provider as the culprit.
- Traceroute asterisks or loss shown for one intermediate hop in pathping are not automatic evidence of failed forwarding. Compare the destination, later hops and actual app symptoms; devices may restrict replies addressed to themselves while forwarding other traffic.
Delay and loss are different: a high ping is not a count of lost packets. TCP can retransmit missing data, sometimes causing delay or lower transfer speed. UDP itself does not guarantee delivery; applications may add their own recovery. The effect depends on the application and whether loss is isolated or occurs in bursts, so one percentage is not a universal pass/fail limit. A short result with no missing replies cannot guarantee every route or future session.
Make targeted changes, then repeat the comparison
- For a wireless-only pattern, check coverage and competing radio use. For wired trouble, compare a known good compatible cable or port and check official guidance for the device and network adapter. Change one thing at a time.
- If trouble tracks your own large transfers, pause, schedule or limit them and compare. Supported queue management may help congestion-related problems when configured using the manufacturer's guide; it does not repair every kind of loss.
- Save router events and before/after measurements before a manufacturer-guided restart. A restart interrupts other users and calls and is a test, not proof of the cause. Avoid making a factory reset or disabling protection the first step.
- Repeat the same tests and the affected app after a change. If only one service still fails, check its status and contact its support; if several devices and services fail, give the network provider the comparison results.
Give support times, duration, connection type, router model, test destinations and settings, sent/missing counts, round-trip times, affected devices and apps, and what changed with Ethernet or reduced load. Remove passwords, tokens and private account details from logs. Reproducible observations are more useful than blaming the hop with the largest percentage or buying a faster plan from one result.