--
Le Rebelle wrote:
> Quelle est la valeur idéale du MTU en ADSL 1024 svp?
tout dépends du type de connexion utilisée
"Luc D.B." <yenatou...@pasdespam.com> a écrit dans le message de news:
3ECA381A...@pasdespam.com...
> Quelle est la valeur idéale du MTU en ADSL 1024 svp?
Ça dépend !
iSpeed (http://www.hms.com/ispeed.asp) sous Windows (1) possède une
option "Discover MTU" qui permet de vérifier quel est le meilleur MTU en
fonction du type de connexion et du FAI.
(1) Question posée avec X-Newsreader: Microsoft Outlook Express
6.00.2800.1106, donc sous Windows.
--
= Dominique Ottello = domi...@ottello-domi.nom.fr == Paris = France =
Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation :
il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau,
même si c'est pire qu'avant et cela de toute évidence. Montherlant
MTU = 1492 en PPPoE
mais pour connaitre la taille ideale
http://www.test-pilote.fr.st/Gestion%20du%20MTU.html
Dom
> "Le Rebelle" <webca...@yahoo.fr> écrivait :
>
> > Quelle est la valeur idéale du MTU en ADSL 1024 svp?
>
> Ça dépend !
Et pour ceux qui veulent mettre les mains dans le cambouis, voici un
fichier batch pour MS-DOS.
Nécessite Varset.exe, bien pratique pour effectuer toutes sortes
d'opérations sur les variables, dont les quatre opérations
mathématiques.
ftp://ftp.externet.hu/pub/mirror/sac/utilmisc/varset.zip
--------------------- Début - Couper ici -----------------------
@echo off
Rem +------------------------------------------------------------+
Rem ! Test de la valeur pr'conis'e de MTU !
Rem ! Appel par : TestMTU [Taille du paquet] [url ou adresse IP] !
Rem ! N'cessite Varset.exe disponible . : !
Rem ! ftp://ftp.externet.hu/pub/mirror/sac/utilmisc/varset.zip !
Rem +------------------------------------------------------------+
if "%1"=="" Goto Syntaxe
Set Paquet=%1
if "%2"=="" Goto Syntaxe
Set IP=%2
set Essai=1
:Boucle
echo Taille du paquet : %Paquet%
ping -f -n 1 -l %Paquet% %IP% | find "fragment'" > nul
if errorlevel 2 goto FindErr
if errorlevel 1 goto PasVu
if errorlevel 0 goto Vu
:Pasvu
Varset Essai + %Essai% 1
Varset Paquet + %Paquet% 1
goto Boucle
:Vu
if %Essai%==1 goto PaqErr
Varset Paquet - %Paquet% 1
Varset MTU + %Paquet% 28
Varset MSS - %MTU% 40
Varset RWIN * %MTU% 44
echo.
echo MTU pr'conis' : %MTU%
echo MSS pr'conis' : %MSS%
echo RWIN pr'conis' : %RWIN%
goto Fin
:PaqErr
echo.
echo La taille originelle du paquet est trop grande (%Paquet%)
echo.
goto Fin
:Syntaxe
echo.
echo Syntaxe d'appel - Manque au moins un paramStre
echo TestMTU [Taille du paquet] [url ou adresse IP]
echo.
goto fin
:FindErr
echo.
echo Erreur dans la commande Find
echo.
:Fin
Set MTU=
Set Paquet=
Set MSS=
Set RWIN=
Set IP=
--------------------- fin - couper ici -----------------
"Dominique Ottello" <otom...@fra.invalid> a écrit dans le message de news:
bnqkcv4lhe4up5uio...@4ax.com...
le ping -f -l 1464 www.rtl.fr
Dom
"Dom" <dom...@laposte.net> a écrit dans le message de news:
bae1pc$7u0$1...@news-reader14.wanadoo.fr...
Bonsoir,
Tout d'abord, le meilleur MTU ne dépends _que_ de votre type de connexion,
pas de son bridage.
Le MTU de base pour les calculs est 1500. C'est le maximum de données qui
peut passer sur un lien Ethernet (trames de 1518 octets maximum dont 18
d'en-tête).
IP, comme Ethernet, utilise des tailles de données variables, mais lors d'un
transfert soutenu de données (un téléchargement), tous les paquets échangés
excepté, peut-être le dernier, vont utiliser la taille maximale mise à leur
disposition. C'est bien cette taille max. qu'il faut analyser.
Puisque vous êtes en PPPoE, le lien Ethernet va être sollicité en plus pour
contenir les infos PPP (2 octets) et PPPoE (6 octets). Il ne reste plus que
1492 octets de MTU pour IP.
En PPPoE, l'ordinateur envoie dans le lien Ethernet un paquet PPPoE
contenant un paquet PPP lequel contient enfin le paquet IP. On parle d'IP
over PPP(2) over PPPoE(6) over Ethernet(18) dans une trame Ethernet faisant
1518 octets tout compris.
Comme on en est à l'opimisation, que votre accès est ADSL, il faut regarder
maintenant les étapes de transformation d'un paquet dans le modem.
Le modem va conserver la trame Ethernet _entière_, et va ajouter une
encapsulation dite AAL5, composée de deux parties :
- Un ajout au début des données correspondant à l'encapsulation LLC ou
VCMUX. En PPPoE, on est généralement en LLC/SNAP (10).
(Nota: Dans les modems, on trouve parfois une option "Frame Check Sequence",
rarement activée. Quand elle l'est, y'a 2 octets 'FCS' de plus à compter à
la fin. Ici, je vais les ignorer.)
- Un ajout à la fin des données à transporter d'une zone tampon puis d'un
"en-queue" (quel terme barbare...) CPCS (8). La zone tampon est calculée de
telle manière que la taille globale de la trame AAL5 soit un exact multiple
de 48 octets.
Cette zone tampon est là uniquement parce que ATM (utilisé par l'ADSL) ne
gère que des "paquets" (dits 'cellules') de taille _fixe_ ! Si l'on choisi
mal la taille des données, on peut se retrouver à envoyer des cellules de 53
octets (48 utiles, 5 d'en-tête) pour un seul octet utile... Pas glop :-(
Sans zone tampon, la taille de la trame AAL5 d'un paquet Ethernet de 1518
octets fait 1518+10+8 = 1536 octets...
Et paf ! :-D C'est un exact multiple de 48 !!! La zone 'tampon' ne
contiendra rien, aucun octet gaspillé.
=> Conclusion : Un MTU à 1492 octets est un MTU optimisé pour l'ADSL en
PPPoE LLC (sans FCS).
Oui, mais, expérimentalement, je me suis apperçu que les abonnés non
dégroupés ne sont pas logés à la même enseigne (Testés: Wanadoo,
Club-Internet, Cegetel et Free 512). Ceux qui passent par Wanadoo, peuvent
utiliser des MTUs jusqu'à 1500 octets sans problèmes, mais ceux qui
utilisent France Telecom pour l'ADSL mais un autre FAI que Wanadoo sont à
1460 octets. On peut voir de visu ce phénomène en faisant le test de
dslreports : http://www.dslreports.com/tweaks, en regardant le résultat,
ceux qui ne sont pas Wanadoo peuvent régler leur MTU sur n'importe quelle
valeur partant de 1460 à 1500 : le resultat est _toujours_ 1460 maximum !
Et le test du "ping -f -l" *ne* montre *pas* de fragmentation ! Je suppose
que cela est la conséquence du lien FT -> FAI utilisant un L2TP qui utilise,
comme par hasard, un en-tête supplémentaire global de 40 octets...
Donc, ceux qui ne sont pas Wanadoo mais qui passent par FT sont légèrement
ralentis par cette fragmentation 'd'arrière plan' qui se fait juste après le
BAS.
Solution ? Utiliser un MTU optimal pour ATM (zone tampon vide), mais
en-dessous des 1460 octets. On obtient ce MTU en soustrayant la valeur de
transport d'une cellule ATM: 1492 - 48 octets = 1444 octets. On est
en-dessous du plafond 1460.
=> 1444 octets est un MTU optimisé pour les abonnés non Wanadoo, non
dégroupés, en PPPoE LLC (sans FCS).
Et pour les gens dégroupés (LDCOM) ? Il faut tester !
Les gens utilisant Free Degroupé peuvent avoir des valeurs de MTU
différentes (peut-être) en USB ou en Ethernet... En IPoA, le MTU recommandé
par RFC est 9180 octets (si si ! RFC1626), mais via la liaison Ethernet, ça
ne dépassera pas les 1500 octets, alors qu'en USB, cette taille n'est pas
impossible...
A propos, en IPoA VCMUX, il n'y a qu'un seul en-queue CPCS (8) qui compte.
Et 9180 + 8 n'est pas multiple de 48... Enfin, vu la taille du monstre, les
quelques octets gaspillés ne représentent pas grand'chose.
--
Herm
Les aventuriers du MTU perdu...
cela ne devient pas simple!.
Dom
> => 1444 octets est un MTU optimisé pour les abonnés non Wanadoo, non
> dégroupés, en PPPoE LLC (sans FCS).
Merci pour cette excellente analyse !
En effet Wanadoo n'est pas logé à la même enseigne que les autres ISP. Les
Wanadiens sont directement sur le réseau IP de France Telecom à la sortie
des BAS, alors que les autres clients sont "tunnelés" jusqu'au LNS de leur
FAI.
--
Hervé LE ROY
Easynet France
Tout dépend effectivement de la manière dont sont livrés les flux abonnés
au provider. À mon humble connaissance, ils "pratiquent" le L2TP, avec des
BAS et tout et tout (eh si ! :/) mais aussi les VC ATM de bout en bout.
Mais visiblement ils réservent ça aux offres à débits garantis,
malheureusement. C'est dommage, car il serait bien agréable de pouvoir se
passer des (sur)couches PPP* et LLC/SNAP dans certains cas (PPPoE)...
--
Julien Lesaint.
> J'ai esayé, cela ne marche pas sous Win XP pro !!!
Ce doit être Varset.exe qui ne peut pas fonctionner sous XP. En effet,
la gestion des variables d'environnement est effectué différemment que
sous MS-DOS.
Il ne devrait pas être difficile (vu les possibilités de la ligne de
commande sous XP) de modifier le batch en remplaçant Varset.exe par la
commande qui va bien ; dans le cas de ce batch, ça ne sert qu'à faire
des calculs (entier) sur les variables.
--
+ Dominique Ottello - domi...@ottello-domi.nom.fr - Paris - France +
Il vaut mieux ignorer où l'on est, et savoir qu'on l'ignore, que de se
croire avec confiance où l'on n'est pas. Jacques Dominique Cassini.
Merci pour vos encouragements, et aussi aux lecteurs qui seront allés
jusqu'au bout ;-)
> En effet Wanadoo n'est pas logé à la même enseigne que les autres
> ISP. Les Wanadiens sont directement sur le réseau IP de France
> Telecom à la sortie des BAS, alors que les autres clients sont
> "tunnelés" jusqu'au LNS de leur FAI.
Ce qui est étrange, c'est que ce tunnel est invisible lors de tests ICMP par
Ping et flag IP 'DF'... C'est le paquet PPP tout entier qui est fragmenté
(auquel cas l'IP transporté à l'interieur ne saurait rien de la
fragmentation qui a eu lieu) ?
Ce que je constate, c'est simplement qu'un site de mesure -DSLReports pour
ne pas le nommer- ne me donne pas le même résultat que la mesure 'ping -f'
pour tout FAI non Wanadoo mais passant par France Telecom, alors que ça
correspond pile-poil pour Wanadoo...
Qui croire ?
Personnellement étant en PPPoA non Wanadoo, j'ai refait le calcul, et comme
je l'indiquais dans un message précédent, j'ai gagné quelques ko en fixant
un MTU à 1430. Optimisé, mais en-dessous de 1460... Un test à 1478 ne me
montre que peu de différence avec 1500.
Ce gain ne va pas très loin, c'est vrai, mais ... c'est gratuit !
---
Calculs pour PPPoA, via modem/routeur (valeurs utilisées aussi par les
modems USB ou cartes PCI en mode PPPoA) :
On reprends la base de calcul de 1500 octets, correspondant à la quantité de
données maximale pouvant être transporté par Ethernet (trame 1518 octets,
en-tête 18 octets). La trame Ethernet est toute-entière utilisée par IP, le
MTU est de 1500 octets donc.
Arrivé au modem/routeur, un encapsulation PPP(2) est _ajouté_ au paquet IP.
Taille du paquet PPP : 1500+2 = 1502 octets.
Ensuite, l'encapsulation AAL5 VCMUX ou LLC. En PPPoA, on utilise
généralement VCMUX, et dans les cas PPPoA ou IPoA, l'encapsulation VCMUX
n'ajoute rien au paquet : c'est comme s'il n'y avait pas d'encapsulation !
Puis l'encapsulation AAL5 CPCS. Ça ajoute au paquet PPP un buffer, puis 8
octets d'en-queue CPCS. La taille du buffer est calculé pour que le résultat
fasse une taille multiple de 48, et ne contient que des données de
remplissage. Mettons un buffer vide, la taille des données AAL5 fera
1502+8=1510, mais 1510 n'est pas multiple de 48, c'est 31*48+22 octets...
Donc un tampon de 26 octets (48-22) inutilisés est envoyé à chaque trame IP
émise...
=> En PPPoA VCMUX, le MTU1500 _n'est pas_ optimisé.
Reprenons à l'envers. Puisque l'on ne peut pas augmenter le MTU IP pour
utiliser pleinement les cellules ATM émises, limité que l'on est pas la
taille des données Ethernet de la source, l'on ne peut que réduire cette
taille. Partons sur 31 cellules complètement remplies.
Taille des données transporté par 31 cellules = 31*48 = 1488.
Moins l'en-tête CPCS (8) : 1480
Moins l'en-tête VCMUX (0) : 1480... Y'a pas d'en-tête si VCMUX et PPP.
Moins l'en-tête PPP(2): 1478
Taille max des données IP (MTU): 1478
=> Le MTU 1478 est optimisé en PPPoA VCMUX.
Oui, mais si l'on n'est pas Wanadoo, ça fragmente (?) dès que le MTU dépasse
1460... Enlevons l'équivalent du contenu d'une cellule ATM : 1478-48=1430.
=> Le MTU 1430 est optimisé en PPPoA VCMUX pour les abonnés non Wanadoo
passant par France Telecom.
Je re- le lien vers une calculette à PPPoA pour ceux qui préfèrent "de visu"
:
http://tjw.hn.org/calc/
--
Herm
En PPPoE, c'est le plus compliqué. Cf message plus loin pour le détail PPPoA
;-)
--
Herm
Bonsoir,
Et bien, il suffit d'aller chez Free dégroupé ;-)
Du pur IP over ATM, en VCMUX. Sans en-têtes PPP ni LLC/SNAP, mais par
contre, les modems et modems-routeurs ADSL ont du mal avec ça, comme par
exemple, le Speed Touch Home / Pro / Firewall / 510(v3), hormis le ST510(v4)
qui semble fonctionner (mais ce dernier est une toute autre bête).
Enfin, sauf si les cervaux de Forpage, qui tentent d'analyser le firmware du
STH / P / etc... , arrivent à implémenter cette fonction dans la boite !
--
Herm
> Et bien, il suffit d'aller chez Free dégroupé ;-)
>
> Du pur IP over ATM, en VCMUX. Sans en-têtes PPP ni LLC/SNAP, mais par
> contre, les modems et modems-routeurs ADSL ont du mal avec ça, comme par
> exemple, le Speed Touch Home / Pro / Firewall / 510(v3), hormis le
> ST510(v4) qui semble fonctionner (mais ce dernier est une toute autre
> bête).
Rumeur ou information pour le ST510. Je ne retrouve pas l'origine.
--
A.G.
ST510 version 4 uniquement, et pas le ST510v3 obtenu par... heu...
Suivre ce fil :
http://www.forpage.com/forum/viewtopic.php?mode=viewtopic&topic=2425&forum=30&start=15
--
Herm
Merci.
--
A.G.
Merci.
Mais au moment de l'ajouter sur la liste, je m'aperçois qu'un certain sense
POPO me l'avait déjà indiqué.
Il gardera donc la paternité de cette trace.
On ne relit jamais assez les FAQ. ;-)
--
A.G.