logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 08-06-2018 17:59:22

Trefix
Membre
Lieu : 48
Distrib. : bookworm
Noyau : linux 6.1.0-25-amd64
(G)UI : Xfce4
Inscription : 15-02-2015

ping : lecture des résultats

Bonsoir.

Le petit (14 ans) s'offre un PC pour jouer (donc W$ sad ) et voudrait "tatatatatatatata..." sur Fortnite. Par curiosité (notre ligne pas dégroupée étant bien pourrite) j'ai donc regardé le wiki à propos de ping puis cherché une liste de serveurs pour Fortnite, pris le premier du top 100 et envoyé :

ping plugandplay.on.vg



J'ai le résultat suivant :

[...]
64 bytes from teamspeak-11.verygames.net (188.165.55.167): icmp_seq=141 ttl=55 time=42.7 ms
64 bytes from teamspeak-11.verygames.net (188.165.55.167): icmp_seq=142 ttl=55 time=47.9 ms
^C
--- plugandplay.on.vg ping statistics ---
142 packets transmitted, 141 received, 0% packet loss, time 141123ms
rtt min/avg/max/mdev = 41.445/50.697/110.247/15.931 ms
 

Mais à l'image d'une poule qui aurait trouvé un couteau, ça ne m'avance pas beaucoup, faute de savoir lire ce résultat...

J'en appelle donc à vos lumières (je vais ranger les courses, là, tout de suite) qui pourront servir à d'autres tant le sujet est peu développé sur le forum.

Merci et @+

Hors ligne

#2 08-06-2018 18:07:48

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : ping : lecture des résultats

Salut
Ce qui importe en jeu en ligne c'est le temps de réponse le débit importe moins
c'est pas terrible mais pas la cata non plus
puis quelqu'un avec un meilleur ping n'aura pas forcement une meilleur latence en jeu tout depend de l'endroit géographique du joueur

ping plugandplay.on.vg


PING plugandplay.on.vg (188.165.55.167) 56(84) bytes of data.
64 bytes from teamspeak-11.verygames.net (188.165.55.167): icmp_seq=1 ttl=54 time=36.0 ms
64 bytes from teamspeak-11.verygames.net (188.165.55.167): icmp_seq=2 ttl=54 time=34.2 ms
64 bytes from teamspeak-11.verygames.net (188.165.55.167): icmp_seq=3 ttl=54 time=39.1 ms
64 bytes from teamspeak-11.verygames.net (188.165.55.167): icmp_seq=4 ttl=54 time=36.3 ms
64 bytes from teamspeak-11.verygames.net (188.165.55.167): icmp_seq=5 ttl=54 time=48.3 ms
64 bytes from teamspeak-11.verygames.net (188.165.55.167): icmp_seq=6 ttl=54 time=36.7 ms


-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<-- 
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

En ligne

#3 08-06-2018 18:20:38

Trefix
Membre
Lieu : 48
Distrib. : bookworm
Noyau : linux 6.1.0-25-amd64
(G)UI : Xfce4
Inscription : 15-02-2015

Re : ping : lecture des résultats

Yep, c'était surtout la lecture des 4 valeurs de la ligne rtt qui m'intéressait :

rtt min/avg/max/mdev = 41.445/50.697/110.247/15.931 ms



Par ailleurs, tes temps sont assez homogènes quand les résultats que j'ai parcourus montraient de gros écarts tous les 3~4 paquets...


PS : j'aurais du mettre aussi les premières lignes du terminal, tu as raison.

Hors ligne

#4 08-06-2018 18:25:52

otyugh
CA Debian-Facile
Lieu : Quimperlé/Arzano
Distrib. : Debian Stable
Inscription : 20-09-2016
Site Web

Re : ping : lecture des résultats

Donc le ping c'est le temps pour que "ça ping et que tu reçoive un pong", un échange de ping pong.
Ça te permet d'avoir la latence.


min/avg/max/mdev = 41.445/50.697/110.247/15.931 ms

