Auteur Sujet: Optimisation Pile TCP 2000 et XP  (Lu 14201 fois)

0 Membres et 2 Invités sur ce sujet

feyb64

  • SFR
  • *
  • Messages: 281
  • Souriez, vous êtes cliqué :)
    • Voir le profil
[tutoriel win] Optimisation Pile TCP 2000 et XP
« Réponse #15 le: 13 mai 2008 à 00:21:56 »
Le MTU de 1400 est celui utilisé pour Médiafibre.
Pour Citéfibre je ne sais pas.

Le seul et unique moyen de déterminer le MTU accepté par le réseau et à mettre dans le PC (ou tous autres équipements derrière le routeur, rgw ou pas) est de faire des 'pings' comme précisé dans le tuto :)

En d'autres termes, suivez le 'tuto' :)

Si jyce peut publier le MTU utilisé par Citéfibre (préciser aussi le débit de la ligne), je modifierai le tableau en conséquence pour ajouter une colonne 'Citéfibre'  ;)

Côté 'fragmentation', il est évident que si l'émetteur derrière le routeur utilise un MTU plus grand que celui supporté par la ligne 'logique' (en tenant compte de l'encapsulation éventuelle), il y aura fragmentation par le routeur, donc à la fois envoi de grands et petits paquets, ce qui est à éviter, puisque au final plus de paquets pour autant de data -> moins de bande passante 'utile'.

Exemple : Dans le cas d'un MTU 'logique' de ligne à 1400, et un pc configuré en 1500, il y aura pour chaque paquet émis par le pc (1500 + entête) deux paquets émis par le routeur (1400 + entête) + (100 + entête) . Donc perte en débit utile équivalent à un 'entête' (plus une encapsulation s'il y en a)
Sur une transmission 'courte' en temps, ce n'est pas un problème, mais sur une 'longue' cela en fait des octets en 'trop' sur la ligne pour rien ...
« Modifié: 13 mai 2008 à 00:43:12 par feyb64 »

vivien

  • Administrateur
  • *
  • Messages: 1 151
    • Voir le profil
    • La Fibre
[tutoriel win] Optimisation Pile TCP 2000 et XP
« Réponse #16 le: 13 mai 2008 à 08:10:04 »
Le MTU de 1400 est celui utilisé pour Médiafibre.
Pour Citéfibre je ne sais pas.


La seulle chose qui pourrais faire que la MTU soit différente entre citéFibre et MediaFibre c'est l'équipement de filtrage du P2P qui citéFibre n'a pas acheté.

Pour moi la différence entre la MTU de feyb64 (1400) et la MTU de jyce (jyce) vient du fait que jyce a remplacé sa Sagem F@st 3190 par un routeur Cisco. feyb64, en suivant le tuto de TTS pour te connecter sans RGW tu arrive a quel MTU ?

jyce

  • Free
  • *
  • Messages: 8
    • Voir le profil
    • JBC explorer (Explorer de fichiers PHP)
[tutoriel win] Optimisation Pile TCP 2000 et XP
« Réponse #17 le: 13 mai 2008 à 09:43:07 »
Donc si j'étais un ouf du tunning, il faudrait que je réduise le MTU de tous mes PC a 1492 pour éviter à mon routeur une fragmentation des paquets lors de l'encapsulation pppoe.
Bof, pas le courage de le faire  ;D

Pour ma conf, un MTU supérieur provoque la perte de toutes les connexions :

interface Dialer0
 ip address negotiated
 ip access-group inboundfilter in
 ip access-group outboundfilter out
 ip verify unicast reverse-path
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip mtu 1492
 ip nat outside
 ip inspect firewall in
 ip inspect firewall out
 ip virtual-reassembly
 encapsulation ppp
 ip tcp adjust-mss 1452
 dialer pool 1
 no cdp enable
 ppp authentication chap callin
 ppp chap hostname login@citefibre.fr
 ppp chap password 7 112345678901234
 ppp ipcp dns request
!

feyb64

  • SFR
  • *
  • Messages: 281
  • Souriez, vous êtes cliqué :)
    • Voir le profil
[tutoriel win] Optimisation Pile TCP 2000 et XP
« Réponse #18 le: 14 mai 2008 à 00:04:42 »
La seulle chose qui pourrais faire que la MTU soit différente entre citéFibre et MediaFibre c'est l'équipement de filtrage du P2P qui citéFibre n'a pas acheté.

