Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Ping results I don't understand

Tags:
  1. Oct 5, 2014 #1

    Borek

    User Avatar

    Staff: Mentor

    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 (Text):

    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?
     
  2. jcsd
  3. Oct 6, 2014 #2

    Borg

    User Avatar
    Gold Member

    Last edited: Oct 6, 2014
  4. Oct 6, 2014 #3

    Borek

    User Avatar

    Staff: Mentor

    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.
     
  5. Oct 6, 2014 #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?
     
  6. Oct 6, 2014 #5

    Filip Larsen

    User Avatar
    Gold Member

    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.
     
  7. Oct 6, 2014 #6

    Borek

    User Avatar

    Staff: Mentor

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

    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.
     
  8. Oct 7, 2014 #7

    jim mcnamara

    User Avatar

    Staff: Mentor

    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.
     
  9. Oct 7, 2014 #8

    Borek

    User Avatar

    Staff: Mentor

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

    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 (Text):

    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?
     
  10. Oct 7, 2014 #9

    jim mcnamara

    User Avatar

    Staff: Mentor

    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.
     
  11. Oct 8, 2014 #10

    FactChecker

    User Avatar
    Science Advisor
    Gold Member

    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.
     
  12. Oct 8, 2014 #11

    Borek

    User Avatar

    Staff: Mentor

    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.
     
  13. Oct 8, 2014 #12

    Borek

    User Avatar

    Staff: Mentor

    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.
     
  14. Oct 8, 2014 #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.
     
  15. Oct 8, 2014 #14

    Borek

    User Avatar

    Staff: Mentor

    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
     
  16. Oct 8, 2014 #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.
     
  17. Oct 8, 2014 #16

    Borek

    User Avatar

    Staff: Mentor

    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.
     
  18. Oct 8, 2014 #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.
     
  19. Oct 27, 2014 #18
    Have you tried using Wireshark to gather information about your computers data transmissions?
     
  20. Oct 28, 2014 #19

    Borek

    User Avatar

    Staff: Mentor

    Not yet. I asked provider for help, they said they changed hardware on their side, since then things seem to be working OK.
     
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook




Similar Discussions: Ping results I don't understand
  1. I dont understand (Replies: 3)

  2. The pages I don't like (Replies: 1)

  3. Ping triangulation (Replies: 5)

  4. Is pingging harmful? (Replies: 2)

  5. Ping help (Replies: 4)

Loading...