min 41.445ms : meilleur temps (minimum)
avg 50.697 : temps moyen (average)
max 110.247ms : pire temps (maximum)
mdev : 15.931 ms : moyenne des écarts de temps de chaque ping (plus cette valeur varie plus ta connexion est instable, coupures lors de téléchargements, inconfort quand on joue, ou parle en VOIP)..


Faut bien comprendre que le ping de donne que les résultats "à un moment donné". Quand tu télécharges, tu "sature" ta connexion, et le ping explose. Personnellement j'ai 30ms stable quand personne ne télécharge mais 3000ms et plus en cas de quelqu'un d'autre utilisant la connexion intensivement. Rien qu'ouvrir une vidéo sur le net peut faire exploser le ping temporairement. D'où l'horreur des "joueurs" quand ils partagent leur connexion avec leurs voisin : le ping explose.

Dernière modification par otyugh (08-06-2018 18:31:39)


virtue_signaling.pngpalestine.png
~1821942.svg

Hors ligne

#5 08-06-2018 18:29:05

Trefix
Membre
Lieu : 48
Distrib. : bookworm
Noyau : linux 6.1.0-25-amd64
(G)UI : Xfce4
Inscription : 15-02-2015

Re : ping : lecture des résultats

otyugh a écrit :

mdev : 15.931 ms : moyenne des écarts de temps de chaque ping (plus cette valeur varie plus ta connexion est instable, coupures lors de téléchargements, inconfort quand on joue, ou parle en VOIP)..


Merci.

En l’occurrence, c'est une valeur, pas une variation qui est indiquée. Faut-il refaire plusieurs tests pour juger de sa variation en comparant les mdev ou y a-t-il un calcul à faire pour extrapoler un résultat de cette valeur brute ?

Yep, je suis curieux...



Édith précise qu'un test en ligne (https:/ /www.degrouptest . com/test-debit .php, trouvé avec duckduck, volontairement inactif ici) me donne un avg de 49.00 ms, donc assez cohérent, il me semble (dans une fourchette 38/78 ms)...
.
.

Dernière modification par Trefix (08-06-2018 18:34:47)

Hors ligne

#6 08-06-2018 18:36:59

otyugh
CA Debian-Facile
Lieu : Quimperlé/Arzano
Distrib. : Debian Stable
Inscription : 20-09-2016
Site Web

Re : ping : lecture des résultats

Meh j'ai jamais trop réflechi à mdev à vrai dire... Jamais trop vu l'intêret tant les autres valeurs sont parlantes en général.