Pour moi la différence entre la MTU de feyb64 (1400) et la MTU de jyce (jyce) vient du fait que jyce a remplacé sa Sagem F@st 3190 par un routeur Cisco. feyb64, en suivant le tuto de TTS pour te connecter sans RGW tu arrive a quel MTU ?


L'équipement de filtrage n'a rien à voir avec la 'réduction' du MTU, car aujourd'hui il ne semble plus 'actif' (je télécharge aujourd'hui à 2.5Mo/s alors qu'avec le 'filtreur', chaque session tcp étant bridée à 1Mo/s) et si je fais le test 'ping' pour déterminer le MTU, au delà de 1400 ça bloque.

Probablement donc des paramètres différents au niveau des configs balancées aux rgw suivant les réseaux (MédiaFibre en général 1400, Citéfibre 1492).
La question 'aurait été' (car c'est presque du passé, tout au moins au 30 juin) pourquoi un MTU si petit ...

Pour le test 'sans rgw', j'avoue ne plus m'en rappeler.


« Modifié: 14 mai 2008 à 00:12:41 par feyb64 »

vivien

  • Administrateur
  • *
  • Messages: 1 151
    • Voir le profil
    • La Fibre
[tutoriel win] Optimisation Pile TCP 2000 et XP
« Réponse #19 le: 14 mai 2008 à 19:52:23 »
Paramètres différents : je n'y crois pas vu que médiafibre et citéFibre partage plusieurs équipements au moins en back-up (les abonnés citéFibre vont en priorité sur des équipements parisiens mais le back-up est sur Pau et inversement pour les abonnés MediaFibre).

La principale différence c'est le N° de tel (01 pour paris, 05 pour Pau) mais il y avait des erreur et des abonnés citéFibre se retrouvaient avec des N° en 05, cela m'amusait à chaque fois que cela se produisait.

Un équipement de filtrage du P2P on peut le configurer pour mettre a X kb/ s les flux P2P ou lui dire on paye un transit de 1 Gb/s, fait en sorte de réduire le P2P de façon a ne pas dépasser. La nuit  le P2P n'est pas bridé et en heure de pointe le trafic est fortement bridé. Si c'est solution qui est retenue, comme médiaFibre pert des abonnés, c'est normal que le P2P ne soit plus bridé car on est en dessous de 1 Gb/s (1 Gb/s c'est un exemple, je ne connais pas le BP des abonnés médiaFibre)

Je persiste à accuser principalement la RGW, qui aurait ce paramètre dans son firmware (le même pour Pau et citéFibre).


- DHCP avec MTU 1500 octets (MSS: 1460) => Pour un paquet rempli de taille standard de 1460 octets, le modem envoi un paquet de 1500 octets.

- PPP avec une MTU 1492 octets (MSS: 1452) => Pour un paquet rempli de taille standard de 1460 octets, le modem envoi 2 paquets :
1) 1452 de data + 40 d'entête + 8 pour PPP = 1500
2) 8 de data + 40 d'entete + 8 pour PPP = 56
Total : 1556 octets envoyés contre 1500 octets en DHCP.

=> sans optimisation du PC le PPP fait baisser le débit de 3,73%

epsilon

  • Orange
  • *
  • Messages: 6
    • Voir le profil
Re : [tutoriel win] Optimisation Pile TCP 2000 et XP
« Réponse #20 le: 25 novembre 2008 à 18:46:08 »
Bonjour,

Nouvel inscrit ici et fibronaute depuis quatre mois à Paris chez Orange, je souhaite apporter à ce thread mon retour d'expériences concernant l'optimisation TCP sur une machine XP.

Pour tuner les performances et la connectivité de ma machine XP j'ai ajouté/modifié dans ma base de registre plusieurs paramétres :

- activé le window scaling and timestamping
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts=3

- paramétré le TCP receive window size
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize=256000

- paramétré au maximum le TCP send/receive window sizes
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\GlobalMaxTcpWindowSize=16777216

Ensuite j'ai passé en revue d'autres paramètres TCP/IP, NBT, ...

Quelques urls :
- Paramètres de configuration NBT et TCP/IP pour Windows XP : http://support.microsoft.com/kb/314053/fr
- Optimiser votre registre XP : http://www.speedguide.net/read_articles.php?id=157

