Я все еще пытаюсь подтвердить свою гипотезу о том, что эта проблема может быть изолирована на серверах, размещенных на одном физическом хосте Hyper-V, но, по крайней мере, я обнаружил частые, хотя и прерывистые, случаи попыток проверки связи с некоторыми из моих серверов с некоторые из моих других серверов и получаю странные ответы. Стандартный инструмент проверки связи Windows мгновенно (намного быстрее, чем можно было бы ожидать при времени ответа <1 мс) сообщит обо всех четырех ответах с числами в десятки тысяч мс.
Бег ping -n 1000 fs1.nisgaa.net > ping-fs1.log выполняется примерно за 10-15 секунд.
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
И так далее, с большими повторяющимися фрагментами, которые, как он утверждает, занимают минуты, но сообщаются мгновенно, за которыми следует небольшая горстка ответов <1 мс, как я и ожидал.
Есть идеи вообще, что могло вызвать что-то подобное?
У меня была такая же проблема, и я нашел следующее сообщение в блоге:
http://blogs.msdn.com/b/tvoellm/archive/2008/06/05/negative-ping-times-in-windows-vm-s-whats-up.aspx
Просто небольшое сообщение в блоге, которое может помочь вам решить проблему, с которой некоторые клиенты сталкивались при работе с виртуальными машинами Hyper-V. Проблема заключается в отрицательном времени пинга на гостевых системах с несколькими процессорами.
Если вы видите отрицательное время пинга в многопроцессорных гостевых ОС W2k3, вы можете подумать о том, чтобы установить / usepmtimer в файле boot.ini.
Основная проблема возникает из-за функции Win32 QueryPerformanceCounter. По умолчанию он использует источник времени, называемый TSC. Это источник времени ЦП, который по сути считает циклы ЦП. TSC для каждого (виртуального) процессора может быть разным, поэтому нет гарантии, что чтение TSC на одном процессоре имеет какое-либо отношение к чтению TSC на другом процессоре. Это означает, что обратное чтение TSC на разных VP может фактически идти в обратном направлении. Hyper-V гарантирует, что TSC не вернется назад на одном VP.
Итак, проблема с отрицательным временем пинга заключается в том, что источник времени использует QueryPerformanceCounter, который использует TSC. Используя флаг / usepmtimer boot.ini, вы меняете источник времени для QueryPerformanceCounter с TSC на таймер PM, который является глобальным источником времени.
Симптомы также влияют на все, что связано с QueryPerformanceCounter, например точечная сеть System.Diagnostics.StopWatch класс.
Обновить - наш дружелюбный ИТ-специалист обновил наши виртуальные машины в соответствии с инструкциями и устранил проблему.
Небольшие промежутки времени в виртуальной машине очень сложно измерить, поскольку виртуальные процессоры не работают постоянно. Я не удивлюсь, если расчеты времени будут сброшены.
Если они действительно сообщаются мгновенно, то измерения от 64 до 85 секунд явно неверны.