O pipevalor na saída de pingindica o número máximo de pacotes de solicitação de eco ICMP não atendidos pendentes na rede em algum momento durante o teste. Normalmente, não é relatado quando esse valor é um (cada solicitação recebeu uma resposta antes do envio da próxima solicitação), como é o caso da operação normal.
Por padrão, o pingcomando espera um segundo entre o envio de solicitações de eco, conforme a descrição em sua página de manual, sob o -iparâmetro:
O padrão é esperar um segundo entre cada pacote normalmente ou não esperar no modo de inundação. Somente o superusuário pode definir o intervalo para valores inferiores a 0,2 segundos.
Na maioria das redes, o tempo de ida e volta (RTT) geralmente é da ordem de dezenas ou centenas de milissegundos, não segundos. Portanto, nesse modo padrão, cada solicitação de eco normalmente recebe uma resposta antes que a solicitação a seguir seja enviada. O número máximo de pacotes pendentes na rede não é maior que um em qualquer ponto do teste; portanto, pipeé igual a 1 e não é relatado.
Se o tempo de resposta a um pacote subir acima desse intervalo padrão por algum motivo, fazendo com que várias solicitações sejam destacadas na rede, o ping reportará um número pipemaior que um. Da mesma forma, você pode invocar essa resposta reduzindo artificialmente o intervalo passando um valor menor que o RTT para o -iparâmetro de ping.
Se o sistema de rede for local, então:
- seus testes estão reduzindo o intervalo para emitir pings
- você ativou o modo de inundação , que não espera por uma resposta antes de enviar outro ping
- as respostas estão demorando um pouco para voltar ao sistema de teste a partir do host remoto
Se isso é indicativo de um problema maior, depende do cenário, do hardware da rede, da pingconfiguração etc.
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3014msepipe 3em diferentes linhas que confundiu o meu código Java que tenta analisá-lo