Une fois vérifié tous ces réglages sur votre OS, il est temps de tester votre bande passante.
En dehors des outils (Iperf, Pchar, ...) qui mesurent la taille des liens et qui ne sont pas à la portée de tout le monde, je vous recommande d'effectuer votre test ici :
http://www.numion.com/  (cliquez sur Measure your speed puis Quickstart)


Bon surf  8)

vivien

  • Administrateur
  • *
  • Messages: 1 151
    • Voir le profil
    • La Fibre
Re : Re : [tutoriel win] Optimisation Pile TCP 2000 et XP
« Réponse #21 le: 25 novembre 2008 à 21:29:54 »
Bonjour et bienvenue ici !
curiosité : tu à pris l'option 100 Mb/s en upload ?

Pour tuner les performances et la connectivité de ma machine XP j'ai ajouté/modifié dans ma base de registre plusieurs paramétres :

- activé le window scaling and timestamping
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts=3


Il me semble que la valeur est déja à 3 par default :

Valeur   Signification
0le timestamps et le window scaling sont désactivés
1le timestamps est désactivé et le window scaling est activé
2le timestamps est activé et le window scaling est désactivé
3le timestamps et window scaling sont activés

Explication pour savoir de quoi on parle :

Timestamps est une option TCP (définit dans IETF RFC 1323) qui rajoute une information de numérotation aux paquets TCP. L'option Timestamps fourni deux champ timestamp de 4 octets chacun (valeurs comprise entre 0 et 4294967295) dans l'entête TCP : TSval pour enregistrer le n° de la transmission initiale et TSecr pour enregistrer le n° sur de l'ordinateur distant. La valeur de TSval est recopiée dans TSecr, lors de la réponse. [à reformuler]

Cette information à 2 usages :
  • RTTM (Round Trip Time Measurement) : Elle aide TCP à mesurer le RTT (round trip time ou temps d'aller retour) pour ajuster les timeouts au-delà duquel un paquet TCP est considéré comme perdu et retransmis.
  • PAWS (Protect Against Wrapped Sequences) : Chaque paquet est numéroté et si il est perdu, il de mande le renvoi de tous les paquets a partir du n° x (ou ne demande de renvoyer que le n° x si l'option SACK est activé). Le N° est codé sur 32bits donc 4294967296 possibilités. Le N° reviens donc a 0 tous les 4294967296 paquets. Avec des grandes Rwin, il y a risque d'avoir le même N° de paquet 2 fois. En cas d'erreur, il ne sauras donc pas quel paquet renvoyer. Les timestamps sont la pour résoudre ce problème. Ils sont donc indispensable pour les grandes Rwin, donc pour les connexions FTTH et satellites.



La fenêtre de réception TCP (TCP receive window ou Rwin) correspond à la quantité maximale de "Paquets IP" pouvant être envoyées par l'émetteur sans avoir à attendre une confirmation de bonne réception de la part du destinataire. Ce "Rwin" est exprimé en nombre d'octets et pas en nombre de paquets. Le destinataire allouera cette quantité en mémoire (emplacement que l'on appel généralement "tampon" ou "buffer") pour pouvoir y placer les données reçus. Si la Rwin est positionné à 0, l'émetteur attend systématiquement l'accusé de réception avant d'envoyer le paquet suivant.

Window scaling est une option TCP (définit dans IETF RFC 1323) qui permet à une connexion TCP de négocier un "scaling factor" ou "Windows scale" pour multiplier les 2 octets de Rwin. Si le window scaling est désactivé, le coefficient multiplicateur est de 1, donc la valeur de la Rwin est celle indiqué par les 2 octets soit de 0 à 65535 octets. Si les 2 octets sont 2000 et que le Windows scale est de 64, la fenêtre de réception TCP (Rwin) est de 2000 x 64 = 128 Ko. Le windows scaling permet de re-pousser la barrière d'une Rwin maximum de 64 Ko à une Rwin maximum de 1 Go.



Je propose que vous fassiez vos remarques sur ces définitions, je rajouter à Wikipedia ce qui font consensus car il est assez pauvre sur ces termes technique. Feyb64, j'ai des doute sur la partie PAWS (Protect Against Wrapped Sequences) si tu peut être doublement attentif sur cette partie.

epsilon

  • Orange
  • *
  • Messages: 6
    • Voir le profil
Re : Re : Re : [tutoriel win] Optimisation Pile TCP 2000 et XP
« Réponse #22 le: 26 novembre 2008 à 10:53:41 »
Bonjour et bienvenue ici !
curiosité : tu à pris l'option 100 Mb/s en upload ?

Bonjour,

Je viens d'y souscrire et devrais en bénéficier d'ici quelques jours.

N.B.
Pour Vista les paramètres à activer et modifier :
- activer le TCP receive window size jusqu'à 16MB maximum
- activer l'auto tunning via l'interface netsh
Cliquer sur Démarrer/Exécuter/cmd
et saisir :
netsh interface tcp set global autotunninglevel=disabled  puis faire entrée
netsh interface tcp set global autotunninglevel=normal  puis faire entrée

feyb64

  • SFR
  • *
  • Messages: 281
  • Souriez, vous êtes cliqué :)
    • Voir le profil
Re : Re : [tutoriel win] Optimisation Pile TCP 2000 et XP
« Réponse #23 le: 07 décembre 2008 à 01:26:54 »
Bonjour,

Nouvel inscrit ici et fibronaute depuis quatre mois à Paris chez Orange, je souhaite apporter à ce thread mon retour d'expériences concernant l'optimisation TCP sur une machine XP.

Pour tuner les performances et la connectivité de ma machine XP j'ai ajouté/modifié dans ma base de registre plusieurs paramétres :


Bienvenue :)

Citation
- activé le window scaling and timestamping
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts=3


Pourquoi pas

Citation
- paramétré le TCP receive window size
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize=256000


Ce paramètre 'TcpWindowsSize' placé ici ne sert strictement à rien :)
car ce paramètre est destiné à spécifier un 'TcpWindowsSize' pour une carte réseau donnée pour remplacer explicitement pour cette carte le paramètre "GlobalMaxTcpWindowSize" qui est lui la valeur par défaut pour toutes les cartes
Le paramètre 'TcpWindowsSize' n'est lu que s'il est ici :
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\interface-name

