2

I am trying to log ping results and graph/analyze the results over an extended duration. I have been using:

ping <address> -D -O -i 0.1 > output.txt

When analyzing the output log I noticed the output does not match up with the results I parse out.

My ping output statistics look like:

546681 packets transmitted, 546529 received, 0.0278041% packet loss, time 55177378ms
rtt min/avg/max/mdev = 23.444/46.021/617.625/9.977 ms, pipe 6

However, when I back-calculate these results from the log I get:

Total Packets sent: 546,535
Arrived on time packets: 545,167
Exceeded timeout but arrived: 1,362
Lost: 6

You can see that I have no record of ~1500 transmitted packets. I am not sure what happened to them as there was no timeout message nor arrival message.

Is it possible for force ping to output outbound packets as well as inbound ones?

Improve this question
New contributor
Ian Wu is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

1 Answer 1

Reset to default
3

The 23 msec RTT suggests that you may be pinging e.g. from Minneapolis or Dallas to a San Francisco datacenter. There's more than one explanation for missing packets, including buffer bloat, ordinary congestion, and good old power fail.

Some of the difficulty may be local. I encourage you to also routinely ping a LAN-attached host, plus a "nearby" host that is at least a kilometer away. This will help you separate "near" from "far" effects, such as episodes that your WAN link experiences.

Fundamentally ICMP is not an "app to app" protocol. Rather, it is a "host to host" protocol; a randomized payload, reflected back to the sender, helps us to distinguish what one or another ping process sent. Embrace that aspect of it. In addition to logging stdout of ping, also run
tcpdump -s 1500 -w ping.pkts icmp.
This will capture all inbound and outbound pings, plus some other things that routers occasionally send.

If possible, run that wireshark / tcpdump command on a distant WAN-attached host that you have sudo on.

If possible, do periodic large file transfers to that WAN-attached host, to assess how packet loss rates and available bandwidth vary over the course of the day. Failing that, do file transfers over your WAN link to a host you control.

Periodically record netstat -s output on the source host, and if possible on the target host. Pay close attention to the "Icmp" and "IcmpMsg" sections.

Your goal in all of this is to tease apart effects happening near the source host, near the target host, or "internet weather" effects on the amorphous cloud in between.

For that last part, you might choose to ping router IPs that show up in traceroute output. However, 100 msec is much too fast to be pinging ISP / NSP infrastructure. Send just a handful of pings each minute, lest your source IP be blacklisted.

Improve this answer
4
  • "The 23 msec RTT suggests that you may be pinging e.g. from Minneapolis or Dallas to a San Francisco datacenter" – I really don't see how it suggests that. OP hasn't even stated which continent they're in, much less the country, nor what sort of WAN link they're pinging through – for many users that's just the first-hop latency alone. Commented Oct 24 at 6:29
  • 1
    I was translating speed of light through fiber to geographic distances. You, or the OP, are free to suggest other populous regions and other places where cloud providers host their servers. My point was that, once we're past a few kilometers of delay, there are many failure modes out there in the cloud that will interact with your ICMP echo response observations. Commented Oct 24 at 7:56
  • How does this explain the discrepancy between ping's summary and the details in the log file? Commented 2 days ago
  • Hard to say, as the OP has not yet posted data from a pair of hosts participating in the ping experiment. I usually start by bringing a pair of “should be same” tcpdump binary logs together, and look for diffs. Often there is a “bad minute” where we experienced a clump of loss events. It requires sudo on both ends, so the netstat -s figures can be a poor man’s substitute for that sometimes. Recording background TCP traffic can also be informative, as the retransmit events show up very clearly. Sometimes we see queuing (RTT) delay go up just before loss events. Commented 2 days ago

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.