ping et pipe

[Mafalda]

Bonjour,

Je chercher une explication au fait que parfois la comande ping renvoi une sortie qui se termine par pipe quelque chose.

Voici la dernière ligne du retour de mon ping:
4 packets transmitted, 3 received, 25% packet loss, time 3025ms
rtt min/avg/max/mdev = 1579.804/1929.340/2319.502/303.347 ms, pipe 3

Je ne comprends pas à quoi correspond le "pipe 3".

Merci de votre aide.

[tomtom]

bizarre cette sortie non documentée....

A vue de nez dans les sources, il semble que ce soit la difference entre le nombre de pacquets transmis et le numero de sequence du paquet reçu. (a priori, le numero donc du dernier paquet reçu par l'hote au moment ou il l'a envoyé)
La valeur de sortie est le max des valeurs observées au cours du temps, si > 0

En d'autres termes, ca donne le """"nombre de paquets sur la ligne"""" (note bien le nombre de guillemets, ne va pas dire que c'est une valeur exacte !).

"Si j'ai envoyé 1000 paquets et que je recois l'aquittement du 998ème, alors quand l'hote distant a généré ce paquet il n'avait recu que le 998ème et donc on suppose que les 2 paquets manquant étaient "sur le chemin" (mais note qu'ils peuvent être parvenus à l'hote entre temps ".


Voila, confère le fichier ping_common.h pour les details dans le texte.

Note que l'analyse alors doit etre importante. par exemple, dans ton exemple :

4 packets transmitted, 3 received, 25% packet loss, time 3025ms
rtt min/avg/max/mdev = 1579.804/1929.340/2319.502/303.347 ms, pipe 3

On peut deja deduire des choses (pas vraiment bonne pour ton reseau ) :

3 dans le pipe -> après avoir envoyé 4 paquets, on a reçu l'acquittement du 1er !
Ce qui signifie que le temps de reponse au premier paquet est de l'ordre de 3 secondes !!! pas glop


t.

[Mafalda]

Merci de ton explication.
D'après ton explication, j'aurai tendance à penser que si je n'ai pas d'acquittement pour le dernier packet alors j'ai nécessairement du % loss.

Or, ce n'est pas toujours le cas; exemple:
3 packets transmitted, 3 received, 0% packet loss, time 2028ms
rtt min/avg/max/mdev = 103.266/422.696/1041.606/437.711 ms, pipe 2

Enfin, ton explication éclaire déjà un peu ma lenterne et je t'en remercie!!!!

[tomtom]

Merci de ton explication.
D'après ton explication, j'aurai tendance à penser que si je n'ai pas d'acquittement pour le dernier packet alors j'ai nécessairement du % loss.

Non... les acquitements peuvent arriver ensuite !

Or, ce n'est pas toujours le cas; exemple:
3 packets transmitted, 3 received, 0% packet loss, time 2028ms
rtt min/avg/max/mdev = 103.266/422.696/1041.606/437.711 ms, pipe 2

Ex de scenario qui "colle" à ces résultats :

t0 -------> emission paquet seq=1
t0+1s ---> emission paquet seq=2
t0+2s ---> emission paquet seq=3
t0+2.01s --> reception paquet ack=1 (----> calcul pipe = 3 envoyés -1 reçu = 2)
t0+2.02s --> reception paquet ack=2 (--> pipe=1)
t0+2.027s -> reception paquet ack=3 (--> pipe=0)


Ce qui est etonnant, c'est que le premier paquet met beaucoup plus de temps que les autres, d'ou le pipe important au debut... En fait, cela vient probablement du fait que pour le premier paquet, l'emmeteur doit faire une requete ARP pour determiner l'adresse mac du recepteur ou de la passerelle, ce qui prend du temps. Tu peux valider cette hypothèse en refaisant le même ping juste après, puis en effaçant l'entrée arp du cache et en recommençant par exemple...

Note que tes temps de réponse sont beaucoup mieux que ceux d'hier

Pour plus de précision,il nous faudrait les resultats des temsp de réponse de chaque paquet.

Si tu veux faire grandir le pipe, tu peux essayer par exemple de reduire l'intervalle d'emission des paquets.

ex : ping -i 0.001 192.168.1.1

...


Bon courage

t.

[Mafalda]

Ok, je comprends mieux.