Citation
- paramétré au maximum le TCP send/receive window sizes
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\GlobalMaxTcpWindowSize=16777216


Ouaouw ! 16Mb la fenêtre ! quel est donc le calcul qui a sorti ce chiffre ?
En 100Mb/s cela correspondrait grosso-modo à une latence de ligne de près de 800ms !

Citation
Ensuite j'ai passé en revue d'autres paramètres TCP/IP, NBT, ...


Tu peux préciser lesquels ?

Citation
Quelques urls :
- Paramètres de configuration NBT et TCP/IP pour Windows XP : http://support.microsoft.com/kb/314053/fr
- Optimiser votre registre XP : http://www.speedguide.net/read_articles.php?id=157


Tu peux préciser lesquels tu as utilisé/modifié ?

Citation
Une fois vérifié tous ces réglages sur votre OS, il est temps de tester votre bande passante.
En dehors des outils (Iperf, Pchar, ...) qui mesurent la taille des liens et qui ne sont pas à la portée de tout le monde, je vous recommande d'effectuer votre test ici :
http://www.numion.com/  (cliquez sur Measure your speed puis Quickstart)


Bon surf  8)


Effectivement numion est probablement un des rares actuellement à vraiment bien fonctionner avec du très haut débit (surtout en upload)

feyb64

  • SFR
  • *
  • Messages: 281
  • Souriez, vous êtes cliqué :)
    • Voir le profil
Re : Re : Re : [tutoriel win] Optimisation Pile TCP 2000 et XP
« Réponse #24 le: 07 décembre 2008 à 01:35:40 »
...
Il me semble que la valeur est déja à 3 par default :

Valeur   Signification
0le timestamps et le window scaling sont désactivés
1le timestamps est désactivé et le window scaling est activé
2le timestamps est activé et le window scaling est désactivé
3le timestamps et window scaling sont activés



Non, la valeur par défaut est 0, qui est plus que 'désactivé' en fait, plus précisement 0 c'est : on ne demande pas à faire ni l'un ni l'autre, mais on accepte que l'autre le fasse (on lui renvoi donc ce dont il a besoin pour le faire)

Citation
Explication pour savoir de quoi on parle :

