Ping results I don't understand

In summary, the conversation discusses issues with the uplink and using ping to analyze and understand the problem. The speaker mentions that the ping results show no problems, but questions the timing and intervals of the packets being sent. They also consider the possibility of DNS lookups affecting the results and plan to try pinging without DNS lookups in the future. Another person suggests that the issue may be related to line saturation or connection quality, which can be affected by weather conditions. The conversation ends with the speaker acknowledging that there may be packet loss, but notes that it is not a major issue in this case.
  • #1
Borek
Mentor
28,951
4,245
I have problems with my uplink that I am trying to analyze and understand (in hope my ISP will be able to do something about that - they tested the line and found no problems, sadly, problems are transient and appear in random moments).

Simplest thing - ping. bpp.com.pl is a domain I own, hosted at home.pl, one of the largest (or perhaps the largest) web hosting service services in Poland:

Code: 
borek@raspberrypi ~ $ ping -c 20 bpp.com.pl
PING bpp.com.pl (212.85.97.214) 56(84) bytes of data.
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=1 ttl=57 time=99.8 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=2 ttl=57 time=122 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=3 ttl=57 time=64.1 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=4 ttl=57 time=65.4 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=5 ttl=57 time=69.5 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=6 ttl=57 time=64.4 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=7 ttl=57 time=97.2 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=8 ttl=57 time=742 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=9 ttl=57 time=99.7 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=10 ttl=57 time=101 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=11 ttl=57 time=101 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=12 ttl=57 time=101 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=13 ttl=57 time=63.5 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=14 ttl=57 time=65.5 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=15 ttl=57 time=63.9 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=16 ttl=57 time=66.7 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=17 ttl=57 time=65.5 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=18 ttl=57 time=65.1 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=19 ttl=57 time=64.7 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=20 ttl=57 time=63.6 ms

--- bpp.com.pl ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 55609ms
rtt min/avg/max/mdev = 63.553/112.436/742.109/145.656 ms
Looks OK, doesn't it? Well... no. How come it takes over 55 seconds to send and receive 20 packets, if they are sent in 1 second intervals? Just watching how the ping displays results it is obvious some packets take many seconds to travel, yet they are reported as if they traveled in just a little bit over 60 ms. How is the time measured?
 
Computer science news on Phys.org
  • #3
Yes, but it doesn't answer the question why a computer that is expected to send packets every 1 second does it at different intervals. Each time I use ping in my home LAN, or each time I use ping to probe outside world and my uplink works correctly, packets are sent every second, in accordance with ping man page.
 
  • #4
I did a couple ping tests as well and this is what I got
20 packets transmitted, 19 received, 5% packet loss, time 19095ms
20 packets transmitted, 17 received, 15% packet loss, time 19018ms

I'm not sure exactly how ping is deciding it's been one second but it doesn't look like it cares as long as it's ball park. Was your system doing something else that might keep the processor busy while you were pinging?
 
  • #5
The lookup of host names for IP numbers usually takes some time (outside the ping itself). Try with -n and see if that changes the total run time.
 
  • #6
Routaran said:
Was your system doing something else

No, nothing serious. There are always some tasks present in the background, but in general it was not under any load.

Filip Larsen said:
The lookup of host names for IP numbers usually takes some time (outside the ping itself).

Do you know if it asks before each ping, or only once, at the very beginning? Because just looking at what it displays it looked as if it lost a second or two at the very beginning, but then lost a lot of time between random pings (some went second by second, some stopped for a long time).

But I agree there is some information that I can get by ignoring DNS lookups, next time my uplink starts to play with me I will try not only to ping -n, but also just ping -n 212.85.97.214. At the moment it works perfectly OK, so all tests go as expected.
 
  • #7
The ICMP protocol may not be what you appear to think it is. For starters, ping packets are not required to be echoed back, many sites block ping. In the US, most federal sites that are in .gov do not ping. But the connection is okay.

If the TTL value gets decremented to zero and you get the packet back you get a time to live error. Your returns above are not necessarily errors. Busy systems will defer forwarding ping packets or simply drop them.

