Obligement - L'Amiga au maximum

Vendredi 29 mars 2024 - 15:44  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

Actualité (récente)
Actualité (archive)
Comparatifs
Dossiers
Entrevues
Matériel (tests)
Matériel (bidouilles)
Points de vue
En pratique
Programmation
Reportages
Quizz
Tests de jeux
Tests de logiciels
Tests de compilations
Trucs et astuces
Articles divers

Articles in english


Réseaux sociaux

Suivez-nous sur X




Liste des jeux Amiga

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z,
ALL


Trucs et astuces

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Glossaire

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


En pratique : MTU - Présentation et configuration
(Article écrit par Philippe Bovier - juin 2004)


Introduction sur le MTU

MTU (Maximal Transmission Unit) est la plus grande taille possible d'un paquet de données, envoyée en une seule fois à travers le réseau Internet. Ce paquet transitera de la source désirée à votre FAI (Fournisseur d'Accès Internet) jusqu'à vous à travers de nombreux chemins, en passant par X routeurs, X passerelles et X protocoles réseau.

Le MTU maximum théorique est de 1500 (défini pour les plates-formes Windows). Cette taille maximale théorique est idéale pour les réseaux TCP (local), l'ADSL ou le câble mais pas pour un modem RTC (ancien protocole).

Un MTU=1500 ou approchant n'est pas grave en termes de réception avec l'ADSL. L'ADSL étant un protocole fiable et récent, un MTU non optimisé n'entraînerait pas une grande différence en vitesse de réception des données (vu la vitesse de travail de l'ADSL).

Principalement en RTC, si vous avez des messages d'erreurs ou des temps trop long lors d'accès à certains sites ou des chutes de débit lors de téléchargements FTP, il vous faut vérifier et/ou corriger cette valeur car c'est le signe d'une fragmentation des paquets de données.

Si votre MTU est trop grand, votre FAI scindera le paquet en autant de fois que nécessaire ce qui vous donnera une réception lente voire pas de réception du tout.

Description et valeurs standard

Chaque paquet se compose de données, appelé MSS (Maximum Segment Size) auquel s'ajoute un en-tête TCP et un en-tête IP.

MTU = MSS + en-tête TCP/IP.
MSS = MTU - 40 (40 = en-tête de 20 octets TCP + en-tête de 20 octets IP).

Valeur MTU Valeur MSS Utilisation idéale et théorique
1500 1460 Internet (câble, ADSL, Numéris...)
1496 1456 Ethernet standard
1492 1452 Plus grande valeur possible applicable à PPPoE
576 536 Modem 56k standard
...
552
...
496
...
296

Exemples concrets et théoriques

1. Premier exemple

Cas de transfert avec 1 500 000 octets de données à travers une ligne T1.
Note : le débit d'une ligne T1 est de 1 544 000 bits/sec.

1.1 Taille des paquets et temps d'attente

Temps d'attente en ms (milli-secondes) = [(MSS+HEADER) x 8 bits] / 1 544 000 bits/sec.

En utilisant différentes valeurs de MTU, nous pouvons calculer le temps d'attente de traversée d'un paquet dans le réseau T1.

MTU = 1500 : (1460+40) x 8 / 1 544 000 = 7,772 ms.
MTU = 576 : (536+40) x 8 / 1 544 000 = 2,984 ms.
Si, par exemple, il faut 10 paquets pour envoyer et recevoir ces données, il faudra donc :

MTU = 1500 : 77,72 ms.
MTU = 576 : 29,24 ms.

Un MTU plus petit transmet donc plus vite les données.

1.2 Taille et nombre de paquets

Reprenons le même exemple que précédemment mais avec juste 1 Mo. 1 Mo = 1024 ko = 1 048 576 octets.

MTU = 1500 :

(1460+40) x 8 / 1 544 000 = 7,772 ms.
1 Mo / MSS = 1 048 576 bytes / 1460 = 719 paquets pour 1 Mo.

Pour transférer 1 Mo :
719 paquets x 7,772 ms = 5 588 068 ms donc 5,588 secondes.

MTU = 576 :

(536+40) x 8 / 1 544 000 = 2,984 ms.
1 Mb / MSS = 1 048 576 octets / 536 = 1957 paquets pour 1 Mo.

Pour transférer 1 Mo :
1957 paquets x 2,984 ms = 5839,68 ms donc 5,840 secondes.

C'est un tout petit peu plus lent, mais la différence est négligeable pour un haut-débit comme le T1.

1.3 Taille des en-têtes TCP/IP

MTU = 1500 : (nombre de paquets x en-tête) = 719 x 40 = 28 760 octets.
MTU = 576 : (nombre de paquets x en-tête) = 1957 x 40 = 78 280 octets.

La quantité de données des en-têtes est supérieure avec 576 (78 280 octets). Les 49 550 bytes supplémentaires en MTU = 576 ne représentent qu'une infime fraction du total des données (ici avec un exemple de 1 048 576 octets).

1.4 En résumé (pour l'exemple de la ligne T1)

Un petit MTU transmet plus de paquets et plus vite qu'un gros MTU. La différence de taille des en-têtes transmises est infime comparé à la taille des données.

On peut donc juger par ces calculs qu'il est impérativement important d'avoir un bon MTU et pas obligatoirement le plus grand possible. La valeur du MTU choisie dépendra du matériel, du FAI et du type de connexion utilisé (RTC ou ADSL).

La différence de temps d'attente entre un MTU = 1500 et un MTU = 576 est presque négligeable avec l'exemple précédent avec une ligne T1 rapide. Cette différence sera plus importante avec une simple connexion par modem RTC (RTC étant un ancien protocole moins fiable et régulier en émission et réception que l'ADSL).

2. Second exemple

Cas avec un Amiga et MiamiDX avec modem RTC 56k.

Une connexion par défaut, faite par MiamiInit, règle le MTU par défaut à 552. Cette valeur par défaut ne peut être qu'une base de départ qu'il vous faut vérifier de chez vous.

L'article considère que le lecteur connaît dans son programme TCP/IP où se situe la valeur MTU à modifier selon ses besoins.

Les exemples suivants existent uniquement avec mon Amiga et son matériel (modem, carte série...). Les résultats que vous allez obtenir seront sûrement différents mais au moins ils auront été contrôlés grâce à la suite de cet article.

2.1 Programmes complémentaires (exemples RTC ou ADSL)

Il est possible graphiquement de vérifier vos transferts Internet avec votre Amiga de deux façons bien plus pratiques car visuelles :

Miamigraph

Disponible sur Aminet. Avec son appel lors de la connexion : MiamiDX -> Évémements -> Démarrer.

MiamiGraph PERIOD=50 DIVISIONS=1 BCOL=000000 GCOL=00FF00 DCOL=FF0000 BORDERLESS INTERFACE=ppp0 (ppp0 à changer selon le nom de votre connexion).

GelBesPanel

Chargement à partir de MiamiDX -> GUI -> Réglages panneaux de contrôles. Disponible sur gelbespanel.amigazeux.net.

MiamiGraph

MiamiGraph.
GelBesPanel

GelBesPanel.

2.2 MiamiPing avec valeur 296, 492, 568, 1492 et modem 56k RTC à 45333

Pour mesurer le temps de réponse d'un paquet envoyé vers un endroit, il nous faut utiliser l'utilitaire MiamiPing fourni dans l'archive de MiamiDX.

Cet utilitaire possède la ligne de commande suivante :

usage: MiamiPing [-Rdfnqrv] [-c count] [-i wait] [-l preload] [-p pattern] [-s packetsize] host

-f = rapide
-c 10 = nombre d'essais
-s 492 = MTU
294.217.300.20 = club-internet.fr (la valeur pour cet article est un exemple).

La valeur 294.217.300.20 se trouve dans : Miami -> base de données -> serveurs DNS.

296 rapide avec -f :

MiamiPing -f -c 10 -s 296 294.217.300.20
PING 294.217.300.20 (294.217.300.20): 296 data bytes
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 182,026/185,238/190,497 ms

MiamiPing -f -c 10 -s 296 294.217.300.20
PING 294.217.300.20 (294.217.300.20): 296 data bytes
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 180,574/184,861/189,658 ms

MiamiPing -f -c 10 -s 296 294.217.300.20
PING 294.217.300.20 (294.217.300.20): 296 data bytes
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 180,959/185,057/190,57 ms

Miami/MiamiPing -f -c 10 -s 296 294.217.300.20
PING 294.217.300.20 (294.217.300.20): 296 data bytes
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 177,682/187,284/198,666 ms

492 rapide avec -f :

MiamiPing -f -c 10 -s 492 294.217.300.20
PING 294.217.300.20 (294.217.300.20): 492 data bytes
11 packets transmitted, 10 packets received, 8% packet loss
round-trip min/avg/max = 253,64/304,9/328,725 ms

568 rapide avec -f :

MiamiPing -f -c 10 -s 568 294.217.300.20
PING 294.217.300.20 (294.217.300.20): 568 data bytes
12 packets transmitted, 10 packets received, 16% packet loss
round-trip min/avg/max = 254,235/312,683/387,104 ms

1492 rapide avec -f :

MiamiPing -f -c 10 -s 1492 294.217.300.20
PING 294.217.300.20 (294.217.300.20): 1492 data bytes
13 packets transmitted, 10 packets received, 23% packet loss
round-trip min/avg/max = 440,244/570,651/671,445 ms

1492 normal sans -f :

Une ligne de commande sans -f permet d'avoir une plus grande description de la transmission des paquets mais aucun ne sera perdu car MiamiPing attend la réception avant d'envoyer un paquet de nouveau.

MiamiPing -c 10 -s 1492 294.217.300.20
PING 294.217.300.20 (294.217.300.20): 1492 data bytes
1500 bytes from 294.217.300.20: icmp_seq=0 ttl=252 time=437,072 ms
1500 bytes from 294.217.300.20: icmp_seq=1 ttl=252 time=446,639 ms
1500 bytes from 294.217.300.20: icmp_seq=2 ttl=252 time=450,65 ms
1500 bytes from 294.217.300.20: icmp_seq=3 ttl=252 time=444,363 ms
1500 bytes from 294.217.300.20: icmp_seq=4 ttl=252 time=445,099 ms
1500 bytes from 294.217.300.20: icmp_seq=5 ttl=252 time=444,067 ms
1500 bytes from 294.217.300.20: icmp_seq=6 ttl=252 time=435,679 ms
1500 bytes from 294.217.300.20: icmp_seq=7 ttl=252 time=444,741 ms
1500 bytes from 294.217.300.20: icmp_seq=8 ttl=252 time=442,912 ms
1500 bytes from 294.217.300.20: icmp_seq=9 ttl=252 time=442,271 ms
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 435,679/443,349/450,65 ms

2.3 En résumé (pour l'exemple modem 56k à 45333)

Nous pouvons observer deux choses :

Plus le MTU est petit, plus le temps de réception des paquets est petit (296 rapide avec -f = 185 ms et 1492 rapide avec -f = 570 ms).

Plus le MTU est petit, plus le nombre de paquets est envoyé rapidement, plus le nombre de paquets perdus est faible (296 rapide avec -f = 0 de perdu, et 1492 rapide avec -f = 3 de perdus).

Que faire alors ?

1. Faites des essais avec MiamiPing -f -c xx -s xxxx xxx.xxx.xxx.xx avec différentes valeurs et plusieurs fois les mêmes valeurs jusqu'à trouver le bon MTU. Un bon MTU sera une commande -f lancée de nombreuses fois sans perte de paquets.

2. Faites les mêmes essais à d'autres périodes de la journée ou le week-end pour valider votre valeur MTU trouvée.

3. Installez Miamigraph et GelBesPanel pour visualiser vos essais graphiquement et même en valeur instantanée avec GelBesPanel. Vous allez vous rendre compte graphiquement que plus le MTU est petit, plus la valeur moyenne de réception des données est grande. Vous constaterez que, avec une connexion à 45 333 (6000 octets maxi avec les en-têtes TCP + IP) :
  • Avec un MTU = 1500, vous recevrez 3 ou 4 paquets de 1500 ce qui donnera une moyenne basse (1500 x 3 = 4500 + 40 x 3 = 4620).
  • Avec un MTU environ 1000, vous recevrez 5 ou 6 paquets de 1000 ce qui augmentera votre moyenne (1000 x 5 = 5000 + 40 x 5 = 5200).
  • Avec un MTU d'environ 500, vous recevrez 10 ou 11 paquets de 500 ce qui augmentera votre moyenne vers une moyenne idéale (500 x 10 = 5000 + 40 x 10 = 5400).
  • Avec un MTU d'environ 250, vous recevrez 20 ou 21 paquets de 500 ce qui va faire baisser un peu votre moyenne car le nombre d'en-têtes sera maintenant trop important (250 x 20 = 5000 + 40 x 20 = 5800).
Le résultat pourra être un MTU à 296, 492 ou 568 pour un modem RTC et 1500 ou approchant pour un modem ADSL ou câble. Ce résultat sera valable pour votre installation avec votre modem, vos câbles de liaison jusqu'à votre ligne téléphonique et la qualité de votre ligne téléphonique.

4. Vérifiez vos résultats en utilisant des sites Internet comme ceux cités dans le chapitre suivant (ftpk ou sdv). Ceux-ci vous donneront des résultats sous forme graphique avec comparaison avec le RTC, ADSL ou le câble.

Sites Internet intéressants

Pour connaître sa vitesse de connexion (en descente) en mode compression ou non :

bw.sdv.fr.

Pour connaître sa vitesse de connexion (en descente) sans compression avec des informations sur l'adresse du premier routeur de chez vous :

services.ftpk.net/speedtest/test.
mire.ipadsl.net.

Test complet mais pour les États-Unis (pour information) :

pcpitstop.com/internet.

Bien sûr, il en existe bien d'autres encore.

Conclusion

J'espère que cet article vous sera utile, d'abord général puis axé plutôt sur le côté pratique Amiga en RTC, avec des conseils complémentaires.

Le but recherché est de donner une méthode Amiga pour contrôler et vérifier la valeur MTU utilisable avec un matériel Amiga et une localisation géographique en rapport avec son FAI.

La valeur MTU miracle n'existe pas pour tous les cas (sauf en ADSL) mais ici, l'utilisateur arrivera à comprendre et à modifier sa valeur MTU vers une valeur presque idéale pour lui.


[Retour en haut] / [Retour aux articles]