Timestamps est une option TCP (définit dans IETF RFC 1323) qui rajoute une information de numérotation aux paquets TCP. L'option Timestamps fourni deux champ timestamp de 4 octets chacun (valeurs comprise entre 0 et 4294967295) dans l'entête TCP : TSval pour enregistrer le n° de la transmission initiale et TSecr pour enregistrer le n° sur de l'ordinateur distant. La valeur de TSval est recopiée dans TSecr, lors de la réponse. [à reformuler]

Cette information à 2 usages :
  • RTTM (Round Trip Time Measurement) : Elle aide TCP à mesurer le RTT (round trip time ou temps d'aller retour) pour ajuster les timeouts au-delà duquel un paquet TCP est considéré comme perdu et retransmis.
  • PAWS (Protect Against Wrapped Sequences) : Chaque paquet est numéroté et si il est perdu, il de mande le renvoi de tous les paquets a partir du n° x (ou ne demande de renvoyer que le n° x si l'option SACK est activé). Le N° est codé sur 32bits donc 4294967296 possibilités. Le N° reviens donc a 0 tous les 4294967296 paquets. Avec des grandes Rwin, il y a risque d'avoir le même N° de paquet 2 fois. En cas d'erreur, il ne sauras donc pas quel paquet renvoyer. Les timestamps sont la pour résoudre ce problème. Ils sont donc indispensable pour les grandes Rwin, donc pour les connexions FTTH et satellites.



La fenêtre de réception TCP (TCP receive window ou Rwin) correspond à la quantité maximale de "Paquets IP" pouvant être envoyées par l'émetteur sans avoir à attendre une confirmation de bonne réception de la part du destinataire. Ce "Rwin" est exprimé en nombre d'octets et pas en nombre de paquets. Le destinataire allouera cette quantité en mémoire (emplacement que l'on appel généralement "tampon" ou "buffer") pour pouvoir y placer les données reçus. Si la Rwin est positionné à 0, l'émetteur attend systématiquement l'accusé de réception avant d'envoyer le paquet suivant.

Window scaling est une option TCP (définit dans IETF RFC 1323) qui permet à une connexion TCP de négocier un "scaling factor" ou "Windows scale" pour multiplier les 2 octets de Rwin. Si le window scaling est désactivé, le coefficient multiplicateur est de 1, donc la valeur de la Rwin est celle indiqué par les 2 octets soit de 0 à 65535 octets. Si les 2 octets sont 2000 et que le Windows scale est de 64, la fenêtre de réception TCP (Rwin) est de 2000 x 64 = 128 Ko. Le windows scaling permet de re-pousser la barrière d'une Rwin maximum de 64 Ko à une Rwin maximum de 1 Go.



Je propose que vous fassiez vos remarques sur ces définitions, je rajouter à Wikipedia ce qui font consensus car il est assez pauvre sur ces termes technique. Feyb64, j'ai des doute sur la partie PAWS (Protect Against Wrapped Sequences) si tu peut être doublement attentif sur cette partie.


Je jeterai un oeil  ;)

epsilon

  • Orange
  • *
  • Messages: 6
    • Voir le profil
Re : Re : Re : [tutoriel win] Optimisation Pile TCP 2000 et XP
« Réponse #25 le: 08 décembre 2008 à 19:00:35 »
Bienvenue :)

Pourquoi pas

Ce paramètre 'TcpWindowsSize' placé ici ne sert strictement à rien :)
car ce paramètre est destiné à spécifier un 'TcpWindowsSize' pour une carte réseau donnée pour remplacer explicitement pour cette carte le paramètre "GlobalMaxTcpWindowSize" qui est lui la valeur par défaut pour toutes les cartes
Le paramètre 'TcpWindowsSize' n'est lu que s'il est ici :
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\interface-name

Ouaouw ! 16Mb la fenêtre ! quel est donc le calcul qui a sorti ce chiffre ?
En 100Mb/s cela correspondrait grosso-modo à une latence de ligne de près de 800ms !

Tu peux préciser lesquels ?

Tu peux préciser lesquels tu as utilisé/modifié ?

Effectivement numion est probablement un des rares actuellement à vraiment bien fonctionner avec du très haut débit (surtout en upload)



Salut Feb64 et merci pour la bienvenue! ;)