ping uses ICMP mainly to get an echo back. Or run traceroute-like things. You got echoes back, so far as I can see. No packet loss. The ping packets contain a time sent value so that when and if that packet comes back ping can calculate time differences. I am totally guessing: it appears to be a line saturation/connection quality problem more than anything.

We have had similar problems in wet weather with remote DSL lines that become noisy due to poor connections in foul weather. ping packets may take longer but do come back to us. Retransmits on the connection are the usual culprit.
 
  • #8
jim mcnamara said:
For starters, ping packets are not required to be echoed back

That would mean lost packets. Happens sometimes, but in this case I have 0% packet loss.

jim mcnamara said:
The ping packets contain a time sent value so that when and if that packet comes back ping can calculate time differences. I am totally guessing: it appears to be a line saturation/connection quality problem more than anything.

We have had similar problems in wet weather with remote DSL lines that become noisy due to poor connections in foul weather. ping packets may take longer but do come back to us. Retransmits on the connection are the usual culprit.

All true, but I don't see how these things can be combined.

If ping packets take longer to come back, I should see it in reported rtts - but apart from 8th (almost 0.8s) all others require below 100 ms, which is more or less what I see when the system works perfectly.

If the line is saturated and packets have to wait for transmission, rtt should be longer - which is not the case.

This is what I see right now:

Code: 
borek@raspberrypi ~ $ ping -c 20 bpp.com.pl
PING bpp.com.pl (212.85.97.214) 56(84) bytes of data.
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=1 ttl=57 time=47.5 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=2 ttl=57 time=48.0 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=3 ttl=57 time=48.4 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=4 ttl=57 time=54.1 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=5 ttl=57 time=47.6 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=6 ttl=57 time=54.5 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=7 ttl=57 time=48.0 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=8 ttl=57 time=73.6 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=9 ttl=57 time=50.1 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=10 ttl=57 time=75.0 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=11 ttl=57 time=49.3 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=12 ttl=57 time=50.9 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=13 ttl=57 time=58.5 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=14 ttl=57 time=60.3 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=15 ttl=57 time=48.2 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=16 ttl=57 time=48.4 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=17 ttl=57 time=48.1 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=18 ttl=57 time=47.9 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=19 ttl=57 time=49.2 ms
64 bytes from v000468.home.net.pl (212.85.97.214): icmp_req=20 ttl=57 time=48.3 ms

--- bpp.com.pl ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19026ms
rtt min/avg/max/mdev = 47.524/52.836/75.087/8.011 ms

19 seconds for 20 packets. What I am asking is - why today 19 s is enough, but few days ago the same operation took 55 s, when rtt is almost identical.

If the program waits for the packet to get back before it sends another one, total working time should be 19 s plus 20*average rtt. If the program doesn't wait, total time should be 19 s plus time required for the last packet to get back. Neither equals 55 seconds in the first case.

Even calling DNS doesn't look like a possible culprit, at least if I understand how these things work. DNS calls are cached by default, so the first call can take longer, but then for some time all should be just local, so for all practical purposes instant?
 
  • #9
Try traceroute to your ISP. Record what you get somewhere. When things go South time-wise at some future point, run traceroute again. Compare. If you lose routers in a network, ignoring a possible man in the middle attack, you should see more latency. Rerouting along a different route to get past a blockage - this is sometimes called internet weather - increases latency for you because of the fact that you are an endpoint and you are stuck routing through whatever happens out there to get to your ISP.

For example, I have home DSL. On Monday UNIX.com showed my connection as originating from Peralta NM. The day before it was Albuquerque, NM. This is because of CenturyLink routing, my ISP provider.

Sorry - I'm just not getting your confusion. My apologies.
 
  • #10
This sounds like something that Wireshark would answer. I don't have a lot of experience with Wireshark, but the few times I used it, it really helped.
 
  • #11
jim mcnamara said:
Sorry - I'm just not getting your confusion.

I will try again.

Program (ping) reports two separate kinds of information.

One is related to packets - how long it takes for the ping packet to travel to destination and to get back (it will also report packets being lost, average/min/max round trip-time (rtt), but it is still information about packets).

