Temps de ping négatif?

15

C'est la première fois que je vois cela et je ne sais pas ce que cela signifie;

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

Quelqu'un a-t-il déjà vu un temps de ping négatif auparavant? Un de mes amis m'a dit qu'il l'avait vu une fois sur une liaison sans fil, et que c'était sur une connexion sans fil, mais .. comment cela se produit-il?

networking wireless-networking ping latency Jeff Welling
la source
4
Avez-vous un processeur AMD?
MaQleod
9
Juste une faille temporaire dans le continuum espace-temps. Rien à craindre. Maintenant, où ai-je mis les clés de mon DeLorean?
jongleur
Je ne me souviens pas précisément sur quelle machine j'ai exécuté le test, mais les 3 seuls sur lesquels j'ai pu l'exécuter sont tous Intel (un ordinateur de bureau Intel, un Macbook Pro, un Mac Mini).
Jeff Welling
12
Le retard de ping négatif est un problème dans la matrice. Cela arrive quand ils changent quelque chose.
James T Snell

Réponses:

15

NTP ou Windows Time Service a-t-il synchronisé l'horloge système pendant le ping?

Hydaral
la source
Excellente question, ça pourrait être ça. Malheureusement, je ne me souviens pas exactement de l'heure à laquelle j'ai fait le ping, donc je ne peux pas vérifier les journaux pour une synchronisation NTP qui s'aligne.
Jeff Welling
Ce serait bizarre, mais +1 pour un excellent point de dépannage.
mbb
Sans meilleure réponse, et étant incapable de trouver une solution plus plausible à partir du moment où cela s'est produit jusqu'à présent, j'accepte cette réponse parce que je pense que c'est l'explication la plus probable de la façon dont cela s'est produit. Merci.
Jeff Welling
Je viens de rencontrer le même problème sur une machine virtuelle et je peux confirmer que NTP corrigeait la dérive temporelle. service ntpd stopsur CentOS a corrigé cela (mais va créer d'autres problèmes, évidemment). Voir cette question très intéressante pour plus d'informations.
Benjamin
4

J'ai du mal à y croire, mais cette discussion semble indiquer que c'est le comportement de certains processeurs AMD.

Personnellement, je ne m'en inquiéterais pas et je suppose que c'est une faille conceptuelle dans ICMP ... Peut-être un paquet qui est passé par un chemin différent ou quelque chose de bizarre impliquant des machines / routeurs avec leurs horloges réglées différemment.

James T Snell
la source
2
De la discussion liée, je ne pencherais pas vers une faille conceptuelle dans ICMP. Il semble qu'AMD ait un décalage d'horloge entre les deux cœurs, ce qui provoque une interprétation négative de l'heure.
Evan
@evan: Mais 0,7 seconde est une énorme différence!
Escargot mécanique
2
le rapport que vous obtenez de ping n'a rien à voir avec les horloges des routeurs externes, c'est la différence de temps entre l'envoi du paquet à sa destination et la réception de la réponse à l'hôte. Il est cadencé par l'hôte.
MaQleod
@Escargot mécanique Vous avez raison, c'est extrêmement grand, mais la discussion liée dit que le biais augmente avec le temps. Si le processeur a fonctionné pendant une période prolongée, 0,7 seconde n'est pas trop absurde. Il serait intéressant de voir si le problème ne survient qu'après un certain temps de fonctionnement du processeur.
Evan
@Evan: Je veux dire que 0,7 seconde est susceptible de provoquer des bugs plus graves que cela, donc nous en aurions probablement déjà entendu parler.
Escargot mécanique
1

Malheureusement, cela ne se limite pas aux processeurs AMD, mais cela semble affecter un peu XP. À ce jour, et après quelques années de recherche de réponses, je connais une solution rapide, mais je ne peux pas le faire sur des serveurs qui ne réapparaîtront pas à distance après le démarrage.

Pour réinitialiser TCP / IP (et les horaires), ouvrez une fenêtre admin CMD et entrez les informations suivantes:

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

Maintenant, vous DEVEZ redémarrer. L'adaptateur réseau revient à DHCP, donc méfiez-vous des télécommandes.

Alors qu'est-ce qui se passe ici?

Pour une raison quelconque, TCP / IP a un horodatage qu'il utilise pour calculer la synchronisation, et il est en quelque sorte truqué. J'avais l'habitude de le voir tout le temps à un endroit, mais c'est finalement arrêté. Malheureusement, cela continue dans l'entrepôt que je gère. Ce soir, tous les points semblent être bloqués à 237 ms, mais 2 sont revenus avec plusieurs pings.

pingpathest un utilitaire très pratique, et je vais l'utiliser plus souvent. Malheureusement, il est arrivé avec les mêmes résultats ...

Chose triste, cela efface également les erreurs de ping dans les jeux.

note - si vous voulez voir le fichier journal, remplacez null par un nom de fichier, tel que c:\log.txt - Null signifie simplement pas de fichier (techniquement)

Jeff Mathews
la source
1

Je crois que c'est un bug dans la façon dont la pingcommande chronomètre les paquets et est aggravé par les processeurs AMD plus qu'Intel.

Les fonctions utilisées pour la synchronisation haute résolution dans les fenêtres sont QueryPerformanceCounteret QueryPerformanceFrequency.

Malheureusement, ils sont cassés pour les processeurs multicœurs car ces processeurs ne renvoient pas les mêmes nombres.

La solution au ping est de définir l'affinité du thread ping. Je doute que ce soit ce qui expliquerait le timing négatif. Il existe également des correctifs d'AMD et de MS qui sont censés aider à le trier.

Matt H
la source