Tcp1323Opts est un paramètre très important car il permet de contrôler les options de dimensionnement des fenêtres (window scaling) et d’horodatage (timestamping) (cf RFC 1323). Sans ce paramètre le dimensionnement est limité à 64K, soit on active/désactive les valeurs "GlobalMaxTcpWindowSize" ou "TcpWindowsSize".
Avec une valeur DWORD = 0 (désactiver les options et la valeur RWIN par défaut à moins de 64ko)
Avec une valeur DWORD = 1 (seule l’option de dimensionnement des fenêtres est activée)
Avec une valeur DWORD = 2 (seule l’option d’horodatage est activée)
Avec une valeur DWORD = 3 (les deux options sont activées)


A propos de TcpWindowsSize, je t’invite à lire cette page :
http://www-didc.lbl.gov/TCP-tuning/Windows.html
puis de lire les liens renvoyant vers d’autres sites dont ceux de MS (très instructifs).
enfin utilises DrTCP à dl ici : http://www.dslreports.com/drtcp ... et regardes les nouvelles valeurs dans ta BDR.


Pour le maximum TCP buffer size, on peut négocier la taille maximale des segments TCP jusqu’à 16MB (maximum TCP buffer size)
Pour tout savoir :
http://www.onlamp.com/pub/a/onlamp/2005/11/17/tcp_tuning.html?page=1
http://www.onlamp.com/pub/a/onlamp/2005/11/17/tcp_tuning.html?page=2
http://dsd.lbl.gov/TCP-tuning/background.html
http://shlang.com/writing/tcp-perf.html


Je vais te lister tous mes paramètres de BDR.


feyb64

  • SFR
  • *
  • Messages: 281
  • Souriez, vous êtes cliqué :)
    • Voir le profil
Re : [tutoriel win] Optimisation Pile TCP 2000 et XP
« Réponse #26 le: 10 décembre 2008 à 22:28:03 »
Concernant l'endroit du TCPWindowsSize nous avons en fait raison tous les deux  ;)
J'ai omis XP et spécifié les paramètres 'Windows 2000' (lui ne reconnais pas TCPWindowSize au niveau Parameters mais GlobalMaxTcpWindowSize) en oubliant que effectivement sous XP c'est TCPWindowSize dans les deux cas (lui ne lit pas du tou GlobalMaxTcpWindowSize)

PS : Concernant les 'sites divers et variés que tu as cité, qu'ils soient bon ou pas n'est pas la question, je vais toujours à la source de toute façon :)

Pour ce qui est de la valeur du TCPWindowsSize, qu'elle puisse valoir 16MB ou 150243324463 GB ne veut pas dire que c'est forcement ça qu'il faut.
Ce n'est pas parce que ta porche peut aller à 310Km/h que tu pourras effectivement y arriver si de toutes façons, quelques soient les routes elles ne te permettent pas d'aller plus que 250Km/h (prenons exemple de la Corse, peu d'endroits ou aller plus vite en fait là bas)
Pareil sur le Net.
En mettant d'office la valeur max sur le net, que ce passe t'il ?
Et bien en fait, pendant une période plus ou moins longue, il va y avoir 'recherche' à concurrence de ton 'max' de la 'bonne' taille à adopter. La rapidité de convergeance dépend aussi de la prise en charge des fameux RFC1323 ou pas par la destination (qui ne sont pas forcement validés partout par défaut sur tous les os ou par la suite sur les installations) tu va avoir de très mauvais débits sur les 'petits' et 'moyens' downloads (en terme 'temps' et 'taille'). Seuls les longs download sans 'accros' (aucun pb de perte de paquet dû à autre chose car alors on recommence à zéro la négo) beneficieraient de cette 'fenêtre' pour être 'au taquet'.

Concernant la 'valeur' à utiliser, je ne défend rien, ce n'est pas moi qui les ai inventé ces 'formules' et 'méthodes', c'est entre autres les types qui ont pondu IP et toute la clique TCP qui va avec ainsi que les 'RFC' qui les décrivent dont la '1323'.
D'ailleurs à quoi peut bien servir la 1323 et ce paramètre 'TcpWindowSize' si de toute façon 'le max est toujours le mieux' ?

Il y a 'a priori' pas à tergiverser, si il existe des 'méthodes et formules mathématiques' permettant de déterminer le 'meilleur' paramètre de 'fenêtre' TCP, c'est pas pour rien :)
Ou bien sous entends tu que c'est du n'importe quoi ? Si tu penses avoir raison, reste à me convaincre que 16MB (ou le max possible pour cette valeur) c'est 'forcement' ce qu'il faut ;)