Il s'agit d'un ping qui se fait sur de l'internationnal vers la Roumanie....et les performances ne sont pas au rendez-vous....

En tout cas merci pour tes explication claires.

[tomtom]

Ha la roumanie ...

Ca me rappelle de bons souvenir !

Bon courage


t.

[Wizard_Spike]

Bon, je n'ai aps de réponse plus précise mais j'apporte mon grain de sel parce que c'est vraiment intéressant.

Si je ping une adresse qui n'existe pas, voici la réponse:

PING 192.168.1.252 (192.168.1.252) from 192.168.1.37 : 56(84) bytes of data.
From 192.168.1.37 icmp_seq=1 Destination Host Unreachable
From 192.168.1.37 icmp_seq=2 Destination Host Unreachable
From 192.168.1.37 icmp_seq=3 Destination Host Unreachable
From 192.168.1.37 icmp_seq=4 Destination Host Unreachable
From 192.168.1.37 icmp_seq=5 Destination Host Unreachable
From 192.168.1.37 icmp_seq=6 Destination Host Unreachable
From 192.168.1.37 icmp_seq=7 Destination Host Unreachable
From 192.168.1.37 icmp_seq=8 Destination Host Unreachable
From 192.168.1.37 icmp_seq=9 Destination Host Unreachable

--- 192.168.1.252 ping statistics ---
11 packets transmitted, 0 received, +9 errors, 100% loss, time 10027ms, pipe 3

Ici, il a passé les 9 premiers paquets en erreur par timeout mais 3 sont encore en route et on en a pas reçu de nouvelle. Ca correspond donc à l'explication de Tomtom.
Par contre, pourquoi dans les deux cas de Mafalda, le "pipe" compte des paquets "received"?
Je pensais vraiment que c'était l'acquittement du destinataire qui incrémentait le compteur du "received". Sinon comment l'envoyeur sait que le destintaire a reçu le paquet, s'il n'a pas encore été acquitté?

[tomtom]

Ici, il a passé les 9 premiers paquets en erreur par timeout mais 3 sont encore en route et on en a pas reçu de nouvelle. Ca correspond donc à l'explication de Tomtom.
Par contre, pourquoi dans les deux cas de Mafalda, le "pipe" compte des paquets "received"?
Je pensais vraiment que c'était l'acquittement du destinataire qui incrémentait le compteur du "received". Sinon comment l'envoyeur sait que le destintaire a reçu le paquet, s'il n'a pas encore été acquitté?

La fonction qui incrémente le "pipesize" est executée à chaque fois qu'un paquet cmp est reçu.
Le "pipe" est calculé à chaque paquet reçu, et la valeur qui est sirtie à la fin est le maximum des valeurs observées au fil du temps.

Quand un paquet arrive, s'il orrespond bien à un paquet attendu (suite à paquet emis), on calcule la valeur du pipe comme étant le nombre de paquets emis moins la valeur du numéro de sequence reçu (+1 d'ailleurs, mais ce n'est pas important pour comprendre).

Dans le cas de mafalda, ce sont bien les reponses de l'hote distant qui arrivent.
Simplement, quand on reçoit l'echo reply du premier paquet emis, on en a deja envoyé 2, d'ou le pipe de 2 (2 -1 +1).

Dans ton cas, on n'a pas de time out mais une reponse de ta machine elle même (c'est l'algo de routage de la pile linux qui veut ça) qui declare "host unreachable" pour le numero de sequence donné. Cette reponse pourrait fort bioen venir de ta passerelle par defaut par exemple.
Quand elle voit le paquet sequence 9, la machine a envoyé 11 paquets et donc elle calcule pipesize=11-9+1=3.


Plus clair ?

t.

[Wizard_Spike]

Les idées fraiches du matin!! Et la honte de mes erreurs du dernier messages!!
Déjà dans mon esprit d'hier, 11-9 = 3
En relisant tous les messages du post, j'ai bien compris cette histoire de pipe.
Surtout ta phrase "La valeur de sortie est le max des valeurs observées au cours du temps, si > 0", ce qui répond à ma question "pourquoi Mafalda a un pipe de 2 alors que 3 paquets ont été transmis et 3 ont été reçus?", c'est que au cours du ping, il y a eut un moment où la machine avait envoyé 3 paquets mais n'avait reçu l'aqcuittement que d'un seul.
C'est simple comme bonjour au final!! En tout cas merci de ces explications.