Pour moi le ping ne sert qu'à savoir l'état d'une connexion à un moment T donné ; c'est l'outil pour "savoir en gros si c'est un problème de saturation" qui explique une lenteur. Je m'en sers seulement pour trois trucs (mais je suis loin d'être un expert, c'est une utilisation complètement empirique ><) :
- Ma connexion est-elle saturée ? (chez moi si quelqu'un télécharger >200 Ko/s le ping explose | ou un envoi de donnée de >80ko/s)
- Ma connexion coupe-t-elle ? Parfois des lignes coupent toutes les heures ou plus (genre un fil qui tape sur une branche quand y a du vent) - ça permet de savoir à quel heure y a eu des coupures.
- Le serveur que je contacte est-il lent ? (si mon ping est bon sur un "google.fr" et mauvais sur "debian-facile.org", je peux conclure que debian-facile a du mal à répondre aux requêtes et que ça vient pas de moi - encore que c'est incomplet un serveur pourrait avoir du mal à servir un service sans pour autant avoir des soucis de débit... Mais bref.)

Dernière modification par otyugh (08-06-2018 18:41:46)


virtue_signaling.pngpalestine.png
~1821942.svg

Hors ligne

#7 08-06-2018 18:38:45

Trefix
Membre
Lieu : 48
Distrib. : bookworm
Noyau : linux 6.1.0-25-amd64
(G)UI : Xfce4
Inscription : 15-02-2015

Re : ping : lecture des résultats

Oki, merki wink

Hors ligne

#8 09-06-2018 09:35:56

raleur
Membre
Inscription : 03-10-2014

Re : ping : lecture des résultats

Croutons a écrit :

Ce qui importe en jeu en ligne c'est le temps de réponse le débit importe moins


L'ennui, c'est que le débit influe sur la latence lorsque la taille des paquets augmente. Il suffit de spécifier des tailles de paquets diverses avec l'option -s de ping pour s'en rendre compte. C'est particulièrement visible en ADSL où le débit montant est relativement bas (1 Mbit/s maxi), sans parler de l'entrelacement qui augmente la stabilité de la ligne mais aussi la latence.

Croutons a écrit :

puis quelqu'un avec un meilleur ping n'aura pas forcement une meilleur latence en jeu tout depend de l'endroit géographique du joueur


Tu peux expliquer ? Que je sache, ce que mesure ping, c'est précisément la latence.

otyugh a écrit :

mdev : 15.931 ms : moyenne des écarts de temps


Tu aurais la formule précise ? Je ne trouve aucune information dans la page de manuel, et d'après quelques tests, ce n'est ni la moyenne des écarts en valeur absolue à la moyenne, ni l'écart-type (racine carrée de la variance, elle-même égale à la moyenne des carrés des écarts à la moyenne).

otyugh a écrit :

Quand tu télécharges, tu "sature" ta connexion, et le ping explose


C'est notamment à cause des tampons d'émission des équipements réseau par lesquels les paquets transitent. On peut limiter l'augmentation du temps de transit en gérant la priorité des paquets à l'émission, en donnant une priorité plus élevée aux protocoles interactifs (SSH, jeu...) et en limitant le débit des téléchargements pour garder une marge.

Dernière modification par raleur (09-06-2018 09:36:42)


Il vaut mieux montrer que raconter.

Hors ligne

#9 09-06-2018 09:44:41

Trefix
Membre
Lieu : 48
Distrib. : bookworm
Noyau : linux 6.1.0-25-amd64
(G)UI : Xfce4
Inscription : 15-02-2015

Re : ping : lecture des résultats

raleur a écrit :

On peut limiter l'augmentation du temps de transit en gérant la priorité des paquets à l'émission, en donnant une priorité plus élevée aux protocoles interactifs (SSH, jeu...) et en limitant le débit des téléchargements pour garder une marge.


Bonjour.

Tu m'intéresse, là, ô grand raleur. Pourrais-tu développer, s'il te plaît, même si je ne suis pas certain de pouvoir tout comprendre à la première lecture ?

Je garde en effet quelques souvenirs amères de mes expériences de jeu en ligne, où ping pas fameux (l'actuel, bine meilleur, fait suite à des travaux IRL qui ont considérablement amélioré l'instabilité de notre ligne, pas dégroupée) et codes de triches m'avaient laissé sur le bord quand mes temps hors-ligne (ET sans tricher) me classaient dans le top 10 mondial du jeu... en connaissance de cause de l'extrême "relativité" de ce genre de "résultat" wink

Hors ligne

#10 09-06-2018 09:48:47

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : ping : lecture des résultats

Tu peux expliquer ? Que je sache, ce que mesure ping, c'est précisément la latence.


Ce que je veux dire c'est qu'il est difficile de savoir quel est la véritable adresse du serveur de jeu
L'adresse du ping n'est sûrement pas le serveur du jeu


-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<-- 
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

En ligne

#11 09-06-2018 10:03:25

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : ping : lecture des résultats

Bon, quoiqu'il en soit, j'ai mis le contenu de ces indications dans le wiki df sur la page du ping :
https://debian-facile.org/doc:reseau:pi … -du-reseau

Merci à vous. big_smile

saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#12 09-06-2018 10:03:43

otyugh
CA Debian-Facile
Lieu : Quimperlé/Arzano
Distrib. : Debian Stable
Inscription : 20-09-2016
Site Web

Re : ping : lecture des résultats

otyugh a écrit :

mdev : 15.931 ms : moyenne des écarts de temps


Tu aurais la formule précise ?


Oui pardon, j'ai traduit à la volée.
C'est l'écart type : https://fr.wikipedia.org/wiki/%C3%89cart_type
Moyenne : (36.0+34.2+39.1+36.3+48.3+36.7)/6=38,4
(36,0-38,4)²=5,8
(34,2-38,4)²=17,6
(39,1-38,4)²=0,5
(36,3-38,4)²=4,4
(48,3-38,4)²=98,0
(36,7-38,4)²=2,9
Variance : (5,8+17,6+0,5+4,4+98,0+2,9)/6=21,5
Écart type : 4,6
...Et merde. Bon ben du coup j'y arrive pas ;..; (mais ils disent bien écart type dans le wiki : https://en.wikipedia.org/wiki/Ping_(net … _ping_test)

otyugh a écrit :

On peut limiter l'augmentation du temps de transit en gérant la priorité des paquets à l'émission, en donnant une priorité plus élevée aux protocoles interactifs (SSH, jeu...) et en limitant le débit des téléchargements pour garder une marge.


Ouais, ce que permet pas ma bidulebox. C'est ce qu'on appelle le QoS ? J'avais cherché là-dessus, c'est assez peu connu paradoxalement, vu tout le bien que ça pourrait faire sur des connexion merdiques partagées.

Dernière modification par otyugh (09-06-2018 10:05:47)


virtue_signaling.pngpalestine.png
~1821942.svg

Hors ligne

#13 09-06-2018 10:04:23

Trefix
Membre
Lieu : 48
Distrib. : bookworm
Noyau : linux 6.1.0-25-amd64
(G)UI : Xfce4
Inscription : 15-02-2015

Re : ping : lecture des résultats

Test à refaire depuis la plateforme utilisée, j'en ai conscience, mais il faut d'abord avoir la machine ET chercher le serveur "le moins pourri" !

Ça, c'est pour la semaine prochaine...



Édith @smolski : j’abonderai le sujet, si je le peux...
.
.

Dernière modification par Trefix (09-06-2018 10:06:00)

Hors ligne

#14 09-06-2018 12:17:49

raleur
Membre
Inscription : 03-10-2014

Re : ping : lecture des résultats

otyugh a écrit :

Ouais, ce que permet pas ma bidulebox. C'est ce qu'on appelle le QoS ? J'avais cherché là-dessus, c'est assez peu connu paradoxalement, vu tout le bien que ça pourrait faire sur des connexion merdiques partagées.


QoS (Quality of Service), traffic shaping... C'est peu connu parce que c'est complexe à appréhender et mettre en oeuvre, et je trouve que la documentation disponible n'est pas suffisamment claire. L'outil de base sous Linux est tc (pour Traffic Control), qui fait partie du paquet iproute/iproute2. La page de manuel est totalement insuffisante pour l'utiliser. Il existe un HOWTO LARTC (Linux Advanced Routing and Traffic Control) qui détaille davantage mais pas suffisament à mon goût. Bref, certains points demeurent obscurs pour moi et je ne sais pas l'utiliser.

Il existe des logiciels de plus haut niveau pour faciliter la mise en oeuvre comme wondershaper, niceshaper. Le pare-feu shorewall aurait aussi cette fonctionnalité.

Mais avant que quelqu'un se lance là-dedans, il faut bien préciser que l'efficacité de ce genre de mesure dépend de l'endroit où on la met en place.
En effet la gestion du trafic n'a d'effet que sur le trafic sortant situé à un point de congestion. Sur un routeur, c'est l'interface de sortie vers le lien de plus faible capacité car c'est là que les paquets reçus par des liens à plus forte capacité vont s'accumuler dans la file d'attente d'émission (ce qui génère de la latence), et qu'on pourra jouer sur cette file d'attente pour rendre certains paquets prioritaires. Dans le cas d'un LAN ethernet ou wifi connecté à une liaison ADSL, il est inutile de faire du contrôle de trafic sur une interface ethernet du LAN ; il faut le faire sur l'interface de sortie ADSL.

Et je rappelle qu'on n'a aucun contrôle direct sur le trafic reçu, et la façon dont l'équipement en face dont on reçoit le trafic gère sa file d'attente d'émission. Tout ce qu'on peut faire, c'est par exemple agir indirectement sur les connexions TCP en forçant la source à limiter son débit afin de ne pas saturer le lien ne pas trop faire grossir la file d'attente.

Dernière modification par raleur (09-06-2018 12:20:44)


Il vaut mieux montrer que raconter.

Hors ligne

#15 09-06-2018 12:51:26

otyugh
CA Debian-Facile
Lieu : Quimperlé/Arzano
Distrib. : Debian Stable
Inscription : 20-09-2016
Site Web

Re : ping : lecture des résultats

Ça serait bien une config préfaite avec tc. Du genre "toujours donner la priorité absolue à X,Y,Z port sur les autres, limiter le débit max à A (pour prévenir l'explosion de la latence)", etc.
Y aurait plus qu'à adapter quelques variables, et ça serait niquel.

Après... Sur quel type de routeur utiliser tc, ça. Autant je vois bien les systèmes libres pour routeur adéquat, auant je vois moins le genre de hardware qui irait bien. Tu aurais quelque exemples de "routeur compatible gnu/linux" en tête ? Des bidules arm SoC ?

Dernière modification par otyugh (09-06-2018 12:53:09)


virtue_signaling.pngpalestine.png
~1821942.svg

Hors ligne

#16 09-06-2018 13:45:32

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : ping : lecture des résultats

Trefix a écrit :

Édith @smolski : j’abonderai le sujet, si je le peux...


Ne te gêne de rien... wink


saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#17 09-06-2018 17:18:08

Severian
Membre
Distrib. : Debian GNU/Linux 9.4 (stretch)
Noyau : Linux 4.14.0-0.bpo.3-amd64
(G)UI : Openbox 3.6.1-4
Inscription : 13-12-2014

Re : ping : lecture des résultats

une chose que j'avais lu (et testé) à une époque lointaine où je faisais du jeu en ligne, c'est le réglage de la MTU
par défaut la MTU est rêglé à 1500 qui est la valeur pour un réseau LAN, hors la plupart des box adsl sont connecté avec le protocole PPPoE qui à une MTU de 1492

pour faire du téléchargement il vaut mieux avoir une MTU max (ou proche du max), de plus gros paquets reçus donc un téléchargement plus rapide, par contre pour le jeu mieux vaut une MTU faible (576)

https://fr.wikipedia.org/wiki/Maximum_transmission_unit
https://www.zebulon.fr/dossiers/37-3-valeur-mtu.html
https://www.zebulon.fr/dossiers/37-6-op … -ping.html

Hors ligne

#18 09-06-2018 17:23:50

Trefix
Membre
Lieu : 48
Distrib. : bookworm
Noyau : linux 6.1.0-25-amd64
(G)UI : Xfce4
Inscription : 15-02-2015

Re : ping : lecture des résultats

Merci ! (... de me donner de la lecture) wink

Hors ligne

#19 12-06-2018 09:51:33

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : ping : lecture des résultats

Salut
@Severian ...stop avec tes vieux articles de 2004 aussi tongue

-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<-- 
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

En ligne

#20 12-06-2018 12:05:44

Severian
Membre
Distrib. : Debian GNU/Linux 9.4 (stretch)
Noyau : Linux 4.14.0-0.bpo.3-amd64
(G)UI : Openbox 3.6.1-4
Inscription : 13-12-2014

Re : ping : lecture des résultats

bhâ jusqu'à preuve du contraire c'est toujours d'actualité, non ?

Hors ligne

Pied de page des forums