Eu encontrei um problema estranho que o tempo de resposta retornado por ping está quase corrigido em 98ms .
Ou eu ping do gateway, ou eu pingar um host local ou um host da Internet. O tempo de resposta é sempre em torno de 98ms , embora o atraso real seja óbvio.
No entanto, o ping reverso (de uma máquina local para este host) funciona corretamente.
Veja a seguir minha tabela de rotas e o resultado:
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
Estou executando iperf para testar a largura de banda, a taxa é muito baixa para uma conexão de rede local.
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
ping tentará fazer uma consulta de PTR de DNS para os endereços IP, que pode ser o atraso que você está vendo. Execute ping -n para desativar.
Você também pode estar vendo um comportamento diferente para o tráfego não-ICMP. Tente usar hping para enviar pacotes UDP e TCP em várias portas para verificar isso.
O modo iperf udp é mais representativo da latência de transição de quadros e da taxa de falhas.
alguns dos testes tcp orientados por sessão encobrem a perda.
também há algumas coisas legais que você pode fazer com o iperf como medições de jitter.
Tags ping nat route local-area-network