Ping is the most used and most misread tool in networking. Four packets tell you almost nothing. Two hundred packets, aimed at the right three targets in the right order, tell you which side of the router your fault lives on.
In the video case, the support team pinged two targets: the Tally server and Google. That instinct is the whole method. A ping result is only meaningful against a known point in the path. Gateway first, then a public IP, then a name - and the pattern of the loss matters as much as the amount. This guide turns ping from a vibe into evidence.
Example only: when every target loses the same share - including the gateway one metre of cable away - the fault is inside your local link, not at the ISP and not at the server.
ping -n 200 192.168.1.1. This tests only your cable, switch and router port. Loss here means the fault is inside your building, full stop8.8.8.8. Gateway clean but loss here moves suspicion to the internet lineping google.com. If the IP works but the name fails or resolves slowly, you have a DNS problem wearing a ping costumeIn the video, the server and Google lost packets together - and the gateway-side link was the shared path, which is where the fault turned out to live.
Bursts of 3 to 4 lost together, then clean: a link event - renegotiation, a marginal pair making and breaking, a port resetting. This is the wired speed and duplex signature. Single random losses spread evenly: congestion or interference class problems. Long total silence, then replies: the link went fully down and came back - power, a rebooting switch, a cable being unplugged. Replies with wildly jumping times: something is saturated - a backup, a big copy, an overloaded uplink. Write the pattern in the ticket; it is worth more than the percentage.
Request timed out means no reply arrived in time - the packet or its answer died on the path. Destination host unreachable usually comes from your own PC or gateway admitting it has no route - a addressing or downed-interface problem, different animal. Reply times under 1 ms on LAN are normal; a wired LAN reply of 20 ms is already a symptom. And always test wired when diagnosing wired complaints - a Wi-Fi ping mixes radio problems into a cable investigation, which is a different disease with different cures. Test from the same wall point, on a cable, before concluding anything.
A 3 percent loss over 4 packets is invisible - zero or one lost, usually zero, because the burst passed before you started. Two hundred packets minimum for a verdict; for an intermittent complaint, run ping -t while the user reproduces the problem in their actual application - Tally reconnecting on cue while the ping window drops bursts is a case-closing screenshot. Record sent, received, lost and the time of day. Intermittent faults respect office hours more often than you would think.
See the video case - two ping windows, gateway-side and internet-side, and how the burst pattern pointed the team at the local link.
Watch Full VideoNot in your local link. If the gateway answers 200 pings with zero loss while a public IP drops packets, suspicion moves to the router WAN side, the ISP line or upstream congestion. Repeat at different times and log it - that log is what an ISP support desk needs.
A short link event. The connection broke and remade itself - classic causes are speed renegotiation from a marginal cable pair, a duplex mismatch collapsing under load, or a port resetting. Bursts are a physical or link-layer signature, not an application problem.
At least 100 to 200 for a percentage you can act on, and for intermittent complaints run a continuous ping while the user reproduces the fault in their application. Four packets can only ever prove the path worked for those four packets.