Question sur le Ping & MTU

[VaillantDes]

Bonjour à tous;

Comme expliqué dans mon premier post *, je vous rappel que je suis novice sur l'utilisation d'un produit Macintoch, et je vais essayer d'etre le plus clair possible dans mon intervention d'aujourd'hui afin qu'il soit plus facile pour vous de me répondre:
( * Cf 1er post de Vaillant http://forums.macg.co/internet-et-reseau/questions-sur-les-preferences-reseaux-848432.html )

Aujourd'hui j'aimerai avoir des réponses sur 2 sujets:

a/ Le MTU ( Maximum Transmission Unit)
b/ le Ping

a/ Dans les préférences réseaux avancés d'éthernet, je vois que le MTU est réglable manuellement.
Pour ma part, j'ai positionné ce dernier sur 1368, alors que d'origine il est sur 1500.
Lors d'une transmission de données informatiques, le maximum transmission unit (MTU) est la taille maximale d'un paquet pouvant être transmis en une seule fois (sans fragmentation) sur une interface. ( source Wikipédia )

Question:

1/ Comment peux t'on trouver le réglage idéal ?
2/ Ce dernier réglage à t'il une incidence sur la gestion de la vitesse de connexion?




b/ Dans un soucis de rapidité, le ping est intéressant pour les joueurs " en ligne ".
Lors d'un réglage sur PC, j'ai utilisé cette astuce ---> http://lire.tayo.fr/baisser-son-ping-dans-les-jeux-astuce.php qui m'a donné satisfaction.
Dans un autre temps j'ai utilisé ce logiciel qui m'a permis de faire des réglages affinés ---> http://www.01net.com/telecharger/windows/Utilitaire/optimiseurs_et_tests/fiches/32984.html

Question:

1/ Y'a t'il un intérêt à trouver un bon réglage sur I-Mac pour le ping?
2/ Un logiciel comme " tcp optimiser " existe t'il? et est il recommandé pour Mac?

Question subsidiaire:

Y'a t'il une astuce, une ligne de commande ou un logiciel qui permet de gagner en fluidité sur un jeu en ligne?


Merci à tout le monde d'avoir pris le temps de me lire et d'apporter des réponses.


Trés Cordialement, Vaillan†

 

[Polo35230]

Alors là, c'est de la technique protocolaire.
Impossible de faire vraiment simple sans parler des couches réseau et des encapsulations.
Il y a toute une littérature là dessus. Pour s'endormir, c'est bien...

Avant de répondre aux questions, un truc simple:
Quand on tape "salut coco" (10 caractères) par exemple à partir d'un site de chat, puis touche "Envoi", ces 10 caractères traversent les sept couches réseaux, de la couche Application (le chat) jusqu'à la couche physique (le câble ethernet, ou le wifi)
Pour que les informations (tes 10 octets) puissent voyager d'une machine A à une machine B , tes 10 octets vont être encapsulés (bornées par des éléments protocolaires).
Nombreux protocoles, nombreux éléments protocolaires....
On va se limiter à ceux concernés par la question , et au protocole TCP/IP sur ethernet.

Protocole TCP élément MSS (Taille maximale en octets du segment). Sa taille va dépendre de celle de la MTU, en principe 1460 octets (1500 de la MTU -40 octets d'encapsulation tcp/ip)
Protocole IP élément MTU (le max en octet que peut transporter un datagramme IP Par défaut 1500 octets

Lors de l'établissement d'une session TCP entre deux machines, celle qui initie la session (ex machine A) envoie sa taille de MSS (en principe 1460, si sa MTU est configurée à1500)
Si B à un paramètrage qui permet une MSS de >=1460, il lui renverra 1460, et c'est cette valeur qui servira d'unité de transmission aux deux machines.
Si il ne peut pas, il lui renverra une valeur inférieure, et c'est cette valeur qui sera alors utilisée.

1-Maintenant, le réglage idéal de la MTU.
On a vu plus haut que le MSS (conditionnée par la MTU) est une valeur négociée entre la machine émettrice et réceptrice.
C'est donc la valeur optimale (mais uniquement entre A et B) La plupart du temps, c'est 1500.

Mais c'est pas aussi simple que ça, parce que entre A et B, il y a plein d'équipements (switchs, routeurs, sondes, firewall) qui font aussi mumuse avec la MSS.
Et même avec la MTU négociée, ça peut ne pas marcher, car suivant ce qu'on rencontre sur internet (options TCP, tunnels), les encapsulations vont grossir, et la règle MTU (1500)-40= MSS (1460) ne s'appliquera plus, car sur internet, certains équipements mal configurés (pour ajuster la taille de la MSS) ne s'adapteront pas au niveau de la fragmentation.

Pour palier ce genre de pb, les machines peuvent vérifier la taille optimale de la MTU en tenant compte des contraintes du réseau (c'est le Path MTU Discovery).
Super bien, sauf que ce dispositif est souvent inopérant du fait que certains firewall ne laissent pas passer ce dialogue...

On peut donc dire que la taille idéale de MTU, c'est celle (la max) qui ne pose pas de pb en fct de ce qu'on fait sur internet.
Maintenant, si tu as une MTU à 1368, c'est que tu as rencontré des pbs avec certains sites, et c'est celle qui est maintenant utilisée même avec ceux qui peuvent faire 1500. Mais tu as raison...

2-Le réglage de la MTU a-t-il une incidence sur la vitesse de transmission?
Oui, il a une incidence sur le débit utile en fonction du type de flux.
Prenons le cas standard MTU =1500 , encaps TCP: 20, encaps IP :20 (nos 40 octets d'encaps)

Prenons un flux FTP MTU=1500 (dont 40 d'encaps) soit 97,4% de débit utile
Passons la MTU à 1000 (il y aura tjs 40 d'encaps) soit 96% de débit utile.
Sur une liaison à 10Mbps (en supposant que le tuyau soit rempli), avec une MTU à 1000, tu gagnes 1,4% de bande passante en débit utile (soit 140 000kbps). Pas terrible...

1/ Y'a t'il un intérêt à trouver un bon réglage sur I-Mac pour le ping?
A vrai dire, je ne sais pas.
Par défaut, le Mac envoie des pings de 64 octets.
Le ping doit être utilisé dans un contexte de jeux pour évaluer les temps de réponse du réseau (latence)
Ce temps est fct de plein de choses, mais également du nombre d'octets envoyés dans un ping.
Donc, changer cette valeur de 64, je vois pas trop l'intérêt.

2/ Un logiciel comme " tcp optimiser " existe t'il? et est il recommandé pour Mac?
-Tcp optimiser joue sur la recherche optimale de la MTU et su la taille du buffer en réception (tcp windows size) de la machine.
Sur windows, il y a un utilitaire (mturoute) pour trouver la bonne taille de MTU. Ca marche si les équipemnts traversés laissent passer ces messages icmp)
Pour modifier le TcpWindowsSize, c'est dans le registre.
-Sur Mac je ne sais pas si il existe l'équivalent, mais avec l'adresse ip du serveur, tu peux faire des choses, mais à la mimine.
ping -s 1500 -D adresseIP (là pour voir si sans fragmenter, ça passe avec 1500). Si ça ne passe pas, baisser la taille.
Pour modifier l TcpWindowsSize, il y a un utilitaire qui fait ça , et bien d'autre chose (mac pilot, à utiliser avec précaution, on joue avec des paramètres système)

3/Y'a t'il une astuce, une ligne de commande ou un logiciel qui permet de gagner en fluidité sur un jeu en ligne?
Je ne sais pas. Il faut la meilleure bande passante possible de bout en bout, La meilleure MTU possible, et un buffer en réception bien calibré.
Ca conditionne les mécanismes d'anticipation dans le sens serveur vers client.
Par défaut, sur mon mac, j'ai 65535 .
Il faudrait regarder dans la doc des jeux pour savoir si il y a une valeur minimum.

Tain.., j'ai fait un pavé.
Un point disco à celui qui a tout lu...

 

[VaillantDes]

Hello Polo;

Merci d'avoir pris le temps de me répondre.
En effet j'ai bien compris tes réponses, à mes questions.
En terme de pédagogie, aucun soucis, j'ai bien " avalé " le pavé.

Trois choses me revienne à l'esprit:

1/ le fameux sous dossier qui existe dans le registre de Windows , le TcpWindowsSize. ( PC )
2/ le calcul du Rwin ? Est t'il d'actualité sur un I-Mac?
3/ Ce lien concernant la BP ( bande passante ) : http://www.youtube.com/watch?v=GO6d84h6Tpg

En sommes, j'ai posé ces questions, car je trouve que mon Ping varie de 35ms à parfois 15ms !
je passe par http://speedtest.net/ pour calculer ce dernier.
Puis, car l'un ne va pas sans l'autre, je regarde ma BP sur ce site : http://mire.ipadsl.net/speedtest.php

Exemple ce soir, je rame, ça n'avance pas:
" Votre Bande
Passante 2701.605 Kbps (337.701 Ko/sec)"

Alors de quoi cela peut venir? un coup rapide, un coup lent?!
L'occupation du réseaux par d'autres internautes?

Y'a t'il une astuce pour conserver une constance relative?
Je me pose plein de questions, qui ne sont pas forcément utiles, mais j'aimerai comprendre.


Sinon, je vais aller voir ce logiciel ( mac pilot )


J'espère que vous aurez compris un peu mieux mon charabia , meme si ce dernier est un peu lourd de compréhension


Cordialement, Vaillant.

Avant de répondre aux questions, un truc simple:
Quand on tape "salut coco" (10 caractères)

Y'en à pas 11 plutôt de caractères?

 

[Polo35230]

Le TCP windows size (c'est le RWIN je pense), comme la MTU ne sont pas propres au Mac ou au PC.
Ce sont des éléments propres aux protocoles TCP et IP.
Ces mêmes piles protocolaires sont présentes aussi bien dans le PC que dans le Mac.
La MTU, comme le TcpWindowsSize (buffer de réception de la machine) peuvent donc être modifiés: dans le registre (comme on le voit dans la vidéo youtube pour le PC), dans la conf réseau pour la MTU, et via un utilitaire pour le Mac.
Ce n'est pas la peine de modifier le TCP windows size dans le Mac. Il est suffisament calibré. Vaut mieux pas utiliser Mac Pilot...

Pourquoi ton ping varie?
Un exemple. J'ai fait le speedtest.net chez moi. J'ai récupéré l'adresse ip de leur machine.
J'ai fait un traceroute sur cette adresse.
Voilà le résultat:
imac:~ Polo$ traceroute 89.84.127.55
traceroute to 89.84.127.55 (89.84.127.55), 64 hops max, 52 byte packets
1 livebox (192.168.1.1) 1.534 ms 0.472 ms 0.456 ms
2 * arennes-651-1-214-1.w90-32.abo.wanadoo.fr (90.32.141.1) 18.020 ms 17.311 ms
3 10.123.101.138 (10.123.101.138) 18.058 ms 18.091 ms 58.119 ms
4 xe-6-0-1-0.nrnan201.nantes.francetelecom.net (193.252.99.186) 24.197 ms 24.772 ms 24.369 ms
5 tengige0-0-0-2.ntaub201.aubervilliers.francetelecom.net (81.253.129.218) 32.809 ms 32.727 ms 32.756 ms
6 xe-5-0-1-0.noaub101.aubervilliers.francetelecom.net (193.252.161.113) 30.782 ms 163.654 ms 42.857 ms
7 te2-5.core04-m.net.bbox.fr (62.34.0.209) 30.849 ms 30.906 ms 31.313 ms
8 v210.core03-m.net.bbox.fr (194.117.192.53) 31.102 ms 31.379 ms 31.080 ms
9 g3-46.core01-m.club-internet.fr (62.34.0.30) 31.332 ms 31.199 ms 31.293 ms
10 ae4.tcore01-m.net.bbox.fr (89.89.102.33) 104.212 ms 31.592 ms 31.511 ms
11 po101.core04-t2.net.bbox.fr (89.89.102.38) 32.257 ms 31.587 ms 31.552 ms
12 v113.tengec5-10g.c6k02-t2.club-internet.fr (62.34.0.174) 31.299 ms 31.564 ms 31.075 ms
13 89.84.127.55 (89.84.127.55) 31.277 ms 31.853 ms 31.318 ms
imac:~ Polo$

Pour faire simple, de chez moi jusqu'au serveur, il y a 13 routeurs, donc 12 liaisons avec des débits.
Sur ces 12 liaisons, il y en a qu'une dont tu dispose pleinement, c'est le raccordement de ta box au point de raccordement opérateur.
Sur tous les autres liens, les ressources sont mutualisées (tu n'es pas tout seul).
De plus, dans tous les équipement traversés, il y a de la qualité de service (QoS).
Ca veut dire que certains flux sont priorisés par rapport à d'autres.
Concrètement, les protocoles utilisés par les flux temps réels (voix, visio, TV) sont les plus prioritaires.
Le protocole icmp (ping) est dans la file la moins prioritaire (best effort). Il fait donc au mieux...
Ca veut dire que quand il est tout seul, il peut potentiellement prendre toute la bande passante, mais si un flux plus prioritaire se présente, il lui fait de la place.
C'est pour ça que le ping varie dans de forte proportions.
Il ne faut pas voir le chemin entre deux machines comme un seul tuyau...

Donc que le temps de latence (aller et retour du ping) varie, c'est normal.
Pas de temps de réponse garantis sur l'internet public...

La seule façon d'avoir du débit garanti et une QoS aux petits oignons, c'est de passer par un opérateur, et de construire un réseau privé. Comme certaines entreprises le font. Chère, la solution...

 

[Tribal]

Un échange super intéressant a lire. Merci beaucoup de ton partage polo

 

[lolipale]

+1

Merci d'avoir pris le temps d'expliquer et de démontrer

 

[VaillantDes]

Le TCP windows size (c'est le RWIN je pense), comme la MTU ne sont pas propres au Mac ou au PC.
Ce sont des éléments propres aux protocoles TCP et IP. OK , bien compris.
Ces mêmes piles protocolaires sont présentes aussi bien dans le PC que dans le Mac.
La MTU, comme le TcpWindowsSize (buffer de réception de la machine) peuvent donc être modifiés: dans le registre (comme on le voit dans la vidéo youtube pour le PC), dans la conf réseau pour la MTU, et via un utilitaire pour le Mac. Ok Polo, y'a t'il un gain à toucher quelque chose sur mac? Apparemment non, d'aprés ta prochaine réponse.
Ce n'est pas la peine de modifier le TCP windows size dans le Mac. Il est suffisament calibré. Vaut mieux pas utiliser Mac Pilot... Ok , je ne touche pas non plus, je suis tes conseils. Je débute, j'ai pas envie de tout mettre en panne, ce serais dommage.

...
Sur tous les autres liens, les ressources sont mutualisées (tu n'es pas tout seul).
De plus, dans tous les équipement traversés, il y a de la qualité de service (QoS). Peux t'on agir sur la " qualité de service " ?
Ca veut dire que certains flux sont priorisés par rapport à d'autres.
Concrètement, les protocoles utilisés par les flux temps réels (voix, visio, TV) sont les plus prioritaires. Meme chez numéricable qui est mon opérateur?
Le protocole icmp (ping) est dans la file la moins prioritaire (best effort). Il fait donc au mieux... Puis je modifier un paramètre pour diminuer mon ping et donc optenir moins de latence ( lag ) ?
Ca veut dire que quand il est tout seul, il peut potentiellement prendre toute la bande passante, mais si un flux plus prioritaire se présente, il lui fait de la place.
C'est pour ça que le ping varie dans de forte proportions. OK , bien compris
Il ne faut pas voir le chemin entre deux machines comme un seul tuyau...

Donc que le temps de latence (aller et retour du ping) varie, c'est normal.
Pas de temps de réponse garantis sur l'internet public...

La seule façon d'avoir du débit garanti et une QoS aux petits oignons, ben les oignons grillés , j'adore ça :love: c'est de passer par un opérateur, et de construire un réseau privé. Comme certaines entreprises le font. Chère, la solution...

Merci Polo pour ta disponibilité, et le temps que tu aura pris à me répondre d'une manière fort complète! Chapeau!:king:
Dans ma tête les choses sont plus claires, même si il reste quelques petits détails qui me dépassent pour l'instant. Je pense comprendre que sur un Mac, les paramètres sont donc optimisés aux rendement maxi dés le départ! Si tu pense avoir quelque chose d'autre a dire, je laisse pour le moment le fils du poste ouvert. Mais j'imagine que le PRINCIPAL est dit. BIG UP à toi, je suis super content de tes explications. Cordialement, Vaillant.

 

[Polo35230]

-Peux t'on agir sur la " qualité de service " ?
Tu ne maîtrises que ton réseau local, jusqu'au port ethernet (ou wifi) de l'équipement opérateur. Dès que tu passes par le port wan de ce dernier, c'est sa QoS qui s'applique sur le ou les tronçons qu'il maîtrise, puis, une autre QoS, si la machine visée n'est pas chez cet opérateur. Sur le réseau, la QoS est appliquée sur les interfaces physiques des équipements opérateurs.
Par contre, en interne, sur ton réseau local, tu peux mettre une QoS en place (avec le matériel qui va bien) pour par exemple brider au niveau bande passante les flux de sauvegardes avec un NAS, de façon à laisser de la place à la navigation ou aux flux TV.

-Concrètement, les protocoles utilisés par les flux temps réels (voix, visio, TV) sont les plus prioritaires. Meme chez numéricable qui est mon opérateur?
C'est évident, il y a de la QoS partout sur internet, et ils la gère quasiment tous de la même façon pour des raisons purement techniques.
Les protocoles véhiculés sont rangés dans différentes files d'attente en fonction de contraintes propres à chacun (par exemple: taux de perte, gigue, etc...)


-Puis je modifier un paramètre pour diminuer mon ping et donc optenir moins de latence ( lag ) ?
A vrai dire, c'est celui (ou l'application) qui émet le ping qui choisit la longueur (via une option).
Sur Mac OS, c'est -s
Par exemple, dans une fenêtre Terminal, tu peux faire des pings de longueurs différentes, et ainsi vérifier l'incidence sur le temps de réponse (plus il y a d'octets dans le ping, plus le temps de réponse est lon. Normal....)
Par exemple, chez moi, sur ma box.
imac:~ Polo$ ping -s 20 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 20 data bytes
28 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.625 ms
28 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.567 ms
28 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.554 ms
28 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.560 ms
^C
--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.554/0.577/0.625/0.028 ms
imac:~ Polo$
imac:~ Polo$ ping -s 1000 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 1000 data bytes
1008 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.749 ms
1008 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.872 ms
1008 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.849 ms
1008 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.871 ms
1008 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.872 ms
^C
--- 192.168.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.749/0.843/0.872/0.048 ms
imac:~ Polo$ ping -s 1500 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 1500 data bytes
1508 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.981 ms
1508 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.092 ms
1508 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.985 ms
1508 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.082 ms
1508 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1.068 ms
^C
--- 192.168.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.981/1.042/1.092/0.048 ms


-Maintenant, du concret. On peut faire une trace pour visualiser la MTU (enfin, la MSS, mais on vu plus haut dans le fil que c'est la MTU qui fixait la taille d la MSS).
Je ferme toutes les applis qui peuvent causer sur le réseau (skype, messagerie, Safari).
Dans une fenêtre Terminal, je passe la commande sudo tcpdump -c 200 pour tracer les 200 premières lignes qui passent (dans les deux sens) par mon interface ethernet.
Puis, je lance Safari (ma page d'accueil est google.fr/ig). Ca défile dans la fenêtre Terminal.
imac:~ Polo$ sudo tcpdump -c 200
Password:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:57:42.711756 IP imac.home.58695 > livebox.home.domain: 36924+ A? www.l.google.com. (34)
16:57:42.749309 IP livebox.home.domain > imac.home.58695: 36924 6/0/0 A 209.85.148.99, A 209.85.148.105, A 209.85.148.103, A 209.85.148.104, A 209.85.148.106, A 209.85.148.147 (130)
16:57:42.750123 IP imac.home.50680 > fra07s07-in-f99.1e100.net.http: Flags , seq 2342634320, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 337957630 ecr 0,sackOK,eol], length 0
16:57:42.788006 IP imac.home.50382 > ns214853.ovh.net.http: Flags [F.], seq 1607545524, ack 3606344140, win 65535, options [nop,nop,TS val 337957630 ecr 2867313138], length 0
16:57:42.791870 IP fra07s07-in-f99.1e100.net.http > imac.home.50680: Flags [S.], seq 2955337069, ack 2342634321, win 5672, options [mss 1430,sackOK,TS val 3238038324 ecr 337957630,nop,wscale 6], length 0
16:57:42.791926 IP imac.home.50680 > fra07s07-in-f99.1e100.net.http: Flags [.], ack 1, win 65535, options [nop,nop,TS val 337957631 ecr 3238038324], length 0
16:57:42.796233 IP imac.home.50680 > fra07s07-in-f99.1e100.net.http: Flags [P.], seq 1:674, ack 1, win 65535, options [nop,nop,TS val 337957631 ecr 3238038324], length 673
16:57:42.843344 IP fra07s07-in-f99.1e100.net.http > imac.home.50680: Flags [.], ack 674, win 110, options [nop,nop,TS val 3238038376 ecr 337957631],

Regardons les lignes 3,5 et 6 (c'est l'établissement de la session TCP entre mon mac et le serveur google).
Ligne 3:TCP Syn. Mon Mac initie une connexion sortante vers le serveur google, et lui communique sa taille de MSS 1460 (normal, j'ai une MTU à 1500, et 1500-40 (d'encaps)= 1460)
Ligne 5: TCP. Syn ack. Le serveur google ne peut pas travailler à 1460. Il donne sa taille de MSS, soit 1430 (il doit donc avoir une MTU à 1470).
Ligne 6: ack. Mon Mac dit ok, on peut commencer, et on échange avec des MSS de 1430 octets (MTU de 1470).
Le serveur Google utilise une MSS à 1430, pour pouvoir répondre à toutes les requêtes, même à celles qui passent dans les tunnels (donc avec des encapsulations TCP/IP supérieures à 40)

-Comment peut-on voir si la taille du buffer en réception (tcp windows size) du Mac est suffisante?
Là aussi, on peut faire une traçe.
Je lance un test de débit descendant (sens serveur de test vers mon Mac).
Donc en principe, avec un test de débit descendant, on a le max de débit q'une machine peut nous envoyer via internet. Chez moi, 12 Mbps dans ce sens.
Dans une fenêtre Terminal, on lance la même commande que ci-dessus.
Voilà un extrait:
17:29:41.118488 IP imac.home.50751 > ipfailover-ovh-1.ivalley.fr.http: Flags [.], ack 392813, win 65535, options [nop,nop,TS val 337976800 ecr 1355881917], length 0
17:29:41.119658 IP ipfailover-ovh-1.ivalley.fr.http > imac.home.50751: Flags [.], seq 392813:394253, ack 1261, win 65, options [nop,nop,TS val 1355881917 ecr 337976799], length 1440
17:29:41.121078 IP ipfailover-ovh-1.ivalley.fr.http > imac.home.50751: Flags [.], seq 394253:395693, ack 1261, win 65, options [nop,nop,TS val 1355881917 ecr 337976799], length 1440
17:29:41.121198 IP imac.home.50751 > ipfailover-ovh-1.ivalley.fr.http: Flags [.], ack 395693, win 65535, options [nop,nop,TS val 337976800 ecr 1355881917], length 0
17:29:41.122132 IP ipfailover-ovh-1.ivalley.fr.http > imac.home.50751: Flags [.], seq 395693:397133, ack 1261, win 65, options [nop,nop,TS val 1355881917 ecr 337976799], length 1440
17:29:41.122180 IP imac.home.50751 > ipfailover-ovh-1.ivalley.fr.http: Flags [.], ack 397133, win 65520, options [nop,nop,TS val 337976800 ecr 1355881917], length 0
17:29:41.123742 IP ipfailover-ovh-1.ivalley.fr.http > imac.home.50751: Flags [.], seq 397133:398573, ack 1261, win 65, options [nop,nop,TS val 1355881917 ecr 337976799], length 1440
17:29:41.124794 IP ipfailover-ovh-1.ivalley.fr.http > imac.home.50751: Flags [.], seq 398573:400013, ack 1261, win 65, options [nop,nop,TS val 1355881919 ecr 337976800], length 1440
17:29:41.124915 IP imac.home.50751 > ipfailover-ovh-1.ivalley.fr.http: Flags [.], ack 400013, win 65535, options [nop,nop,TS val 337976800 ecr 1355881917], length 0

Lignes 2 et 3 : Le serveur de test envoie deux messages de 1440 octets à suivre.
Ligne 4: le Mac acquitte ces 2840 octets et communique au serveur la taille disponible de son buffer en réception (win 65535, soit la totalité). Il a eu le temps de vider ce buffer avant d'acquitter.
Ligne 5: Le serveur envoie 1440 octets.
Ligne 6: Le mac acquitte ces 1440 octets, et lui communique son buffer en réception, soit 65520 octets. Il a pas eu le temps de le vider complètement.
Et ainsi de suite.

On voit dans la suite de la trace (j'ai pas tout mis) que le la taille du buffer disponible oscille tjs entre ces deux valeurs.
On peut en conclure que le Mac n'est jamais en difficulté. Il peut encaisser beaucoup plus au niveau débit entrant.
S' il avait été en difficulté, on aurait vu la taille disponible du buffer du mac baisser pour faire ralentir le serveur.
Une taille de 0 communiquée au serveur par le Mac signifierait que le Mac demande au serveur d'arrêter de transmettre jusqu'à ce qu'il lui communique une valeur différente de 0.

En réalité, le Mac ne sera jamais en difficulté (pour des échanges sur internet), parce que les débits entrants (chez les particuliers) sont rarement supérieurs à 30Mbps, et que la carte réseau peut aller jusqu'à 1Gbps.
Les paramètres du Mac sont donc configurés pour ce débit.

 

[VaillantDes]

Bonsoir Polo; Vraiment un grand merci pour toutes ces informations!
J'ai tout bu, je n'ai rien laissé.
Seule une dernière question me préoccupe :

- Puis-je agir via le terminal pour diminuer mon Ping?
- J'utilise Safari pour jouer et naviguer sur le net; Utiliser " Ubuntu " serait t'il plus fluide?et donc plus rapide?

Trés cordialement, Vaillan†

 

[Polo35230]

- J'utilise Safari pour jouer et naviguer sur le net; Utiliser " Ubuntu " serait t'il plus fluide?et donc plus rapide?

On peut pas comparer Safari et Ubuntu. Safari est un Navigateur et Ubuntu un système d'exploitation Linux.

- Puis-je agir via le terminal pour diminuer mon Ping?

Si c'est pour avoir une latence plus basse, diminuer la taille du ping (elle est de 56 octets par défaut sur un Mac) en la passant à 20 par exemple, n'aurait qu'un effet très limité.
Je ne sais d'ailleurs pas comment la changer dans le mac...

Regarde l'impact entre un ping (56) par défaut, et un ping de 20 sur un serveur DNS de Numéricable.
Si on prend les valeurs moyennes, ça fait un gain de 0,7ms

imac:~ polo$ ping 89.2.0.1
PING 89.2.0.1 (89.2.0.1): 56 data bytes
64 bytes from 89.2.0.1: icmp_seq=0 ttl=56 time=30.574 ms
64 bytes from 89.2.0.1: icmp_seq=1 ttl=56 time=29.568 ms
64 bytes from 89.2.0.1: icmp_seq=2 ttl=56 time=29.053 ms
64 bytes from 89.2.0.1: icmp_seq=3 ttl=56 time=29.190 ms
64 bytes from 89.2.0.1: icmp_seq=4 ttl=56 time=29.358 ms
64 bytes from 89.2.0.1: icmp_seq=5 ttl=56 time=29.034 ms
^C
--- 89.2.0.1 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 29.034/29.463/30.574/0.530 ms
imac:~ polo$ ping -s 20 89.2.0.1
PING 89.2.0.1 (89.2.0.1): 20 data bytes
28 bytes from 89.2.0.1: icmp_seq=0 ttl=56 time=28.063 ms
28 bytes from 89.2.0.1: icmp_seq=1 ttl=56 time=28.085 ms
28 bytes from 89.2.0.1: icmp_seq=2 ttl=56 time=29.038 ms
28 bytes from 89.2.0.1: icmp_seq=3 ttl=56 time=28.805 ms
28 bytes from 89.2.0.1: icmp_seq=4 ttl=56 time=28.599 ms
28 bytes from 89.2.0.1: icmp_seq=5 ttl=56 time=29.581 ms
^C
--- 89.2.0.1 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 28.063/28.695/29.581/0.532 ms
imac:~ polo$

Sur ton réseau local, il n'y a pas grand chose à faire...

Par contre, j'ai vu que certains opérateurs proposaient des options joueurs.
Chez Free, c'est l'option Fastpath.
En réalité, cette option, c'est pas quelque chose en plus, mais c'est quelque chose en moins...
Pour aller plus vite, ils virent un dispositif de correction d'erreurs (interleaving) entre la box et le DSLAM (c'est sur l'ADSL).
Ca permet de gagner un peu sur la latence...
C'est bon pour les jeux, mais pas pour le reste...

Tu es chez Numéricable, c'est de la fibre. Ils n'y a donc pas de dispositifs de corrections d'erreurs utilisés sur l'ADSL.
J'en sais rien, mais s'ils ne proposent pas d'option joueur, c'est pour ça. Ils n'en ont pas besoin.