Перейти к содержимому

Отрицательное время пинга?

15

Это первый раз, когда я видел это, и я не уверен, что это значит;

64 bytes from 74.125.93.99: icmp_seq=6233 ttl=53 time=545.493 ms  64 bytes from 74.125.93.99: icmp_seq=6234 ttl=53 time=776.093 ms  64 bytes from 74.125.93.99: icmp_seq=6235 ttl=53 time=-705.731 ms  64 bytes from 74.125.93.99: icmp_seq=6236 ttl=53 time=52.549 ms  64 bytes from 74.125.93.99: icmp_seq=6237 ttl=53 time=44.470 ms  

Кто-нибудь когда-нибудь видел отрицательный пинг раньше? Мой друг сказал мне, что он видел это однажды по беспроводной связи, и это было по беспроводной связи, но .. как это происходит?

8 476 просмотров
Jeff Welling спросил 15 лет назад
J 325

4 ответа

15
Принятый ответ

NTP или служба времени Windows синхронизировали системные часы во время пинга?

Отличный вопрос, это может быть. К сожалению, я точно не помню, в какое время я выполнял эхо-запрос, поэтому я не могу проверить журналы для синхронизации NTP, которая выстраивается.

Jeff Welling · 15 лет назад · 0

Это было бы чертовски странно, но +1 за отличный пункт для устранения неполадок.

mbb · 15 лет назад · 0

Без лучшего ответа и неспособности найти более правдоподобное решение с тех пор, как это произошло до сих пор, я принимаю этот ответ, потому что я думаю, что это наиболее вероятное объяснение того, как это произошло. Благодарю.

Jeff Welling · 15 лет назад · 0

Я только что столкнулся с той же проблемой на виртуальной машине и могу подтвердить, что проблема была в NTP, исправляющем смещение времени. service ntpd stop на CentOS исправил это (но, очевидно, создаст другие проблемы). См. Этот очень интересный вопрос для получения дополнительной информации.

Benjamin · 14 лет назад · 0
Hydaral ответил 15 лет назад
H 1 626
4

Мне трудно в это поверить, но это обсуждение, кажется, указывает на то, что это поведение определенных процессоров AMD.

Лично я не стал бы беспокоиться об этом и предположил бы, что это концептуальный недостаток в ICMP ... Может быть, пакет, который прошел по другому пути, или что-то странное, включающее машины / маршрутизаторы с разными часами.

Из связанного обсуждения я бы не стал склоняться к концептуальному недостатку в ICMP. Похоже, что AMD имеет сдвиг часов между двумя ядрами, что вызывает отрицательную интерпретацию времени.

Evan · 15 лет назад · 2

@evan: Но 0,7 секунды - это * огромное * несоответствие!

Mechanical snail · 15 лет назад · 0

отчет, который вы получаете от ping, не имеет ничего общего с часами на внешних маршрутизаторах, это разница во времени, когда пакет отправляется по назначению, а ответ принимается обратно на хост. Это синхронизировано хозяином.

MaQleod · 15 лет назад · 2

@ Механическая улитка. Вы правы, это очень много, но связанная с этим дискуссия говорит, что перекос со временем растет. Если процессор работал в течение длительного периода времени, 0,7 секунды не слишком абсурдно. Было бы интересно увидеть, если проблема возникает только после того, как процессор некоторое время работал.

Evan · 15 лет назад · 0

@Evan: Я имею в виду, что 0,7 секунды могут привести к более серьезным ошибкам, чем это, поэтому мы, вероятно, уже слышали об этом.

Mechanical snail · 15 лет назад · 0
James T Snell ответил 15 лет назад
J 5 558
1

Я считаю, что это ошибка в способе, которым pingкоманда умножает пакеты и усугубляется процессорами AMD больше, чем Intel.

Функции, которые используются для синхронизации высокого разрешения в окнах QueryPerformanceCounterи QueryPerformanceFrequency.

К сожалению, они не работают для многоядерных процессоров, поскольку эти процессоры не возвращают одинаковые числа.

Исправление для ping - установить сродство потока в ping. Я сомневаюсь, что это делает это, которое объяснило бы отрицательный выбор времени. Есть также патчи от AMD и MS, которые должны помочь разобраться.

Matt H ответил 14 лет назад
M 3 368
1

Unfortunately, this is not limited to AMD processors, but it seems to affect XP quite a bit. To date, and after a few years of searching for answers, I know a quick fix, but I can't do it to servers that won't reappear by remote after booting.

To reset TCP/IP (and timings), open an admin CMD window and enter the following:

ipconfig /flushdns arp -d gpupdate /force netsh int ip reset null netsh winsock reset 

Now, you MUST reboot. Network adapter reverts to DHCP, so beware remoters.

So what happens here?

For some reason, TCP/IP has a time stamp it uses to calculate timing, and it gets fudged somehow. I used to see it all the time at one location, but it's finally stopped. Unfortunately, it continues at the warehouse I manage. Tonight, all points seem to be stuck at 237ms, but 2 popped back with multiple pings.

pingpath is a very handy utility, and I will be using this more often. Unfortunately, it came up with the same results...

Sad thing, this clears ping miscounts in games also.

note- if you want to see the log file, replace null with a filename, such as c:\log.txt -- Null just means no file (technically)

Jeff Mathews ответил 12 лет назад
J 11