En théorie, le jeu peut fonctionner avec des vitesses très basses, voire du 56K sur ligne analogique.
Dans les faits, le jeu fonctionne avec la période souhaitée définie par les joueurs (de 10s / minute à 60s /minute)
Au cas où les transferts de données ne sont pas terminés à la fin de la période, le jeu se met en pause... bien sûr que ce n'est pas top.
Dans ce cas, il suffit d'augmenter le temps de la simulation (en passant de 10s/min à 20s/min, vous permettez de doubler le nombre de données transmises avant de passer à la séquence temporelle suivante).
En MP, il est important que le hôte ait le débit montant le plus important.. mais si plusieurs joueurs ont des débits montants supérieurs à 64 Ko, mieux vaut prendre celui dont le PC semble le meilleur en puissance de calcul.
Par ailleurs, le ping n'est pas une information dimensionnant HW car le système utilisé découpe le temps de simulation en période de une minute, les données de la simulation étant calculées pour la séquence suivante alors que l'on affiche la simulation de la séquence précédente. Pour illustrer, nous avons réalisé des tests avec Hook alors que ce dernier utilise une liaison satelitaire avec un ping de 1500ms.. un débit montant faible (peut être 8 Ko/s) et un débit descendant de 256 Ko/s (si je me souviens bien). Il va sans dire que Hook ne peut être l'hôte d'une partie mais néanmoins il peut jouer sans problème à HW.
JMM
Pour XP :
Je suis en train de regarder si je ne peux pas améliorer mon débit de bande passante (sans que ce soit instable) avec le logiciel TCP Optimizer (également Dr PC pour voir une autre valeur MTU) et pour l'instant ça me semble pas trop mal...
Je suis resté stable pour le TTL*, j'ai réussi à trouver la valeur maximum de MTU** et commencer à régler mon RWIN*** (qui doit être un multiple de MSS****)
A gauche mes nouveaux paramètres à droite les anciens par défaut.
J'ai d'abord réglé la vitesse de connexion puis recherché ma valeur MTU avec logiciel TCP Optimizer (Onglet "MTU/Latency" et cliquer sur le bouton "Largest MTU") puis je suis partis du principe que pour TTL, 128 était la valeur par défaut, ensuite il fallait trouver le juste milieux entre l'augmentation du débit "upload et download" et le risque d'avoir des pertes de données (valeur RWIN trop grande)
4835 kbps down (~4.84 Mbps, 590 KB/s)↓
455 kbps up (~0.46 Mbps, 56 KB/s)↑
Pour l'instant le débit montant est encore limite, mais si je monte plus la valeur RWIN il-y-a le risque plus important de pertes de données...
*TTL (Time To Live) est une valeur définie dans l'en-tête des paquets IP sortants. TTL détermine le montant maximum de temps (en secondes) d'un paquet IP peut vivre, ou le nombre de routeurs d'un paquet IP peut traverser avant d'être jeté (le plus bas).
TTL (Time To Live) is a value set in the header of outgoing IP packets. TTL determines the maximum amount of time (in seconds) an IP packet can live, or the number of routers an IP packet may pass through before being discarded (whichever is lower).
**MTU (Maximum Transmission Unit) est la plus grande quantité de données qui peuvent être transférées dans un cadre physique sur le réseau. Si un paquet qui a un MTU plus petit que la longueur de trame du paquet est envoyé, la fragmentation se produit. Pour TCP (Transmission Control Protocol) MTU peut varier de 68 à 1500 octets. MTU plus grand permet de réduire les frais généraux (moins de têtes).
MTU (Maximum Transmission Unit) is the greatest amount of data that can be transferred in one physical frame on the network. If a packet that has a smaller MTU than the packet's frame length is sent, fragmentation will occur. For TCP (Transmission Control Protocol) MTU can range from 68 to 1500 bytes. Larger MTUs provide for lower overhead (fewer headers).
***RWIN (TCP Receive Window) est un tampon qui détermine la quantité de données à l'ordinateur récepteur est prêt à recevoir en même temps.
Une valeur RWIN qui est trop grande se traduira par une plus grande perte de données si un paquet est perdu ou endommagé. Un RWIN trop petit sera très lent, comme chaque paquet devra être reconnu avant que le paquet suivant est envoyé.
RWIN est l'un des paramètres les plus importants dans le peaufinage de toute connexion TCP / IP.
RWIN (TCP Receive Window) is a buffer that determines how much data the receiving computer is prepared to get at one time.
A RWIN value that's too large will result in greater loss of data if a packet is lost or damaged. A too small RWIN will be very slow, as each packet will have to be acknowledged before the next packet is sent.
RWIN is one of the most important parameters in tweaking any TCP/IP connection.
****MSS (Maximum Segment Size) définit le plus grand segment de TCP (Transfer Control Protocol) de données que le Winsock est disposé à recevoir. Quand une connexion est établie, les deux extrémités d'accord pour utiliser la plus petite de la valeur de chaque final. Parce que en-têtes sont généralement de 40 octets, MSS est habituellement de 40 inférieure à la MTU (Maximum Transmission Unit).
MSS (Maximum Segment Size) defines the largest segment of TCP (Transfer Control Protocol) data that the Winsock is prepared to receive. When a connection is established, the two ends agree to use the smaller of each end's value. Because headers are typically 40 bytes, MSS is usually 40 less than the MTU (Maximum Transmission Unit).
Il va falloir que je vois, si ça à amélioré quelque chose lors de ma prochaine rencontre en multi...
Sources :
http://lafibre.info/bbox-tutoriels/optimiser-windows-xp-pour-avoir-de-meilleurs-debits-avec-bbox/http://www.echosdunet.net/dossiers/dossier_1063_optimiser%20sa%20connexion%20internet%20avec%20tcp%20optimizer.htmlhttp://www.echosdunet.net/dossiers/dossier_974_verification+reglage+votre+mtu+sous+windows.htmlQuelques tests :
http://www.speedguide.net/analyzer.phphttp://www.speedguide.net/speedtest/