medir a latência unidirecional / tremulação / perda de pacotes

Estou obtendo maior latência e StDev devido ao congestionamento de rotas e perda de pacotes , mas os caminhos de avanço e reverso percorrem redes distintas (por exemplo, uma sendo init7.net, a outra sendo he.net), portanto, é muito difícil entender qual rede ou host é responsável pelo congestionamento, perda de pacotes, tremulação e latência aumentada.

Existe uma maneira de diminuir a culpa depois que a frente e a ré mtrnão conseguem identificar o culpado exato, e os contatos do NOC @ não respondem ou alegam não sofrer nenhuma perda no caminho em questão? (Estou usando o OpenBSD.)

Eu até tentei fazer um contato mtrdireto com alguns clientes das duas redes que podem estar enfrentando o congestionamento, mas não consegui encontrar nenhum problema dessa maneira, especialmente porque, por exemplo, o he.net tem muitos POPs e, muitas vezes, rotas distintas são tomadas entre uma determinada entrada e o POP de saída; portanto, quando tento mtrseus hosts (como o tserv) diretamente no POP de saída no qual eu possa estar perdendo pacotes na rede, um caminho he.net diferente é usado para alcançar o mesmo POP, e nenhuma perda de pacote ocorre, o que não prova nada de interessante (exceto uma possível sugestão de que eles possam realmente sobrecarregar algumas rotas, garantindo que outras permaneçam desinteressadas, ignorando todas as solicitações NOC @ de não clientes).

Uma maneira de fazer isso é o carimbo de data / hora do ICMP, que é milissegundos a partir da meia-noite UTC. Ele tem o benefício adicional de que você não precisa necessariamente controlar as duas extremidades, desde que a extremidade remota não seja protegida por firewall, há boas chances de funcionar.

No entanto, para obter medições unidirecionais confiáveis, é necessário o mesmo tempo confiável nas duas extremidades. Como o registro de data e hora do ICMP possui precisão de apenas 1ms (o que não é suficiente para muitos aplicativos, mas é suficiente para isso), é razoavelmente fácil encontrar hosts que não colaboram, nos quais o registro de data e hora do ICMP fornece dados úteis.

Se você controlar as duas extremidades, verifique se está sincronizando o NTP com apenas 1 servidor e o mesmo servidor. O relógio absoluto não é muito importante, é apenas importante que você experimente o mais próximo possível do mesmo tempo.

Se o registro de data e hora do ICMP não for suficiente, é muito fácil escrever 10 linhas de ruby ​​/ perl / python ou até C para fazer medições quando você controlar as duas extremidades.

Eu realmente não posso sugerir software para fazer medições de carimbo de data / hora ICMP unidirecionalmente, o hping2 suporta o envio de carimbo de data / hora ICMP, mas por algum motivo não gera valores unidirecionais. Eu escrevi o patch para o hping2 para exibir as latências de sentido único.