Os testes de ping respondem instantaneamente, mas relatam enormes tempos de resposta

Question

Ainda estou tentando confirmar minha hipótese de que esse problema pode estar isolado em servidores hospedados no mesmo host Hyper-V físico, mas certamente pelo menos encontrei casos freqüentes, embora intermitentes, de tentativa de pingar alguns meus servidores de alguns dos meus outros servidores e recebendo respostas bizarras. A ferramenta padrão de ping do Windows instantaneamente (de longe, muito mais rápido do que você esperaria por um tempo de resposta de < 1ms) informa todas as quatro respostas, com números nas dezenas de milhares de ms.

A execução de ping -n 1000 fs1.nisgaa.net > ping-fs1.log foi concluída em cerca de 10 a 15 segundos.

1. The first line: Reply from 10.3.0.17: bytes=32 time=85546ms TTL=128
2. The next ~450:  Reply from 10.3.0.17: bytes=32 time=63979ms TTL=128
3. The next two:   Reply from 10.3.0.17: bytes=32 time<1ms TTL=128 (these lines actually take a second to spit out, unlike the above, which appear instantly)
4. Next two:       Reply from 10.3.0.17: bytes=32 time=85546ms TTL=128
5. Next two:       Reply from 10.3.0.17: bytes=32 time<1ms TTL=128
6. Next one:       Reply from 10.3.0.17: bytes=32 time=63980ms TTL=128
7. Next five:      Reply from 10.3.0.17: bytes=32 time<1ms TTL=128
8. Next three:     Reply from 10.3.0.17: bytes=32 time=91472ms TTL=128
9. Next ~75:       Reply from 10.3.0.17: bytes=32 time=63980ms TTL=128
0. Next four:      Reply from 10.3.0.17: bytes=32 time<1ms TTL=128
1. Next one:       Reply from 10.3.0.17: bytes=32 time=85546ms TTL=128
2. Next one:       Reply from 10.3.0.17: bytes=32 time<1ms TTL=128
3. Next one:       Reply from 10.3.0.17: bytes=32 time=85546ms TTL=128
4. Next 15:        Reply from 10.3.0.17: bytes=32 time=63980ms TTL=128

E assim por diante, com grandes e repetitivas partes que afirmam levar minutos, mas são reportadas instantaneamente, seguidas por um pequeno grupo de < Respostas de 1 ms, como seria de esperar.

Alguma idéia do que poderia causar algo assim?

    

Answer 1

Pequenas quantidades de tempo podem ser muito difíceis de medir em uma VM, pois os processadores virtuais não são executados continuamente. Eu não ficaria surpreso se os cálculos de tempo fossem descartados.

Se eles forem realmente informados instantaneamente, as medições de 64 a 85 segundos estarão claramente erradas.

    

Answer 2

Eu tenho tido exatamente o mesmo problema e encontrei o seguinte post no blog:

link

Just a quick blog post that might help you resolve an issue that some customers have seen running under Hyper-V VM's. The issue is negative ping times on multi-processor guests.

If you see negative ping times in multiprocessor W2k3 guest OSes you might consider setting the /usepmtimer in the boot.ini file.

The root issue comes about from the Win32 QueryPerformanceCounter function. By default it uses a time source called the TSC. This is a CPU time source that essentially counts CPU cycles. The TSC for each (virtual) processor can be different so there is no guarantee that reading TSC on one processor has anything to do with reading TSC on another processor. This means back to back reads of TSC on different VP's can actually go backwards. Hyper-V guarantees that TSC will not go backwards on a single VP.

So here the problem with negative ping times is the time source is using QueryPerformanceCounter which is using TSC. By using the /usepmtimer boot.ini flag you change the time source for QueryPerformanceCounter from TSC to the PM timer which is a global time source.

Os sintomas também afetam qualquer coisa que dependa de QueryPerformanceCounter , como a classe dot net System.Diagnostics.StopWatch .

Atualização - nossa equipe de TI amigável atualizou nossas máquinas virtuais de acordo com as instruções e corrigiu o problema.