PS : a moins que le réseau Fibre FT soit de la 'merde' totale, seul moyen d'expliquer qu'il te faudrait 16MB de 'windows' pour être au taquet  ;D

feyb64

  • SFR
  • *
  • Messages: 281
  • Souriez, vous êtes cliqué :)
    • Voir le profil
Re : [tutoriel win] Optimisation Pile TCP 2000 et XP
« Réponse #27 le: 10 décembre 2008 à 22:46:22 »
Au fait, j'oubliai  ::)

Dans AUCUN des articles que tu cites je ne vois qu'il faut mettre 16MB  :-\
Où donc as tu trouvé cette valeur ?

Concernant DRTcp, c'est un outil pour montrer/modifier les valeurs en question, mais ce n'est pas lui que dit quoi mettre  ;)

feyb64

  • SFR
  • *
  • Messages: 281
  • Souriez, vous êtes cliqué :)
    • Voir le profil
Re : Re : [tutoriel win] Optimisation Pile TCP 2000 et XP
« Réponse #28 le: 10 décembre 2008 à 22:51:10 »
...
PS : a moins que le réseau Fibre FT soit de la 'merde' totale, seul moyen d'expliquer qu'il te faudrait 16MB de 'windows' pour être au taquet  ;D


Bien entendu, je ne pense pas que FT soit tombé aussi bas, loin de là heureusement  ;D
Hein, pas d'aciditées envers moi Mesdames, Messieurs de l'Orange, Ok  ;)

epsilon

  • Orange
  • *
  • Messages: 6
    • Voir le profil
Re : Re : [tutoriel win] Optimisation Pile TCP 2000 et XP
« Réponse #29 le: 12 décembre 2008 à 14:32:10 »
Salut feb64,

Concernant l'endroit du TCPWindowsSize nous avons en fait raison tous les deux  ;)

lol


Citation de: feyb64
J'ai omis XP et spécifié les paramètres 'Windows 2000' (lui ne reconnais pas TCPWindowSize au niveau Parameters mais GlobalMaxTcpWindowSize) en oubliant que effectivement sous XP c'est TCPWindowSize dans les deux cas (lui ne lit pas du tou GlobalMaxTcpWindowSize)

Sous XP il faut ajouter dans sa base de registre les valeurs TCPWindowSize et GlobalMaxTcpWindowSize aux clés suivantes :
- HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
- HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\interface-name (interface-name = la carte réseau, pour l'identifier on voit son IP, son serveur DHCP, etc...)


Citation de: feyb64
PS : Concernant les 'sites divers et variés que tu as cité, qu'ils soient bon ou pas n'est pas la question, je vais toujours à la source de toute façon :)

Idem  ;)


Citation de: feyb64
Pour ce qui est de la valeur du TCPWindowsSize, qu'elle puisse valoir 16MB ou 150243324463 GB ne veut pas dire que c'est forcement ça qu'il faut.

Il ne faut surtout pas indiquer 16777216 comme valeur DWORD (en décimale) pour TCPWindowsSize mais sa RWIN si on est en mesure de la calculer.

Cette valeur de 16777216 est à indiquer pour GlobalMaxTcpWindowSize et permet d'augmenter les tampons d'envoi et de réception TCP qui permettent aux applications de déplacer leur données plus rapidement et d'exécuter ainsi les autres requêtes.

Je précise un point très important : si l'on désire tuner sa machine sous XP en indiquant sa MTU et RWIN il faut ajouter absolument les paramètres suivants dans sa BDR :

Dans les clés suivantes :
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\

et l'on ajoute les valeurs DWORD suivantes :
- GlobalMaxTcpWindowSize, de 65535 à 16777216
- TcpWindowSize, indiquer sa RWIN (qui doit être absolument un multiple de MSS)
- Tcp1323Opts, contrôle les options de dimensionnement des fenêtres et d’horodatage (window scalling & timestampin), donc active/désactive les valeurs GlobalMaxTcpWindowSize ou TcpWindowsSize.
- SackOpts, cette fonction améliore les performances de connexion quand on utilise des grandes tailles de fenêtres RWIN.
- TcpMaxDupAcks, détermine le nombre d’ACK (Accusé de Réception)
- EnablePMTUBHDetect, détecte des routeurs de type "trou noir" (black hole)
- EnableDeadGWDetect ou DeadGWDetectDefault, détecte les passerelles inactives et permet de passer sur des passerelles de réserve
- DefaultTTL, permet d'augmenter le nombre de routeur pour trouver un site donné
- EnablePMTUDiscovery, détecte la MTU

