Eu tenho uma VM ESXi que executa comandos em alguns dispositivos de 700 ~ em nossa rede. Está usando Expect, e devido à idade deste equipamento eles têm períodos de baixo desempenho. Esses dois não se misturam bem - pois o script Expect terá que esperar muito tempo para obter a saída antes de prosseguir.
Para tentar evitar isso, nossa equipe decidiu que um pingteste deveria ser feito antes de conectar ao dispositivo. Se houver perda de pacotes, voltaremos a isso mais tarde.
O problema que estamos tendo é que nosso teste de ping se parece com isso:
loss=`ping -i 0.2 -w 2 $1 | grep "packet loss" | awk '{print $6}'`
loss=${loss%?}
echo "$loss"
10 pings em dois segundos - mas recebemos muitas respostas de perda de pacotes de 9% . Por exemplo, geralmente temos testes 74/700 saindo preventivamente devido à detecção de perda de pacotes. 39/74 desses relatam 9% , enquanto o restante relata em múltiplos de 10.
Até onde podemos dizer, isso não faz sentido; há 10 pacotes sendo enviados... se um for descartado, deve haver uma perda de 10%. Isso tem sido observado com pouca frequência, mas acontece. É possível que haja algo acontecendo na memória que esteja fazendo com que o número 9 se manifeste? Se estes são casos legítimos de perda de pacotes, então é uma grande notícia para nós.
Existem várias versões de ping. Alguns têm a
-wopção. Alguns aceitam, mas não são documentados. Em algumas versões do ping, isso acontece:Ou seja: um pacote é emitido, o tempo expira e nunca é recebido de volta.
Assim: 1 pacote de 11 foi perdido, isso é 9% de perda.
Com essas versões de ping, adicionar uma
-copção deve resolver o problema:Isso significa: tente pacotes a cada 0,2 segundos até que 10 pacotes tenham sido recebidos ou até que um limite de tempo de 5 segundos tenha decorrido.