Explanation to ping latency please :D :D :D :{
-
So I am NOT a network guru.. and this does not make sense to me at all.
When I try to ping a workstation I received <1ms average.
When I try to ping a switch I received <1ms to =6ms. average at 2-3ms
When I try to ping our phone system I received =1ms to =5ms. average at 3-4ms.What does this mean?
-
@LAH3385 said:
So I am NOT a network guru.. and this does not make sense to me at all.
When I try to ping a workstation I received <1ms average.
When I try to ping a switch I received <1ms to =6ms. average at 2-3ms
When I try to ping our phone system I received =1ms to =5ms. average at 3-4ms.What does this mean?
Latency is the amount of time that it takes for the device to respond over the network. It's a combined number of the network time and the time for the device to respond. On a local LAN, the delays are typically caused by the device being busy and unable to respond immediately. On a WAN the latency is normally caused by network traversal time.
The range of numbers is exactly what it says, it is the range of response times from a number of pings. The average is a mean overage of the response times.
-
Here is a ping of my laptop to the home router:
scott@1207-scott ~ $ ping 192.168.1.254 PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data. 64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=0.928 ms 64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=0.960 ms 64 bytes from 192.168.1.254: icmp_seq=3 ttl=64 time=0.922 ms 64 bytes from 192.168.1.254: icmp_seq=4 ttl=64 time=0.914 ms 64 bytes from 192.168.1.254: icmp_seq=5 ttl=64 time=0.933 ms 64 bytes from 192.168.1.254: icmp_seq=6 ttl=64 time=0.972 ms 64 bytes from 192.168.1.254: icmp_seq=7 ttl=64 time=0.826 ms 64 bytes from 192.168.1.254: icmp_seq=8 ttl=64 time=0.927 ms 64 bytes from 192.168.1.254: icmp_seq=9 ttl=64 time=4.58 ms 64 bytes from 192.168.1.254: icmp_seq=10 ttl=64 time=1.95 ms 64 bytes from 192.168.1.254: icmp_seq=11 ttl=64 time=0.840 ms 64 bytes from 192.168.1.254: icmp_seq=12 ttl=64 time=0.803 ms 64 bytes from 192.168.1.254: icmp_seq=13 ttl=64 time=0.871 ms 64 bytes from 192.168.1.254: icmp_seq=14 ttl=64 time=0.966 ms 64 bytes from 192.168.1.254: icmp_seq=15 ttl=64 time=0.960 ms 64 bytes from 192.168.1.254: icmp_seq=16 ttl=64 time=0.949 ms 64 bytes from 192.168.1.254: icmp_seq=17 ttl=64 time=1.78 ms 64 bytes from 192.168.1.254: icmp_seq=18 ttl=64 time=1.25 ms 64 bytes from 192.168.1.254: icmp_seq=19 ttl=64 time=0.845 ms ^C --- 192.168.1.254 ping statistics --- 19 packets transmitted, 19 received, 0% packet loss, time 18018ms rtt min/avg/max/mdev = 0.803/1.220/4.585/0.850 ms
Each link is one ping attempt, that's the raw data. The final line is the summary. There were 19 pings sent. 100% worked, so there is 0% loss. Total time for this ping cycle was 18.018 seconds.
The minimum latency that I saw was .803 milliseconds. The average was 1.22ms. And the largest latency was 4.585 ms. The mean deviation was .850ms for the statisticians.
-
@LAH3385 said:
So I am NOT a network guru.. and this does not make sense to me at all.
When I try to ping a workstation I received <1ms average.
When I try to ping a switch I received <1ms to =6ms. average at 2-3ms
When I try to ping our phone system I received =1ms to =5ms. average at 3-4ms.What does this mean?
Pretty normal your phone system likely processing sip traffic and causes the slight delay for pings. It may even be setup to proiritize traffic so pings can handle less preferentially than its SIP traffic.
-
@Jason said:
@LAH3385 said:
So I am NOT a network guru.. and this does not make sense to me at all.
When I try to ping a workstation I received <1ms average.
When I try to ping a switch I received <1ms to =6ms. average at 2-3ms
When I try to ping our phone system I received =1ms to =5ms. average at 3-4ms.What does this mean?
Pretty normal your phone system likely processing sip traffic and causes the slight delay for pings. It may even be setup to proiritize traffic so pings can handle less preferentially than its SIP traffic.
One hopes, in fact, that a phone will deprioritize anything but the RTP voice traffic.