cf à la fin de mon post mes paramètres dans ma BDR

 
Citation de: feyb64
Ce n'est pas parce que ta porche peut aller à 310Km/h que tu pourras effectivement y arriver si de toutes façons, quelques soient les routes elles ne te permettent pas d'aller plus que 250Km/h (prenons exemple de la Corse, peu d'endroits ou aller plus vite en fait là bas)
Pareil sur le Net.
En mettant d'office la valeur max sur le net, que ce passe t'il ?
Et bien en fait, pendant une période plus ou moins longue, il va y avoir 'recherche' à concurrence de ton 'max' de la 'bonne' taille à adopter. La rapidité de convergeance dépend aussi de la prise en charge des fameux RFC1323 ou pas par la destination (qui ne sont pas forcement validés partout par défaut sur tous les os ou par la suite sur les installations) tu va avoir de très mauvais débits sur les 'petits' et 'moyens' downloads (en terme 'temps' et 'taille'). Seuls les longs download sans 'accros' (aucun pb de perte de paquet dû à autre chose car alors on recommence à zéro la négo) beneficieraient de cette 'fenêtre' pour être 'au taquet'.

Concernant la 'valeur' à utiliser, je ne défend rien, ce n'est pas moi qui les ai inventé ces 'formules' et 'méthodes', c'est entre autres les types qui ont pondu IP et toute la clique TCP qui va avec ainsi que les 'RFC' qui les décrivent dont la '1323'.
D'ailleurs à quoi peut bien servir la 1323 et ce paramètre 'TcpWindowSize' si de toute façon 'le max est toujours le mieux' ?

Le max ici est représenté par la valeur GlobalMaxTcpWindowSize et non TcpWindowSize.
A l'usage, c'est ta MTU, ta RWIN qui amélioreront les performances réseaux de la machine. Mais pour bien fonctionner il faut fixer des limites.


Citation de: feyb64
Il y a 'a priori' pas à tergiverser, si il existe des 'méthodes et formules mathématiques' permettant de déterminer le 'meilleur' paramètre de 'fenêtre' TCP, c'est pas pour rien :)
Ou bien sous entends tu que c'est du n'importe quoi ? Si tu penses avoir raison, reste à me convaincre que 16MB (ou le max possible pour cette valeur) c'est 'forcement' ce qu'il faut ;)

Je n'ai pas du tout exprimé cela :o
J'espère que c'est plus clair pour toi à présent.  ;)


Citation de: feyb64
PS : a moins que le réseau Fibre FT soit de la 'merde' totale, seul moyen d'expliquer qu'il te faudrait 16MB de 'windows' pour être au taquet  ;D
Franchement la Fibre par Orange ça fonctionne très bien. Je suis en symétrique en plus depuis peu et c'est vraiment impressionnant après optimisation.

Tu me le demandais précédemment voici mes paramètres dans ma BDR ss XP :
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"IPEnableRouter"=dword:00000000
"PerformRouterDiscovery"=dword:00000000
"TCPMaxHalfOpenRetired"=dword:00000400
"ForwardBroadcasts"=dword:00000000
"NoDefaultExempt"=dword:00000001
"NoNameReleaseOnDemand"=dword:00000001
"EnableFragmentChecking"=dword:00000001
"DefaultMSS"=dword:000005a0
"UseDomainNameDevolution"=dword:00000001
"EnableICMPRedirect"=dword:00000001
"DontAddDefaultGatewayDefault"=dword:00000000
"EnableSecurityFilters"=dword:00000001
"GlobalMaxTcpWindowSize"=dword:01000000
"Tcp1323Opts"=dword:00000003
"KeepAliveTime"=dword:000493e0
"DisableIPSourceRouting"=dword:00000002
"EnableDeadGWDetect"=dword:00000000
"EnablePMTUDiscovery"=dword:00000001
"EnablePMTUBHDetect"=dword:00000000
"SynAttackProtect"=dword:00000002
"SackOpts"=dword:00000001
"TcpMaxHalfOpen"=dword:00000500
"MTU"=dword:0000055c
"TcpWindowSize"=dword:0007f800
"TcpMaxDupAcks"=dword:00000002
"DefaultTTL"=dword:000000ff