Second is a program total working time - how long it took to send all these packets and to wait till they get back.

Total working time consists of the delays between packets (by default 1 second long), some initial call to the DNS, to find IP of the computer that should be pinged, and depending on how the program works it can also include round trip times. If I am sending 20 packets, I expect the program to wait for around 19 seconds total, so assuming packets traveling fast (low rtt times) total time the program works should be not much longer. That's what happened in the second case I listed - total running time (reported at the end of the output) was 19026 ms (so apparently round trip times are not included).

What I don't understand is why the total running time in the first case was so much longer, at 55609 ms, when rtts were in general in the same below 100 ms range.
 
  • #12
FactChecker said:
This sounds like something that Wireshark would answer. I don't have a lot of experience with Wireshark, but the few times I used it, it really helped.

From what I see in wikipedia I will have to use TShark, as I am not using any GUI of the raspberry. But thank you for the pointer, I will look into it.
 
  • #13
It's got to be something on your system. since the rtt is still essentially identical, the network's doing the same thing as it was when you got the 55s run time. Each individual ping was still taking the same amount of time to traverse the network. The only thing left over is that the system was waiting a lot longer between sending out pings.
I do not have a good explanation for why this would occur given your system wasn't under load.
 
  • #14
Routaran said:
I do not have a good explanation for why this would occur given your system wasn't under load.

Not only the system is not under load - other computers from my LAN experienced hiccup with the web access at the time, which was what started me investigate. Instead of getting answers, I got tricky questions o_O
 
  • #15
You know, if other computers were also having an issue on the LAN at the same time, perhaps this may be an issue with your switches or router. If you have managed devices, perhaps you can look up it's documentation to see if any of your switches recorded a fault or any errors around that time.
 
  • #16
My bet is that the problem is outside (uplink). But it still doesn't explain why ping shows what it shows. I expected rtt to become longer, that would make sense. I expected lost packets, that would make sense. What I see doesn't make sense, at least to me.
 
  • #17
Yeah, you're right. If the delay occurs after the packet has left the system (local switches or external WAN) the rtt must get longer, the system would record a delay. The only thing that I can think of which still fits is that the system waited a lot longer than 1 second between sending out pings. But why would the rest of your network also look slow?

I'm speculating here but perhaps the switches downgraded your link speeds to 10mbps, some interference perhaps or maybe your uplink tanked (i've noticed this with cable connections sometimes). Your pings would probably still come back just as fast, the packet is too small to notice any real difference but all the systems would have to wait longer corresponding to a "hiccup" as you called it. Once the interference was gone, all the switches are back up to 100/1000mbps

A trace route from back then would have probably answered that question.
 
  • #18
Have you tried using Wireshark to gather information about your computers data transmissions?
 
  • #19
Not yet. I asked provider for help, they said they changed hardware on their side, since then things seem to be working OK.
 

What do ping results mean?

Ping results show the response time between your computer and a server or website. It is measured in milliseconds (ms) and a lower number indicates a faster response time.

Why do I have high ping results?

High ping results can be caused by a slow internet connection, network congestion, or a large distance between your computer and the server. It can also be due to a high number of devices connected to your network or outdated network hardware.

What is a good ping result?

A good ping result is typically less than 100ms. However, it can vary depending on your location and internet connection. Lower ping results indicate a faster and more stable connection.

Why do my ping results vary?

Ping results can vary due to a number of factors such as network congestion, server load, and distance between your computer and the server. It is also possible that your internet service provider has different routing paths for different websites, resulting in varying ping results.

Can ping results be improved?

Yes, ping results can be improved by upgrading your internet connection to a faster speed, using a wired connection instead of wireless, and reducing the number of devices connected to your network. It can also help to optimize your network settings and update your network hardware.

Similar threads

STOP: 0x0000008E (0xC000005, 0XBF04DF7B, 0xED924B18 0X000000000)
    • Computing and Technology
Replies
23
Views
5K
6 months after dropping out of college - my tips
    • STEM Career Guidance
2
Replies
37
Views
13K

Hot Threads

Recent Insights

Back
Top