Tiempo de ping negativo?

15

Esta es la primera vez que veo esto y no estoy seguro de lo que significa;

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

¿Alguien ha visto un tiempo de ping negativo antes? Un amigo mío me dijo que lo vio una vez en un enlace inalámbrico, y esto fue a través de una conexión inalámbrica, pero ... ¿cómo sucede eso?

networking wireless-networking ping latency Jeff Welling
fuente
44
¿Tienes un procesador AMD?
MaQleod
99
Solo una grieta temporal en el continuo espacio-tiempo. Nada de que preocuparse. ¿Dónde puse las llaves de mi DeLorean?
malabarista
No recuerdo específicamente en qué máquina ejecuté la prueba, pero los únicos 3 en los que podría haberlo ejecutado son todos Intel (una computadora de escritorio Intel, una Macbook Pro, una Mac Mini).
Jeff Welling
12
El ping lag negativo es una falla en la matriz. Sucede cuando cambian algo.
James T Snell

Respuestas:

15

¿NTP o Windows Time Service sincronizaron el reloj del sistema durante el ping?

Hydaral
fuente
Excelente pregunta, esa podría ser. Desafortunadamente, no recuerdo exactamente a qué hora hice el ping, así que no puedo verificar los registros para una sincronización NTP que se alinea.
Jeff Welling
Sería extraño, pero +1 para un excelente punto de solución de problemas.
mbb
Sin una mejor respuesta proporcionada, y al no poder llegar a una solución más plausible desde el momento en que esto sucedió hasta ahora, acepto esta respuesta porque creo que es la explicación más probable de cómo sucedió esto. Gracias.
Jeff Welling
Acabo de encontrar el mismo problema en una máquina virtual y puedo confirmar que el problema fue la corrección de NTP. service ntpd stopen CentOS solucionó eso (pero creará otros problemas, obviamente). Vea esta pregunta muy interesante para más información.
Benjamin
4

Me resulta difícil de creer, pero esta discusión parece indicar que este es el comportamiento de ciertas CPU AMD.

Personalmente, no me preocuparía y asumiría que es una falla conceptual en ICMP ... Tal vez un paquete que pasó por un camino diferente o algo extraño que involucra máquinas / enrutadores con sus relojes configurados de manera diferente.

James T Snell
fuente
2
De la discusión vinculada, no me inclinaría hacia la falla conceptual en ICMP. Parece que AMD tiene un sesgo de reloj entre los dos núcleos, lo que provoca la interpretación negativa de la hora.
Evan
@evan: ¡Pero 0.7 segundos es una gran discrepancia!
Caracol mecánico
2
el informe que obtiene del ping no tiene nada que ver con los relojes en los enrutadores externos, es la diferencia en el tiempo desde el momento en que el paquete se envía a su destino y la respuesta se recibe de nuevo al host. Es registrado por el anfitrión.
MaQleod
@ Caracol mecánico Tienes razón, eso es extremadamente grande, pero la discusión vinculada dice que el sesgo crece con el tiempo. Si el procesador ha estado funcionando durante un período prolongado de tiempo, 7 segundos no es demasiado absurdo. Sería interesante ver si el problema solo surge después de que el procesador ha estado funcionando durante un tiempo.
Evan
@Evan: Quiero decir que 0.7 segundos pueden causar errores más serios que esto, por lo que probablemente ya hayamos oído hablar de eso.
Caracol mecánico
1

Desafortunadamente, esto no se limita a los procesadores AMD, pero parece afectar bastante a XP. Hasta la fecha, y después de algunos años de buscar respuestas, conozco una solución rápida, pero no puedo hacerlo en servidores que no volverán a aparecer de forma remota después del arranque.

Para restablecer TCP / IP (y tiempos), abra una ventana de administrador CMD e ingrese lo siguiente:

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

Ahora, DEBE reiniciar. El adaptador de red vuelve a DHCP, así que tenga cuidado con los controles remotos.

Entonces, ¿qué pasa aquí?

Por alguna razón, TCP / IP tiene una marca de tiempo que utiliza para calcular el tiempo, y de alguna manera se falsifica. Solía ​​verlo todo el tiempo en un lugar, pero finalmente se detuvo. Desafortunadamente, continúa en el almacén que administro. Esta noche, todos los puntos parecen estar atascados en 237 ms, pero 2 volvieron a aparecer con múltiples pings.

pingpathes una utilidad muy útil, y la usaré más a menudo. Desafortunadamente, se obtuvieron los mismos resultados ...

Lo triste es que esto también elimina los errores de ping en los juegos.

nota: si desea ver el archivo de registro, reemplace nulo con un nombre de archivo, como c:\log.txt - Nulo solo significa que no hay archivo (técnicamente)

Jeff Mathews
fuente
1

Creo que es un error en la forma en que el pingcomando cronometra los paquetes y se ve agravado por los procesadores AMD más que por Intel.

Las funciones que se utilizan para la sincronización de alta resolución en Windows son QueryPerformanceCountery QueryPerformanceFrequency.

Desafortunadamente, están rotos para los procesadores multi-core ya que estos procesadores no devuelven los mismos números.

La solución para hacer ping es establecer la afinidad de hilo en ping. Dudo que esté haciendo esto lo que explicaría el momento negativo. También hay parches de AMD y MS que se supone que ayudan a resolverlo.

Matt H
fuente