1

I encountered a weird problem that the response time returned by ping is almost fixed at 98ms.

Either I ping the gateway, or I ping a local host or a internet host. The response time is always around 98ms although the actual delay is obvious.

However, the reverse ping (from a local machine to this host) works properly.

The following is my route table and the result:

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    100    0        0 eth1
60.194.136.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

# ping the gateway
ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=98.7 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=97.0 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=96.0 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=94.9 ms
64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=94.0 ms
^C
--- 192.168.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 94.030/96.149/98.744/1.673 ms 

#ping a local machine
ping 192.168.1.88
PING 192.168.1.88 (192.168.1.88) 56(84) bytes of data.
64 bytes from 192.168.1.88: icmp_req=1 ttl=64 time=98.7 ms
64 bytes from 192.168.1.88: icmp_req=2 ttl=64 time=96.9 ms
64 bytes from 192.168.1.88: icmp_req=3 ttl=64 time=96.0 ms
64 bytes from 192.168.1.88: icmp_req=4 ttl=64 time=95.0 ms
^C
--- 192.168.1.88 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 95.003/96.696/98.786/1.428 ms

#ping a internet host
 ping google.com
PING google.com (74.125.128.139) 56(84) bytes of data.
64 bytes from hg-in-f139.1e100.net (74.125.128.139): icmp_req=1 ttl=42 time=99.8 ms
64 bytes from hg-in-f139.1e100.net (74.125.128.139): icmp_req=2 ttl=42 time=99.9 ms
64 bytes from hg-in-f139.1e100.net (74.125.128.139): icmp_req=3 ttl=42 time=99.9 ms
64 bytes from hg-in-f139.1e100.net (74.125.128.139): icmp_req=4 ttl=42 time=99.9 ms
^C64 bytes from hg-in-f139.1e100.net (74.125.128.139): icmp_req=5 ttl=42 time=99.9 ms

--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 32799ms
rtt min/avg/max/mdev = 99.862/99.925/99.944/0.284 ms

I am running iperf to test the bandwidth, the rate is quite low for a LAN connection. 

iperf -c 192.168.1.87 -t 50 -i 10 -f M
------------------------------------------------------------
Client connecting to 192.168.1.87, TCP port 5001
TCP window size: 0.06 MByte (default)
------------------------------------------------------------
[  4] local 192.168.1.139 port 54697 connected with 192.168.1.87 port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  6.12 MBytes  0.61 MBytes/sec
[  4] 10.0-20.0 sec  6.38 MBytes  0.64 MBytes/sec
[  4] 20.0-30.0 sec  6.38 MBytes  0.64 MBytes/sec
[  4] 30.0-40.0 sec  6.25 MBytes  0.62 MBytes/sec
[  4] 40.0-50.0 sec  6.38 MBytes  0.64 MBytes/sec
[  4]  0.0-50.1 sec  31.6 MBytes  0.63 MBytes/sec
steveyang
  • 673
  • 4
  • 10
  • 16
  • Do you experience high delays in other protocols? – Khaled Apr 04 '12 at 07:05
  • How to test those? I could put the result here. – steveyang Apr 04 '12 at 07:10
  • For example, you can try to transfer a big file from one machine to another. – Khaled Apr 04 '12 at 07:11
  • @Khaled: transfering a big file is all about measuring bandwidth, slow start scaling, and window scaling - latency is an important factor in throughput - but far from the only determinant. – symcbean Apr 04 '12 at 07:44
  • netperf returns latency/RTT information for UDP or TCP workloads. Needs to be run on two machines, though. You do not have some kind of QoS or net delay emulation mechanism in place by any chance? `tc -s class list dev eth0`, `tc -s qdisc list dev eth0` – the-wabbit Apr 04 '12 at 07:47
  • @symcbean I agree. And also the problem here is not about real network lag, but the effective measurement provided by `ping`. In the case of `ping google.com` the summarize has **5 packets transmitted, 5 received, 0% packet loss, time 32799ms** but the ping response time is still `98ms`. – steveyang Apr 04 '12 at 07:48
  • in this case this might simply be a bug in your implementation of ping. Have you tried `traceroute` to see if it exposes the same kind of problem? – the-wabbit Apr 04 '12 at 07:56
  • @syneticon-dj thx to the hints. **Firstly of all**, I have enabled QoS on the local route - but as the ping initiated from other local machine works properly. I didn't think it is the cause of the problem. After I turned the QoS down, the same problem persists. **Secondly**, I tried `traceroute` which works properly with one hop ` 1 192.168.1.1 (192.168.1.1) 97.892 ms 97.883 ms 97.876 ms` – steveyang Apr 04 '12 at 08:02
  • @syneticon-dj I've ran `iperf` and the result is quite low. (5-6Mbps). Another hint I got is that: when I reboot the machine, the `ping` response and bandwidth is normal. But it will stop responding to `ping` for a while and then start this lagging problem. – steveyang Apr 04 '12 at 08:08
  • Why you expect different ping times between gateway and a local machine - aren't they on the same LAN segment ? – Sandman4 Apr 04 '12 at 09:01
  • @Sandman4 There are on the same LAN `192.168.1.0/24`. I didn't expect a different one but a normal one (98ms) is innormal. But main problem is that even ping to a external service (google.com), the ping value is the same. – steveyang Apr 04 '12 at 09:05
  • and traceroute to google is also 1 hop ? – Sandman4 Apr 04 '12 at 09:14
  • It is something weirdy as every hop costs equally hours. Is there something wrong with the `ping` program? `traceroute to google.com (74.125.128.113), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 99.774 ms 99.767 ms 99.760 ms 2 218.249.152.201 (218.249.152.201) 99.777 ms 99.771 ms 99.766 ms 3 218.241.239.137 (218.241.239.137) 99.760 ms 99.755 ms 99.749 ms 4 124.205.98.201 (124.205.98.201) 99.708 ms 99.707 ms 99.701 ms` – steveyang Apr 04 '12 at 09:21
  • Can you try a different machine on that same switch port? Might be something misconfigured upstream from your machine (like a broadcast storm on the switch, misconfigured STP, etc.). – gravyface Apr 11 '12 at 21:34

2 Answers2

2

ping will try to do a DNS PTR query for the IP addresses, which may be the delay you're seeing. Run ping -n to disable.

You could also be seeing different behaviour for non-ICMP traffic. Try using hping to send UDP and TCP packets on various ports to check this.

mgorven
  • 30,615
  • 7
  • 79
  • 122
1

iperf udp mode is more representative of the actual frame transition latency and failure rate.

some of the session-oriented tcp tests gloss over loss.

there are also some cool things you can do with iperf like jitter measurements.

http://openmaniak.com/iperf.php

user145837
  • 371
  • 5
  • 18