Raisonnement de SAGEM:
*1460 pour tout le monde = USB peu pénalisé, ethernet content.
*1500 pour tout le monde = USB content, ethernet catastrophique
(péniche 1500 ne passe plus = fragmentation).
La décision est vite prise !
ou est-ce pour optimiser au max la connexion adsl ?
Oui, péniche de 1500 sur canal de 1500 = tiptop !
Ou se situe ce paramètre ? impossible de mettre la main dessus ???
"*RWIN = si tu utilises plus grand que 65535, pense à changer
vtcp.386 version 4.10.2222 buguée bridée à 65535 par 4.10.2223"
RWIN is the TCP Receive Window = DefaultRcvWindow dans le registre
Win98 = HKLMSystemCurrentControlSetServicesVxDMSTCP
N'existe pas si d'origine (défaut92), apparaît à la bidouille
(65535 pour la plupart des drivers ADSL), va jusqu'à 256960.
Cette valeur est bonne pour tous les usages, à ne modifier que pour
amusement par des gens avertis (REGISTRE CORROMPU = REINSTALL
COMPLETE !!!). Dépend de VTCP.386 dont la première version 4.10.2222
était buguée limitant à 65535 (ceci expliquant cela ?).
La 4.10.2223 monte semble-t-il à 256960.
RWIN est un entrepôt intermédiaire où on stocke le contenu de
plusieurs péniches avant de vérifier la marchandise et signer le reçu.
Si anomalie, on jette tout ce qui est dans l'entrepot et on fait
relivrer. Gros entrepôt = travail plus rapide.
Si erreur, gros entrepôt = travail moins rapide, il faut trouver le
bon compromis.
Les (re)livraisons étant beaucoup plus rapides en ADSL qu'en RTC donc
moins pénalisantes, on utilise de gros entrepôts:
RTC = Win98 = 8192
ADSL = driver ADSL = 65535
Dans ce groupe, lire les contributions de Rémy MOULIN qui signe Herm.
[...]
Raisonnement de SAGEM:
*1460 pour tout le monde = USB peu pénalisé, ethernet content.
*1500 pour tout le monde = USB content, ethernet catastrophique
(péniche 1500 ne passe plus = fragmentation).
La décision est vite prise !
ou est-ce pour optimiser au max la connexion adsl ?
Oui, péniche de 1500 sur canal de 1500 = tiptop !
Ou se situe ce paramètre ? impossible de mettre la main dessus ???
"*RWIN = si tu utilises plus grand que 65535, pense à changer
vtcp.386 version 4.10.2222 buguée bridée à 65535 par 4.10.2223"
RWIN is the TCP Receive Window = DefaultRcvWindow dans le registre
Win98 = HKLMSystemCurrentControlSetServicesVxDMSTCP
N'existe pas si d'origine (défaut92), apparaît à la bidouille
(65535 pour la plupart des drivers ADSL), va jusqu'à 256960.
Cette valeur est bonne pour tous les usages, à ne modifier que pour
amusement par des gens avertis (REGISTRE CORROMPU = REINSTALL
COMPLETE !!!). Dépend de VTCP.386 dont la première version 4.10.2222
était buguée limitant à 65535 (ceci expliquant cela ?).
La 4.10.2223 monte semble-t-il à 256960.
RWIN est un entrepôt intermédiaire où on stocke le contenu de
plusieurs péniches avant de vérifier la marchandise et signer le reçu.
Si anomalie, on jette tout ce qui est dans l'entrepot et on fait
relivrer. Gros entrepôt = travail plus rapide.
Si erreur, gros entrepôt = travail moins rapide, il faut trouver le
bon compromis.
Les (re)livraisons étant beaucoup plus rapides en ADSL qu'en RTC donc
moins pénalisantes, on utilise de gros entrepôts:
RTC = Win98 = 8192
ADSL = driver ADSL = 65535
Dans ce groupe, lire les contributions de Rémy MOULIN qui signe Herm.
[...]
Raisonnement de SAGEM:
*1460 pour tout le monde = USB peu pénalisé, ethernet content.
*1500 pour tout le monde = USB content, ethernet catastrophique
(péniche 1500 ne passe plus = fragmentation).
La décision est vite prise !
ou est-ce pour optimiser au max la connexion adsl ?
Oui, péniche de 1500 sur canal de 1500 = tiptop !
Ou se situe ce paramètre ? impossible de mettre la main dessus ???
"*RWIN = si tu utilises plus grand que 65535, pense à changer
vtcp.386 version 4.10.2222 buguée bridée à 65535 par 4.10.2223"
RWIN is the TCP Receive Window = DefaultRcvWindow dans le registre
Win98 = HKLMSystemCurrentControlSetServicesVxDMSTCP
N'existe pas si d'origine (défaut92), apparaît à la bidouille
(65535 pour la plupart des drivers ADSL), va jusqu'à 256960.
Cette valeur est bonne pour tous les usages, à ne modifier que pour
amusement par des gens avertis (REGISTRE CORROMPU = REINSTALL
COMPLETE !!!). Dépend de VTCP.386 dont la première version 4.10.2222
était buguée limitant à 65535 (ceci expliquant cela ?).
La 4.10.2223 monte semble-t-il à 256960.
RWIN est un entrepôt intermédiaire où on stocke le contenu de
plusieurs péniches avant de vérifier la marchandise et signer le reçu.
Si anomalie, on jette tout ce qui est dans l'entrepot et on fait
relivrer. Gros entrepôt = travail plus rapide.
Si erreur, gros entrepôt = travail moins rapide, il faut trouver le
bon compromis.
Les (re)livraisons étant beaucoup plus rapides en ADSL qu'en RTC donc
moins pénalisantes, on utilise de gros entrepôts:
RTC = Win98 = 8192
ADSL = driver ADSL = 65535
Dans ce groupe, lire les contributions de Rémy MOULIN qui signe Herm.
[...]
Michael wrote:Waaah trop balèze
<:o)))
Pas balèze du tout !
C'est juste le souhait -imprudent !- de rendre service à quelqu'un qui
utilise la même configuration que moi et qui disait son désarroi.
L'étendue de mes incompétences m'expose à tout moment à un tacle
meurtrier,
à la carotide, de n'importe lequel des pensionnaires de ce groupe.
Il ne faut pas oublier que ces quelques notions intégrées péniblement sont
le résultat d'énormes con...ries passées.
Amitiés.
Michael wrote:
Waaah trop balèze
<:o)))
Pas balèze du tout !
C'est juste le souhait -imprudent !- de rendre service à quelqu'un qui
utilise la même configuration que moi et qui disait son désarroi.
L'étendue de mes incompétences m'expose à tout moment à un tacle
meurtrier,
à la carotide, de n'importe lequel des pensionnaires de ce groupe.
Il ne faut pas oublier que ces quelques notions intégrées péniblement sont
le résultat d'énormes con...ries passées.
Amitiés.
Michael wrote:Waaah trop balèze
<:o)))
Pas balèze du tout !
C'est juste le souhait -imprudent !- de rendre service à quelqu'un qui
utilise la même configuration que moi et qui disait son désarroi.
L'étendue de mes incompétences m'expose à tout moment à un tacle
meurtrier,
à la carotide, de n'importe lequel des pensionnaires de ce groupe.
Il ne faut pas oublier que ces quelques notions intégrées péniblement sont
le résultat d'énormes con...ries passées.
Amitiés.
Reclus wrote:
Raisonnement de SAGEM:
*1460 pour tout le monde = USB peu pénalisé, ethernet content.
*1500 pour tout le monde = USB content, ethernet catastrophique
(péniche 1500 ne passe plus = fragmentation).
La décision est vite prise !
Bonsoir,
La taille des canaux (jolie, l'analogie :-) ) en Ethernet est aussi de
1500.
Mais en effet, pour l'Ethernet, tout dépends si l'on utilise un modem
Ethernet ou un routeur Ethernet !
Les modems (Ethernet inclus) ne savent pas ouvrir la connexion
(identifiant
/ mot de passe de connexion) par eux-même. C'est l'ordinateur qui en a la
tâche, et ça se fait en "langue" (protocole) PPP.
Mais PPP ne sait transiter que sur des liaisons dites "points à points"
(PPP
= Point to Point Protocol), c'est à dire, des liaisons où seuls deux
appareils dialoguent, pas plus. PPP, en fait, ne connaît que deux entités
:
"moi" et "l'autre".
C'est parfaitement Ok dans le cas de liaison série (sur une prise COM1,
COM2, etc. , on ne relie qu'un seul appareil), une liaison PCI (il y a
autant de canaux PCI que de slots dans la machine, et sur un slot, on ne
peut mettre qu'une carte, pas plus), ou une liaison USB (chaque
périphérique
USB possède un identifiant, et le contrôleur USB ouvre un canal 'virtuel'
vers le modem pour chaque communication).
Ethernet, ce n'est pas du point à point. Pour chaque trame envoyée, il
faut
indiquer nominativement le destinataire... "Moi", "l'autre" : aucun sens
en
Ethernet. Mais on peut installer des protocoles qui, eux, savent ouvrir un
canal de dialogue à deux extrémités par-dessus un réseau (Ethernet ou
autre
!) : Ex: PPTP et PPPoE...
Ces deux zouaves "consomment" de la place, de façon imagée, ils sont des
"barges" dans lesquelles on installerait les "péniches".
Si la péniche fait pile poile la taille du canal, mettre la péniche dans
une
barge, et boum, l'ensemble ne passe plus dans le canal : obligé d'utiliser
des péniches plus petites !
Ce souci n'apparaît pas avec les routeurs : c'est le routeur qui s'occupe
de
l'authentification PPP, et ce qui sort de la prise Ethernet, c'est de
l'Internet "tout cuit". Les trames PPP n'empruntent pas la liaison
Ethernet,
qui est le canal étroit de l'ensemble, donc les péniches 1500 sont
possibles.
Avec les modems USB (pûr USB) ou PCI, carrément, on a de l'Ethernet nulle
part, on est pas limité à 1500 en théorie, on pourrait faire plus.ou est-ce pour optimiser au max la connexion adsl ?
Oui, péniche de 1500 sur canal de 1500 = tiptop !
Uniquement s'il n'y a pas besoin de "barges" (ici : modem USB, pas de
problème), et si on est pas limité plus loin !
Il faut bien voir que le chemin entre l'abonné et le FAI est un parcours
d'obstacles, et que le MTU de l'ensemble égal le MTU de la zone la plus
rétrécie du parcours...
Pour un abonné non Wanadoo :
Abonné
|
| USB (Trames PPP, MTU implicite en IP(1500) over PPP(2) = 1502)
|
Modem USB
|
| ATM o ADSL (Trames IP o PPP o ATM o ADSL, aka "PPPoA")
| (Limite conventionnelle : 9180 (!!!) )
| (Les trames IPoPPP faisant 1502 passent "à l'aise")
|
DSLAM Opérateur ADSL
|
| ATM (Trames IP o PPP o ATM reconstituées)
| (depuis les signaux ADSL échangés)
| (Même limite conventionnelle que ci-dessus)
|
BAS Opérateur ADSL (France Télecom (et LDCOM?) )
|
| ??? (Trames IP o PPP o L2TP o ???)
| (Limite = ???)
|
EAS France Telecom, chez le FAI
|
| Ethernet (IP o PPP o L2TP o UDP/IP o Ethernet)
| (Limite : 1460 (hypothèse) ! )
|
LNS Fournisseur d'Accès Internet (Enfin !)
En abonné Wanadoo, il n'y a pas utilisation de tunnel L2TP, donc pas de
limite à 1460...
En décortiquant le protocole ATM, on s'apperçoit que ça commence par
ajouter
un en-tête , donc ça entre dans une "barge" (8 octets en PPPoA VCMUX) et
que
ça utilise des petits paquets de taille utile de 48 octets seulement (Les
barges sont découpées, chaque morceau transporté séparément, puis la barge
et le contenu sont re-soudés à l'arrivée !).
Mieux : ces petits paquets, ces cellules ATM, ont une taille fixe. Remplie
ou ne contenant qu'un seul octet, c'est 48 octets + 5 d'en-tête de cellule
qui partent !
Donc optimiser = faire en sorte que toutes les cellules soient pleines,
tout
le temps !
En PPPoA VCMUX, le nombre d'octets IP transportables pour x cellules vaut:
MTU optimisé = [x * 48 (taille utile d'une cellule)] - 2 (PPP) - 8
(ATM.CPCS)
Si l'on prends x = 32, on obtient MTU26 : trop gros pour PPP qui, par
défaut, utilise un maximum de 1500.
Si l'on prends x = 31, ça donne 1478 : Impec pour les abonnés Wanadoo,
mais
trop gros pour les autres avec le tunnel L2TP.
Si l'on prends x = 30, on obtient 1430. C'est ce que j'utilise comme
réglage, étant Club-Internet non dégroupé, avec routeur connecté en PPPoA
VCMUX.
type de mesure quantité minimum moyenne maximum
download 59 59,4 Ko/sec 61,8 Ko/sec 62,7 Ko/sec
upload 43 14,0 Ko/sec 16,1 Ko/sec 16,4
Ko/sec
http://www.grenouille.com/graph/index.php?zone 132
Attention, pour PPPoE, la formule est différente :
MTU Max = 1492 (à cause de la "barge" PPPoE)
MTU optimisé = [x * 48 ] - 40
x = 32, MTU = 1496 : Trop grand
x = 31, MTU = 1448 : Impec.Ou se situe ce paramètre ? impossible de mettre la main dessus ???
"*RWIN = si tu utilises plus grand que 65535, pense à changer
vtcp.386 version 4.10.2222 buguée bridée à 65535 par 4.10.2223"
RWIN is the TCP Receive Window = DefaultRcvWindow dans le registre
Win98 = HKLMSystemCurrentControlSetServicesVxDMSTCP
N'existe pas si d'origine (défaut92), apparaît à la bidouille
(65535 pour la plupart des drivers ADSL), va jusqu'à 256960.
Cette valeur est bonne pour tous les usages, à ne modifier que pour
amusement par des gens avertis (REGISTRE CORROMPU = REINSTALL
COMPLETE !!!). Dépend de VTCP.386 dont la première version 4.10.2222
était buguée limitant à 65535 (ceci expliquant cela ?).
La 4.10.2223 monte semble-t-il à 256960.
Ou, pour éviter de faire des recherches un peu fastidieuses dans la base
de
registre, ce petit utilitaire sans installation est très bien :
http://www.dslreports.com/drtcpRWIN est un entrepôt intermédiaire où on stocke le contenu de
plusieurs péniches avant de vérifier la marchandise et signer le reçu.
Si anomalie, on jette tout ce qui est dans l'entrepot et on fait
relivrer. Gros entrepôt = travail plus rapide.
Si erreur, gros entrepôt = travail moins rapide, il faut trouver le
bon compromis.
Les (re)livraisons étant beaucoup plus rapides en ADSL qu'en RTC donc
moins pénalisantes, on utilise de gros entrepôts:
RTC = Win98 = 8192
ADSL = driver ADSL = 65535
Heu... j'ai une autre version de l'histoire ...
RWIN est un entrepôt intermédiaire pour stocker des paquets qui
arriveraient
dans le désordre.
Imaginons que les péniches n° 1 2 3 et 4 arrivent dans cet ordre : 1 3 4
2.
La péniche 1 arrive, elle était attendue, le contenu est immédiatement
déchargé et envoyé au traitement, un accusé de réception est signé et
renvoyé à l'expéditeur. L'indicateur de débit se positionne sur le débit
normal (mettons : 64 ko/s)
La péniche 3 arrive... Mais on attendait la péniche 2 ! On décharge la
péniche 3 dans le dépot RWIN, au premier emplacement. Rien n'est envoyé au
traitement. Une photocopie de l'accusé de réception de la péniche 1 est à
nouveau envoyée, et si l'option TCP/IP "Selective Acknowledgement" est
active (cf DrTCP), un mot est indiqué en marge de l'accusé de réception
indiquant "Reçu le n° 3"). L'indicateur de débit baisse (32ko/s)...
La péniche 4 arrive... Toujours pas de péniche 2 en vue.... La péniche 4
est
déchargée dans RWIN, second emplacement, toujours rien vers le traitement.
Re-photocopie de l'accusé de réception de la péniche 1, et si option
"Selective ACKs", info crayonée : "Reçus n°3 et n°4"). L'indicateur de
débit
baisse encore (16ko/s)...
Finalement, la péniche 2 est arrivéééeee, sans s'presseeer (pardon...).
Elle
est immédiatement déchargée en envoyée au traitement, puis immédiatement,
les chargements RWIN emplacement 1 et 2 (ex- péniches 3 et 4) sont
envoyées
successivement au traitement, un accusé de réception pour la péniche 4 est
envoyée (implicitement, ça vaut quitus pour les péniches 2, 3 et 4), et
...
l'aiguille de débit fait temporairement un bond ! (144 ko/s, pour
rattraper
le retard).
Avoir un gros RWIN ne signifie pas que les accusés de réceptions seront
retardés, mais plutôt qu'en cas de liaison Internet aléatoire, moins de
paquets devront être re-émis s'ils ont pu être stockés dans l'entrepôt
RWIN.
Il fut un temps où un buffer de 16 ko était énorme, mais au jour
d'aujourd'hui, avec des machines de plusieurs centaines de Mo de RAM en
standard, qu'est ce que c'est, 64 ko, hein ?Dans ce groupe, lire les contributions de Rémy MOULIN qui signe Herm.
[...]
Ouille, les chevilles ;-) :-P
--
Herm
Reclus wrote:
Raisonnement de SAGEM:
*1460 pour tout le monde = USB peu pénalisé, ethernet content.
*1500 pour tout le monde = USB content, ethernet catastrophique
(péniche 1500 ne passe plus = fragmentation).
La décision est vite prise !
Bonsoir,
La taille des canaux (jolie, l'analogie :-) ) en Ethernet est aussi de
1500.
Mais en effet, pour l'Ethernet, tout dépends si l'on utilise un modem
Ethernet ou un routeur Ethernet !
Les modems (Ethernet inclus) ne savent pas ouvrir la connexion
(identifiant
/ mot de passe de connexion) par eux-même. C'est l'ordinateur qui en a la
tâche, et ça se fait en "langue" (protocole) PPP.
Mais PPP ne sait transiter que sur des liaisons dites "points à points"
(PPP
= Point to Point Protocol), c'est à dire, des liaisons où seuls deux
appareils dialoguent, pas plus. PPP, en fait, ne connaît que deux entités
:
"moi" et "l'autre".
C'est parfaitement Ok dans le cas de liaison série (sur une prise COM1,
COM2, etc. , on ne relie qu'un seul appareil), une liaison PCI (il y a
autant de canaux PCI que de slots dans la machine, et sur un slot, on ne
peut mettre qu'une carte, pas plus), ou une liaison USB (chaque
périphérique
USB possède un identifiant, et le contrôleur USB ouvre un canal 'virtuel'
vers le modem pour chaque communication).
Ethernet, ce n'est pas du point à point. Pour chaque trame envoyée, il
faut
indiquer nominativement le destinataire... "Moi", "l'autre" : aucun sens
en
Ethernet. Mais on peut installer des protocoles qui, eux, savent ouvrir un
canal de dialogue à deux extrémités par-dessus un réseau (Ethernet ou
autre
!) : Ex: PPTP et PPPoE...
Ces deux zouaves "consomment" de la place, de façon imagée, ils sont des
"barges" dans lesquelles on installerait les "péniches".
Si la péniche fait pile poile la taille du canal, mettre la péniche dans
une
barge, et boum, l'ensemble ne passe plus dans le canal : obligé d'utiliser
des péniches plus petites !
Ce souci n'apparaît pas avec les routeurs : c'est le routeur qui s'occupe
de
l'authentification PPP, et ce qui sort de la prise Ethernet, c'est de
l'Internet "tout cuit". Les trames PPP n'empruntent pas la liaison
Ethernet,
qui est le canal étroit de l'ensemble, donc les péniches 1500 sont
possibles.
Avec les modems USB (pûr USB) ou PCI, carrément, on a de l'Ethernet nulle
part, on est pas limité à 1500 en théorie, on pourrait faire plus.
ou est-ce pour optimiser au max la connexion adsl ?
Oui, péniche de 1500 sur canal de 1500 = tiptop !
Uniquement s'il n'y a pas besoin de "barges" (ici : modem USB, pas de
problème), et si on est pas limité plus loin !
Il faut bien voir que le chemin entre l'abonné et le FAI est un parcours
d'obstacles, et que le MTU de l'ensemble égal le MTU de la zone la plus
rétrécie du parcours...
Pour un abonné non Wanadoo :
Abonné
|
| USB (Trames PPP, MTU implicite en IP(1500) over PPP(2) = 1502)
|
Modem USB
|
| ATM o ADSL (Trames IP o PPP o ATM o ADSL, aka "PPPoA")
| (Limite conventionnelle : 9180 (!!!) )
| (Les trames IPoPPP faisant 1502 passent "à l'aise")
|
DSLAM Opérateur ADSL
|
| ATM (Trames IP o PPP o ATM reconstituées)
| (depuis les signaux ADSL échangés)
| (Même limite conventionnelle que ci-dessus)
|
BAS Opérateur ADSL (France Télecom (et LDCOM?) )
|
| ??? (Trames IP o PPP o L2TP o ???)
| (Limite = ???)
|
EAS France Telecom, chez le FAI
|
| Ethernet (IP o PPP o L2TP o UDP/IP o Ethernet)
| (Limite : 1460 (hypothèse) ! )
|
LNS Fournisseur d'Accès Internet (Enfin !)
En abonné Wanadoo, il n'y a pas utilisation de tunnel L2TP, donc pas de
limite à 1460...
En décortiquant le protocole ATM, on s'apperçoit que ça commence par
ajouter
un en-tête , donc ça entre dans une "barge" (8 octets en PPPoA VCMUX) et
que
ça utilise des petits paquets de taille utile de 48 octets seulement (Les
barges sont découpées, chaque morceau transporté séparément, puis la barge
et le contenu sont re-soudés à l'arrivée !).
Mieux : ces petits paquets, ces cellules ATM, ont une taille fixe. Remplie
ou ne contenant qu'un seul octet, c'est 48 octets + 5 d'en-tête de cellule
qui partent !
Donc optimiser = faire en sorte que toutes les cellules soient pleines,
tout
le temps !
En PPPoA VCMUX, le nombre d'octets IP transportables pour x cellules vaut:
MTU optimisé = [x * 48 (taille utile d'une cellule)] - 2 (PPP) - 8
(ATM.CPCS)
Si l'on prends x = 32, on obtient MTU26 : trop gros pour PPP qui, par
défaut, utilise un maximum de 1500.
Si l'on prends x = 31, ça donne 1478 : Impec pour les abonnés Wanadoo,
mais
trop gros pour les autres avec le tunnel L2TP.
Si l'on prends x = 30, on obtient 1430. C'est ce que j'utilise comme
réglage, étant Club-Internet non dégroupé, avec routeur connecté en PPPoA
VCMUX.
type de mesure quantité minimum moyenne maximum
download 59 59,4 Ko/sec 61,8 Ko/sec 62,7 Ko/sec
upload 43 14,0 Ko/sec 16,1 Ko/sec 16,4
Ko/sec
http://www.grenouille.com/graph/index.php?zone 132
Attention, pour PPPoE, la formule est différente :
MTU Max = 1492 (à cause de la "barge" PPPoE)
MTU optimisé = [x * 48 ] - 40
x = 32, MTU = 1496 : Trop grand
x = 31, MTU = 1448 : Impec.
Ou se situe ce paramètre ? impossible de mettre la main dessus ???
"*RWIN = si tu utilises plus grand que 65535, pense à changer
vtcp.386 version 4.10.2222 buguée bridée à 65535 par 4.10.2223"
RWIN is the TCP Receive Window = DefaultRcvWindow dans le registre
Win98 = HKLMSystemCurrentControlSetServicesVxDMSTCP
N'existe pas si d'origine (défaut92), apparaît à la bidouille
(65535 pour la plupart des drivers ADSL), va jusqu'à 256960.
Cette valeur est bonne pour tous les usages, à ne modifier que pour
amusement par des gens avertis (REGISTRE CORROMPU = REINSTALL
COMPLETE !!!). Dépend de VTCP.386 dont la première version 4.10.2222
était buguée limitant à 65535 (ceci expliquant cela ?).
La 4.10.2223 monte semble-t-il à 256960.
Ou, pour éviter de faire des recherches un peu fastidieuses dans la base
de
registre, ce petit utilitaire sans installation est très bien :
http://www.dslreports.com/drtcp
RWIN est un entrepôt intermédiaire où on stocke le contenu de
plusieurs péniches avant de vérifier la marchandise et signer le reçu.
Si anomalie, on jette tout ce qui est dans l'entrepot et on fait
relivrer. Gros entrepôt = travail plus rapide.
Si erreur, gros entrepôt = travail moins rapide, il faut trouver le
bon compromis.
Les (re)livraisons étant beaucoup plus rapides en ADSL qu'en RTC donc
moins pénalisantes, on utilise de gros entrepôts:
RTC = Win98 = 8192
ADSL = driver ADSL = 65535
Heu... j'ai une autre version de l'histoire ...
RWIN est un entrepôt intermédiaire pour stocker des paquets qui
arriveraient
dans le désordre.
Imaginons que les péniches n° 1 2 3 et 4 arrivent dans cet ordre : 1 3 4
2.
La péniche 1 arrive, elle était attendue, le contenu est immédiatement
déchargé et envoyé au traitement, un accusé de réception est signé et
renvoyé à l'expéditeur. L'indicateur de débit se positionne sur le débit
normal (mettons : 64 ko/s)
La péniche 3 arrive... Mais on attendait la péniche 2 ! On décharge la
péniche 3 dans le dépot RWIN, au premier emplacement. Rien n'est envoyé au
traitement. Une photocopie de l'accusé de réception de la péniche 1 est à
nouveau envoyée, et si l'option TCP/IP "Selective Acknowledgement" est
active (cf DrTCP), un mot est indiqué en marge de l'accusé de réception
indiquant "Reçu le n° 3"). L'indicateur de débit baisse (32ko/s)...
La péniche 4 arrive... Toujours pas de péniche 2 en vue.... La péniche 4
est
déchargée dans RWIN, second emplacement, toujours rien vers le traitement.
Re-photocopie de l'accusé de réception de la péniche 1, et si option
"Selective ACKs", info crayonée : "Reçus n°3 et n°4"). L'indicateur de
débit
baisse encore (16ko/s)...
Finalement, la péniche 2 est arrivéééeee, sans s'presseeer (pardon...).
Elle
est immédiatement déchargée en envoyée au traitement, puis immédiatement,
les chargements RWIN emplacement 1 et 2 (ex- péniches 3 et 4) sont
envoyées
successivement au traitement, un accusé de réception pour la péniche 4 est
envoyée (implicitement, ça vaut quitus pour les péniches 2, 3 et 4), et
...
l'aiguille de débit fait temporairement un bond ! (144 ko/s, pour
rattraper
le retard).
Avoir un gros RWIN ne signifie pas que les accusés de réceptions seront
retardés, mais plutôt qu'en cas de liaison Internet aléatoire, moins de
paquets devront être re-émis s'ils ont pu être stockés dans l'entrepôt
RWIN.
Il fut un temps où un buffer de 16 ko était énorme, mais au jour
d'aujourd'hui, avec des machines de plusieurs centaines de Mo de RAM en
standard, qu'est ce que c'est, 64 ko, hein ?
Dans ce groupe, lire les contributions de Rémy MOULIN qui signe Herm.
[...]
Ouille, les chevilles ;-) :-P
--
Herm
Reclus wrote:
Raisonnement de SAGEM:
*1460 pour tout le monde = USB peu pénalisé, ethernet content.
*1500 pour tout le monde = USB content, ethernet catastrophique
(péniche 1500 ne passe plus = fragmentation).
La décision est vite prise !
Bonsoir,
La taille des canaux (jolie, l'analogie :-) ) en Ethernet est aussi de
1500.
Mais en effet, pour l'Ethernet, tout dépends si l'on utilise un modem
Ethernet ou un routeur Ethernet !
Les modems (Ethernet inclus) ne savent pas ouvrir la connexion
(identifiant
/ mot de passe de connexion) par eux-même. C'est l'ordinateur qui en a la
tâche, et ça se fait en "langue" (protocole) PPP.
Mais PPP ne sait transiter que sur des liaisons dites "points à points"
(PPP
= Point to Point Protocol), c'est à dire, des liaisons où seuls deux
appareils dialoguent, pas plus. PPP, en fait, ne connaît que deux entités
:
"moi" et "l'autre".
C'est parfaitement Ok dans le cas de liaison série (sur une prise COM1,
COM2, etc. , on ne relie qu'un seul appareil), une liaison PCI (il y a
autant de canaux PCI que de slots dans la machine, et sur un slot, on ne
peut mettre qu'une carte, pas plus), ou une liaison USB (chaque
périphérique
USB possède un identifiant, et le contrôleur USB ouvre un canal 'virtuel'
vers le modem pour chaque communication).
Ethernet, ce n'est pas du point à point. Pour chaque trame envoyée, il
faut
indiquer nominativement le destinataire... "Moi", "l'autre" : aucun sens
en
Ethernet. Mais on peut installer des protocoles qui, eux, savent ouvrir un
canal de dialogue à deux extrémités par-dessus un réseau (Ethernet ou
autre
!) : Ex: PPTP et PPPoE...
Ces deux zouaves "consomment" de la place, de façon imagée, ils sont des
"barges" dans lesquelles on installerait les "péniches".
Si la péniche fait pile poile la taille du canal, mettre la péniche dans
une
barge, et boum, l'ensemble ne passe plus dans le canal : obligé d'utiliser
des péniches plus petites !
Ce souci n'apparaît pas avec les routeurs : c'est le routeur qui s'occupe
de
l'authentification PPP, et ce qui sort de la prise Ethernet, c'est de
l'Internet "tout cuit". Les trames PPP n'empruntent pas la liaison
Ethernet,
qui est le canal étroit de l'ensemble, donc les péniches 1500 sont
possibles.
Avec les modems USB (pûr USB) ou PCI, carrément, on a de l'Ethernet nulle
part, on est pas limité à 1500 en théorie, on pourrait faire plus.ou est-ce pour optimiser au max la connexion adsl ?
Oui, péniche de 1500 sur canal de 1500 = tiptop !
Uniquement s'il n'y a pas besoin de "barges" (ici : modem USB, pas de
problème), et si on est pas limité plus loin !
Il faut bien voir que le chemin entre l'abonné et le FAI est un parcours
d'obstacles, et que le MTU de l'ensemble égal le MTU de la zone la plus
rétrécie du parcours...
Pour un abonné non Wanadoo :
Abonné
|
| USB (Trames PPP, MTU implicite en IP(1500) over PPP(2) = 1502)
|
Modem USB
|
| ATM o ADSL (Trames IP o PPP o ATM o ADSL, aka "PPPoA")
| (Limite conventionnelle : 9180 (!!!) )
| (Les trames IPoPPP faisant 1502 passent "à l'aise")
|
DSLAM Opérateur ADSL
|
| ATM (Trames IP o PPP o ATM reconstituées)
| (depuis les signaux ADSL échangés)
| (Même limite conventionnelle que ci-dessus)
|
BAS Opérateur ADSL (France Télecom (et LDCOM?) )
|
| ??? (Trames IP o PPP o L2TP o ???)
| (Limite = ???)
|
EAS France Telecom, chez le FAI
|
| Ethernet (IP o PPP o L2TP o UDP/IP o Ethernet)
| (Limite : 1460 (hypothèse) ! )
|
LNS Fournisseur d'Accès Internet (Enfin !)
En abonné Wanadoo, il n'y a pas utilisation de tunnel L2TP, donc pas de
limite à 1460...
En décortiquant le protocole ATM, on s'apperçoit que ça commence par
ajouter
un en-tête , donc ça entre dans une "barge" (8 octets en PPPoA VCMUX) et
que
ça utilise des petits paquets de taille utile de 48 octets seulement (Les
barges sont découpées, chaque morceau transporté séparément, puis la barge
et le contenu sont re-soudés à l'arrivée !).
Mieux : ces petits paquets, ces cellules ATM, ont une taille fixe. Remplie
ou ne contenant qu'un seul octet, c'est 48 octets + 5 d'en-tête de cellule
qui partent !
Donc optimiser = faire en sorte que toutes les cellules soient pleines,
tout
le temps !
En PPPoA VCMUX, le nombre d'octets IP transportables pour x cellules vaut:
MTU optimisé = [x * 48 (taille utile d'une cellule)] - 2 (PPP) - 8
(ATM.CPCS)
Si l'on prends x = 32, on obtient MTU26 : trop gros pour PPP qui, par
défaut, utilise un maximum de 1500.
Si l'on prends x = 31, ça donne 1478 : Impec pour les abonnés Wanadoo,
mais
trop gros pour les autres avec le tunnel L2TP.
Si l'on prends x = 30, on obtient 1430. C'est ce que j'utilise comme
réglage, étant Club-Internet non dégroupé, avec routeur connecté en PPPoA
VCMUX.
type de mesure quantité minimum moyenne maximum
download 59 59,4 Ko/sec 61,8 Ko/sec 62,7 Ko/sec
upload 43 14,0 Ko/sec 16,1 Ko/sec 16,4
Ko/sec
http://www.grenouille.com/graph/index.php?zone 132
Attention, pour PPPoE, la formule est différente :
MTU Max = 1492 (à cause de la "barge" PPPoE)
MTU optimisé = [x * 48 ] - 40
x = 32, MTU = 1496 : Trop grand
x = 31, MTU = 1448 : Impec.Ou se situe ce paramètre ? impossible de mettre la main dessus ???
"*RWIN = si tu utilises plus grand que 65535, pense à changer
vtcp.386 version 4.10.2222 buguée bridée à 65535 par 4.10.2223"
RWIN is the TCP Receive Window = DefaultRcvWindow dans le registre
Win98 = HKLMSystemCurrentControlSetServicesVxDMSTCP
N'existe pas si d'origine (défaut92), apparaît à la bidouille
(65535 pour la plupart des drivers ADSL), va jusqu'à 256960.
Cette valeur est bonne pour tous les usages, à ne modifier que pour
amusement par des gens avertis (REGISTRE CORROMPU = REINSTALL
COMPLETE !!!). Dépend de VTCP.386 dont la première version 4.10.2222
était buguée limitant à 65535 (ceci expliquant cela ?).
La 4.10.2223 monte semble-t-il à 256960.
Ou, pour éviter de faire des recherches un peu fastidieuses dans la base
de
registre, ce petit utilitaire sans installation est très bien :
http://www.dslreports.com/drtcpRWIN est un entrepôt intermédiaire où on stocke le contenu de
plusieurs péniches avant de vérifier la marchandise et signer le reçu.
Si anomalie, on jette tout ce qui est dans l'entrepot et on fait
relivrer. Gros entrepôt = travail plus rapide.
Si erreur, gros entrepôt = travail moins rapide, il faut trouver le
bon compromis.
Les (re)livraisons étant beaucoup plus rapides en ADSL qu'en RTC donc
moins pénalisantes, on utilise de gros entrepôts:
RTC = Win98 = 8192
ADSL = driver ADSL = 65535
Heu... j'ai une autre version de l'histoire ...
RWIN est un entrepôt intermédiaire pour stocker des paquets qui
arriveraient
dans le désordre.
Imaginons que les péniches n° 1 2 3 et 4 arrivent dans cet ordre : 1 3 4
2.
La péniche 1 arrive, elle était attendue, le contenu est immédiatement
déchargé et envoyé au traitement, un accusé de réception est signé et
renvoyé à l'expéditeur. L'indicateur de débit se positionne sur le débit
normal (mettons : 64 ko/s)
La péniche 3 arrive... Mais on attendait la péniche 2 ! On décharge la
péniche 3 dans le dépot RWIN, au premier emplacement. Rien n'est envoyé au
traitement. Une photocopie de l'accusé de réception de la péniche 1 est à
nouveau envoyée, et si l'option TCP/IP "Selective Acknowledgement" est
active (cf DrTCP), un mot est indiqué en marge de l'accusé de réception
indiquant "Reçu le n° 3"). L'indicateur de débit baisse (32ko/s)...
La péniche 4 arrive... Toujours pas de péniche 2 en vue.... La péniche 4
est
déchargée dans RWIN, second emplacement, toujours rien vers le traitement.
Re-photocopie de l'accusé de réception de la péniche 1, et si option
"Selective ACKs", info crayonée : "Reçus n°3 et n°4"). L'indicateur de
débit
baisse encore (16ko/s)...
Finalement, la péniche 2 est arrivéééeee, sans s'presseeer (pardon...).
Elle
est immédiatement déchargée en envoyée au traitement, puis immédiatement,
les chargements RWIN emplacement 1 et 2 (ex- péniches 3 et 4) sont
envoyées
successivement au traitement, un accusé de réception pour la péniche 4 est
envoyée (implicitement, ça vaut quitus pour les péniches 2, 3 et 4), et
...
l'aiguille de débit fait temporairement un bond ! (144 ko/s, pour
rattraper
le retard).
Avoir un gros RWIN ne signifie pas que les accusés de réceptions seront
retardés, mais plutôt qu'en cas de liaison Internet aléatoire, moins de
paquets devront être re-émis s'ils ont pu être stockés dans l'entrepôt
RWIN.
Il fut un temps où un buffer de 16 ko était énorme, mais au jour
d'aujourd'hui, avec des machines de plusieurs centaines de Mo de RAM en
standard, qu'est ce que c'est, 64 ko, hein ?Dans ce groupe, lire les contributions de Rémy MOULIN qui signe Herm.
[...]
Ouille, les chevilles ;-) :-P
--
Herm
Ben en tout cas j'ai installé tout le bazar que j'ai pu trouvé
Depuis, aucun problèmes a signaler !
(je touche du bois ...)
Ben en tout cas j'ai installé tout le bazar que j'ai pu trouvé
Depuis, aucun problèmes a signaler !
(je touche du bois ...)
Ben en tout cas j'ai installé tout le bazar que j'ai pu trouvé
Depuis, aucun problèmes a signaler !
(je touche du bois ...)
Auriez-vous la gentillesse, si votre emploi du temps l'autorise, de
nous faire un résumé succinct de la compression en ADSL.
Je n'ai trouvé d'information nulle part.
Il semble exister des systèmes propriétaires très contraignants...
Auriez-vous la gentillesse, si votre emploi du temps l'autorise, de
nous faire un résumé succinct de la compression en ADSL.
Je n'ai trouvé d'information nulle part.
Il semble exister des systèmes propriétaires très contraignants...
Auriez-vous la gentillesse, si votre emploi du temps l'autorise, de
nous faire un résumé succinct de la compression en ADSL.
Je n'ai trouvé d'information nulle part.
Il semble exister des systèmes propriétaires très contraignants...
L'info sur la structure du réseau ADSL de France Télécom est ici:
http://www.entreprises.francetelecom.com/publication/offre/fiche_collecteipa
(Cf. document pdf STAS CIPA vers la fin)
Il semblerait que l'architecture LDCOM en soit fortement inspirée.
Pour le protocole ATM, c'est la RFC2684, qui remplace la RFC1483, dispo
là:
http://www.faqs.org/rfcs/rfc2684.html
Pour IP sur ATM (Free), c'est la RFC 1577 CIP qui est sensée s'appliquer:
http://www.faqs.org/rfcs/rfc1577.html
Sauf que Free l'utilise en liaison avec l'encapsulation ATM VCMUX, alors
que
la RFC décrit LLC...
Le MTU pour IP sur ATM, et par extension, la taille dispo pour du xxx sur
ATM :
http://www.faqs.org/rfcs/rfc1626.html
Le protocole PPPoE, tunnel permettant une liaison point à point sur un
support quelconque :
http://www.faqs.org/rfcs/rfc2516.html
Le corollaire : PPPoA
http://www.faqs.org/rfcs/rfc2364.html
La description de l'option TCP/IP "Selective ACKnowledgments" :
http://www.faqs.org/rfcs/rfc2018.html
J'oubliais L2TP.
http://www.faqs.org/rfcs/rfc2661.html
Certains de ces documents ont été traduits en français, par exemple ici:
http://abcdrfc.free.fr/
Bonnes lectures :-D
--
Herm
L'info sur la structure du réseau ADSL de France Télécom est ici:
http://www.entreprises.francetelecom.com/publication/offre/fiche_collecteipa
(Cf. document pdf STAS CIPA vers la fin)
Il semblerait que l'architecture LDCOM en soit fortement inspirée.
Pour le protocole ATM, c'est la RFC2684, qui remplace la RFC1483, dispo
là:
http://www.faqs.org/rfcs/rfc2684.html
Pour IP sur ATM (Free), c'est la RFC 1577 CIP qui est sensée s'appliquer:
http://www.faqs.org/rfcs/rfc1577.html
Sauf que Free l'utilise en liaison avec l'encapsulation ATM VCMUX, alors
que
la RFC décrit LLC...
Le MTU pour IP sur ATM, et par extension, la taille dispo pour du xxx sur
ATM :
http://www.faqs.org/rfcs/rfc1626.html
Le protocole PPPoE, tunnel permettant une liaison point à point sur un
support quelconque :
http://www.faqs.org/rfcs/rfc2516.html
Le corollaire : PPPoA
http://www.faqs.org/rfcs/rfc2364.html
La description de l'option TCP/IP "Selective ACKnowledgments" :
http://www.faqs.org/rfcs/rfc2018.html
J'oubliais L2TP.
http://www.faqs.org/rfcs/rfc2661.html
Certains de ces documents ont été traduits en français, par exemple ici:
http://abcdrfc.free.fr/
Bonnes lectures :-D
--
Herm
L'info sur la structure du réseau ADSL de France Télécom est ici:
http://www.entreprises.francetelecom.com/publication/offre/fiche_collecteipa
(Cf. document pdf STAS CIPA vers la fin)
Il semblerait que l'architecture LDCOM en soit fortement inspirée.
Pour le protocole ATM, c'est la RFC2684, qui remplace la RFC1483, dispo
là:
http://www.faqs.org/rfcs/rfc2684.html
Pour IP sur ATM (Free), c'est la RFC 1577 CIP qui est sensée s'appliquer:
http://www.faqs.org/rfcs/rfc1577.html
Sauf que Free l'utilise en liaison avec l'encapsulation ATM VCMUX, alors
que
la RFC décrit LLC...
Le MTU pour IP sur ATM, et par extension, la taille dispo pour du xxx sur
ATM :
http://www.faqs.org/rfcs/rfc1626.html
Le protocole PPPoE, tunnel permettant une liaison point à point sur un
support quelconque :
http://www.faqs.org/rfcs/rfc2516.html
Le corollaire : PPPoA
http://www.faqs.org/rfcs/rfc2364.html
La description de l'option TCP/IP "Selective ACKnowledgments" :
http://www.faqs.org/rfcs/rfc2018.html
J'oubliais L2TP.
http://www.faqs.org/rfcs/rfc2661.html
Certains de ces documents ont été traduits en français, par exemple ici:
http://abcdrfc.free.fr/
Bonnes lectures :-D
--
Herm
