Reprise du message précédent :

 
Ou as tu vu que c'est dit une synchro inférieur, j'ai parlé du débit IP qui est inférieur a celui du Debit ATM (valeur donnée par le modem)?
Modem connecté = synchro (donc ATM)
Débite = Débit IP (donc IP)

 
je ne vois nulle part mentionné de "débit IP inférieur"  dans cette phrase
 
>Si ton Modem est connecté à 8 Mb, il débite 8Mb (enfin moins vu que c'est de l'ATM)
 
t'as voulu chercher l'embrouille

Ben vi mais c'est pas marqué Débit ATM non plus
mdr

bon, a la lecture de vos remarque, j'ai mlancé en http sur clubic le telechargement d'une ubuntu...j'etais a 250ko/s a peu pres...
 
J'ai choisi ensuite les "optimal settings" de tcp optimizer...rebooté l'ordi, et sur le meme dl je suis maintenant a 800ko/s
 
Pour info : 1214m du NRA, 14db d'affaiblissement, 576m en 4/10 et le reste en 6/10  
 
Merci pour ce ptiot soft

edit:voilà du post collector pour kobaia    
j'arrete de discuter avec toi pour 2 raisons:
1-tu ne discutes que pour casser.
2-tu ne comprends pas ou ne veux pas comprendre.

edit2:
voilà ce qu'on peut trouver un peu n'importe où...

en voilà une methode pour determiner son debit?!
explique moi comment tu peux modifier/augmenter ton debit en modifiant ta base de registre?

oui m'enfin bon en adsl2 + je pourrais tout de meme telecharger plus vite je pense      
 
Ptete que c'est le serveur apres qui satur  ou ptete faire des reglages plus fin dans TCPO  

ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh,enfin

Personne pour me répondre sur le petit doute qui m'étreint ?  
Car si c'est ce que je crains va falloir vite que j'annule ma commande
 
Est-ce normal pour une demande de freebox en dégroupé total (classique avec numéro FT au préalable) de voir figurer ces étapes :
 
3. Votre inscription a été validée par France Télécom  
4. Votre ligne est en cours de construction par France Télécom  
 
Sachant que e suis à l'étape 2 aujourd'hui, donc ces étapes ne sont pas encore passées.
 
Merci !

 
Ouiiiiiiiiiiiiiiiiii
 
exemple chez moi de ce que ça a donné pour mon Degroupage Total
 

 
Ben vi puisque c'est Free commande à FT l'opération
Le petit bout qui va du central à chez toi appartient toujours a FT

Ok merci ! Me voici soulagé !
 
Bon ben plus qu'à attendre alors

ah tien, je viens de passer à l'étape 3.

 
c'est toi qui veut pas comprendre :
 
nul part il n'a ete ecrit que tcpo permettait d'augmenter le debit ATM.
Il permet simplement d'en profiter au maximum en evitant à windows de brider le debit sur le LAN.
 
En gros, de bons reglages de la pile TCP windows permettent d'exclure ton pc et/ou reseau (de chez toi entre ta box et ton pc, je prefere preciser) de la liste des goulets d'etranglement possibles.

 
Je croyais que dans le cas du dégroupage total, FT vendait cette partie à Free. Je me suis donc fourvoyé ?
 
Quelle est la partie qui change de main dans ce cas ?
 
Et bravo pour ton étape 3 ^^

la difference entre de bons reglages par un soft sur TA BECANE et les reglages par defaut ne font pas que tu passes
d'un debit en reception de 250 ko/s à du 500 ko/s,on parle de plus de 700 ko/s dans certain cas.
Apres que certains os se "reserve" un peu de bande passante et que tcp optimizer la libere ok...mais pas de quoi gagner 200%...

C'est juste par 2 coïncidences énormes alors qu'on a eu autant de boost

 
En fait, c'est juste Free qui prend en charge ton abonnement, c'est lui qui paie la location à France Télécom.

 
 
Moi aussi l'option est apparue mais ça veut dire quoi ? Il faut que je contacte le syndic de mon immeuble si je veux que Free raccorde mon immeuble c'est ça ?  

Si t'as toutes ses coordonnées il suffit de remplir le formulaire et c'est Free qui le contactera

y'a pas moyen de voir la liste des ordinateurs connectés à la freebox ?

Bah si.
Pour télécharger un fichier avec un seul thread, je suis passé de 550ko/s à 1600ko/s. Bah oui.
Et c'est pas de la "réservation de bande passante" . Je t'ai donné le calcul qui montre ça dans un précédent post...
 
Sans TCPO, pour saturer ma ligne je devais lancer 3 téléchargement en parallèle. Super utile...
 
Et voilà ce que ça donne vu par la Grenouille :

 
 
Très facile de tester si y'a besoin de TCPO ou pas :
 
1. Lancer le téléchargement de ça : ftp://test-debit.free.fr/image.iso (et pas avec un soft du style Mass Downloader, qui truande le coup... Simplement avec son navigateur web)
2. Attendre un peu et noter la vitesse de téléchargement
3. Arrêter le téléchargement en 1. et lancer de la même manière 2 fois ftp://test-debit.free.fr/image.iso (dans 2 répertoires différents)
4. Attendre que les vitesses se stabilisent, noter la vitesse de téléchargement de chaque, et les additionner.
 
Si le résultat de 4. est bien meilleur que celui de 2., c'est que les paramètres TCP de l'ordinateur (Windows ou Linux ou autre) sont pas optimisés pour le très haut débit, et donc qu'il faut les régler. Et TCPO le fait très bien . Mais on peut aussi le faire à la mano dans la base de registres, c'est juste plus chiant .
 
 
Et le coup du serveur qui sature, ça marche pas avec test-debit.free.fr ...

c'est pas serieux ce que tu me dit...estimer ton down en téléchargeant un iso sur 1 serveur...
si on suit ton raisonement:
test 1 sans tcpo:j'arrive à disons 250 ko/s
j'installe tcpo
test 2: 500 ko/s
je reçois donc 250 ko/s en plus?!
d'où viennent t'ils?ils viennent bien du serveur?!
c'est donc que toi tu n'a pas été capable de les recevoirs à cause de la mauvaise config de la pile tcp? c'est bien ça?
et en installant tcpo ça corrige le probleme?!
windows aurait donc une si mauvaise config de la pile que ça pour passer du simple au double?!

Oui

Oui

Oui

Oui, ça peut arriver. Parcequ'un gros RWIN ne convient pas à tous les cas (en bas débit, acquitter des très gros paquets de données en TCP peut être catastrophique, surtout s'il y a beaucoup de perte).
 
Maintenant relis ça lentement, un exemple avec un RWIN (ou TCPWindowSize, littéralement "fenêtre de réception de données" ) de 65 535 octets :

 
Maintenant, si tu l'oses, tu peux aller faire un tour sur cette page, qui fera état de ta config TCP :
http://www.speedguide.net/analyzer.php
Si ça se trouve elle est parfaitement correcte. Ou pas. Le test que j'ai décrit peut déjà donner une première idée...

hélas tu perds ton temps avec qqun qui :
 
1) croit que lui seul "dit la vérité" (sic)
 
2) ne comprend pas ou ne veut pas comprendre ce qui lui est 'opposé' et *surtout* confirmé, constaté, bref 'validé'  dans *les faits*  
 
3)il dénie déjà ceci ! preuve qu'il n'a jamais été vérifié l'incidence constatable des reglages TCP dans la bdr !
 
>explique moi comment tu peux modifier/augmenter ton debit en modifiant ta base de registre?
 
à partir de là-la foi est plus forte que la raison , c'est pas nouveau !  alors bof... tu ne peux plus rien à ce stade ; pas grave non plus

up

manque le "pas"

j'ai raison quand je dis que tcpo ne peut pas permettre de passer de 250 ko/s à 500 ko/s uniquement parcequ'il "ajusterait" la pile tcp par rapport au debit.windows par defaut n'est pas si pourri du tout.
et c'est pas avec les tests du download de l'iso que t'a pu montrer quoi que ce soit,ni les autres en telechageant chez clubic.

il t'a été démontré le contraire mais bon , crois ce que tu veux
 
déjà tu me fais marrer avec là encore tes 'postulats'...
 
>c'est pas serieux ce que tu me dit...estimer ton down en téléchargeant un iso sur 1 serveur...
 
je sature , tres régulierement ma BP , avec l'iso de Free , sur 1 seul serveur donc ; enfin disons 8 à 9 fois sur 10  
 
le fait que je n'ai que 8Mbits de synchro ( au lieu de 20 par ex) reste totalement anecdotique ici ( par rapport à la capacité du reseau Free pour qqun chez Free donc)  ; je crois que c'est Fred qui a saturé un lien  100Mbits avec cet .iso sur donc un seul serveur ! mais là encore , te dire ça ou pisser dans un violon ...

ok

http://www.freeplayer.org/portal.php?pid=10

Sachant que la bande passante négociée par le modem dans les 2 cas (avec et sans TCPO) est supérieure à 500ko/s et que le serveur en face a lui aussi plus de 500ko/s de bande passante, tu l'expliques comment alors ?

À quoi sert une connexion internet ? À faire des pings ?

Bouarf, j'ai déjà réussi à convaincre banannnus, pourtant c'était pas gagné
 
Et heureusement que tout le monde n'est pas comme paprika, sinon on vivrait dans des cavernes, vêtus de peaux de bêtes, croyant que la terre est plate "sinon on tomberait" et que le soleil tourne autour de la terre "pasqu'il passe au-dessus de notre tête"

 
moi, j'y comprends rien à tous ces chiffres.
t'en pense quoi toi du résultat suivant :
 

 
Pink.
 
nb : impressionnant ta courbe grenouille....

Heu...
 
Bon OK. Y'a 3 paramètres principaux sur lesquels tu peux jouer : MTU, RWIN et TTL
 

 
Il faut savoir que pour les transferts de données par réseaux informatiques on passe son temps à découper des données en morceaux, pour les recoller plus loin. Dans notre cas, ça doit donner quelques chose comme :
{données brutes de x octets} découpées en {blocs TCP de taille RWIN}, eux-même découpés en {paquets IP de taille MSS} pour transiter sur un lien ethernet par exemple, eux-même découpés en {cellules ATM de 52 octets} entre modems ADSL
Une fois arrivés chez le destinataire, les cellules ATM sont assemblées par le modem en paquets IP, eux-même assemblés en blocs TCP, eux-même assemblés en données brutes de x octets. La boucle est bouclée
 
J'en profite pour dire que je fais ça à l'arrache, de tête, un samedi matin vite fait avant de partir en week-end : il y a certainement des erreurs et des imprécisions, je m'en excuse d'avance auprès des pinailleurs qui ne vont pas manquer de me tomber dessus
 
1er morceau, le TCP RWIN (fenêtre de réception de données TCP). Le principe est simple : quand on reçoit RWIN octets, on envoie un acquittement au serveur pour dire "OK, on passe au suivant". On a donc ceci :
 
[ RWIN octets reçus ]=>[ envoi d'un acquittement ]=>[ RWIN octets reçus ]=>[ envoi d'un acquittement ]=>...=>[ RWIN ou moins octets reçus (cas du dernier bloc) ]=>[ envoi d'un acquittement final ]
 
Il n'y a pas de limites de taille de RWIN, c'est juste une question de bon sens :
• si RWIN est trop petit, tu passes ton temps à envoyer des acquittements, et pendant le temps d'un acquittement, tu ne reçois pas de données .
Et c'est ce que je disais plus haut : si tu reçois RWIN octets en 50 millièmes de secondes et que pour envoyer un acquittement il te faut 50 millièmes de secondes (en gros c'est comme un ping) : tu reçois des données pendant 50ms, tu attends 50ms, tu reçois des données pendant 50ms, tu attends 50ms etc. La moitié du temps tu attends des données : si tu remplis ton RWIN à la vitesse de 500ko/s par exemple, ton fichier vu par ton disque dur arrive à la vitesse de 250ko/s, car il met 2 fois plus de temps à arriver
• si RWIN est trop gros, tu dois acquitter des gros volumes de données, ce n'est pas l'idéal non plus (imagine remplir des RWIN de 1Mo à 5ko/s )
• Il faut donc faire un compromis, pour que même si tu as un serveur avec un ping assez pourri (sur speedguide ils prennent 200 et 500ms) il faut que ton temps d'acquittement soit négligeable devant celui qu'il te faut pour recevoir RWIN octets. Et ça c'est dans l'encadré bandwith * delay product
 
 
Ca c'était pour la couche TCP.
 
Au niveau de la couche IP, les paquets font MTU octets. Dans ces MTU octets, 40 octets sont des données de contrôle, ce qui fait que les données "utiles" dans le paquet IP font MSS octets ( MSS = MTU - 40). Là par contre, il y a une limite haute, de 1500 octets pour le MTU (c'est la taille max d'un paquet de données sur un lien ethernet, de mémoire).
Pour bien faire, il faut que ton RWIN soit un multiple de ton MSS : ça permet d'éviter d'avoir à envoyer un paquet de taille inférieure au maximum pour finir de remplir ton RWIN, alors que le but du jeu est justement d'avoir des paquets IP les plus gros possibles.
Exemple : pour envoyer 1000 octets "utiles", avec un MSS de 1000 octets tu reçois en vérité 1040 octets. Avec un MSS de 500 octets, t'es obligé de faire 2 paquets, donc de recevoir 500 + 40 + 500 + 40 = 1080 octets : c'est pratiquement 4% de bande passante perdue bêtement, sans même compter le temps perdu entre les 2 paquets.
 
Donc en pratique, on choisit le MTU le plus grand que permet ta connexion (1500 en dégroupé, 1492 en non dégroupé à cause du protocole PPPoE qui rajoute 8 octets de contrôle dans le MSS).
Ca, c'est les encadrés MTU, MSS et RWIN
Sauf que le site que tu citais il y a quelques pages fait une bonne remarque : ton paquet IP est encore découpé en cellules ATM sur le lien ADSL. On peut donc gratter l'envoi d'une cellule ATM en choisissant son MTU comme étant un multiple de la taille utile dans une cellule ATM.
Sauf qu'une cellule ATM c'est très petit (53 octets, dont 48 octets de charge utile), alors oui, on y gagne 4 octets par paquet IP au niveau de la couche ATM, mais on y perd aussi au niveau de la couche IP...
S'il n'a pas été fait, il faut faire le calcul complet pour savoir si on y gagne vraiment
 
Reste le Time To Live (TTL, "temps qu'il reste à vivre" ).
Ca, ça peut être un problème très con
Dans chaque paquet IP, parmis les octets de contrôle t'as un octet "TTL", qui est rempli par l'émetteur du paquet, et qui est décrémenté par chaque routeur par lequel transite le paquet. Ca permet d'éviter que des paquets se promènent ad vitam eternam dans internet : à un moment le TTL va être nul et le paquet va obligatoirement être jeté par le routeur.
Comme c'est codé sur un octet, le TTL vaut entre 0 et 255.
Les valeurs traditionnelles sont 127 et 255 (dépend des OS et des réglages).
Dans ton cas il vaut probablement 127, puisque reçu par speedguide, le paquet que tu leur a envoyé avait un TTL de 111 : il a donc traversé 16 routeurs.
Avec un TTL de moins de 16, speedguide n'aurait jamais reçu ton paquet !
C'est pour ça qu'il faut le prendre suffisamment grand. Au-delà de 127 c'est pas vraiment très utile, ça gêne "l'internet", donc toi aussi, indirectement
Ca c'était l'encadré Time to live left
 
 
Les autres encadrés, ce sont des paramètres pour lesquels j'ai rien à dire
 
Voilà
 
 
Euh sinon je trouve des chiffres bons, mais si tu veux faire un test avec ton MTU à 1500 octets, il ne faut pas oublier de modifier le RWIN en conséquence. Tu peux aussi encore doubler ton RWIN. Mais en lisant bien, tu avais la réponse (encadré bandwith * delay) : t'es limité à 20mbps avec les serveurs dont le ping est de 200ms, et 8mbps avec ceux à 500ms. Ce sont des pings extrêmes, en pratique la majorité des serveurs se pinguent en moins de 100ms en free dégroupé avec réglage du ping standard.
 
 
Bon week-end

Le calcul est pas si compliqué en fait si on ne prend en compte que le volume de données (c'est-à-dire sans compter la latence entre 2 paquets IP, qui pourrait être très supérieure à la latence entre 2 cellules ATM) :
à chaque paquet IP supplémentaire, on se mange 40 octets de contrôle en plus
à chaque cellule ATM supplémentaire, on se mange 5 octets de contrôle en plus
 
Le MTU préconisé par Grenouille est de 1480, soit un MSS de 1440
Le MTU max en dégroupé est de 1500, soit un MSS de 1460
 
Pour être sûr d'avoir que des paquets IP pleins dans les 2 cas, il faut envoyer 1460 / 1440 qu'on peut réduire à 73 / 72 : 73 paquets de 1440 octets = 72 paquets de 1460 = 105 120 octets
 
Ce qui veut dire que tous les 105 120 octets, avec un MTU de 1480 on envoie un paquet IP plein de plus qu'avec un MTU de 1500 : on se pénalise donc de 40 octets dans le premier cas.
 
Par contre, avec un MTU de 1500, à chaque paquet IP émis on envoie une cellule ATM de plus, on se pénalise donc de 72 x 5 = 360 octets, le MTU de 1480 octets est donc plus intéressant, si on néglige les latences entre paquets et entre cellules
 
(Bon ça fait un écart de 320 octets sur 105 120, soit environ 0.3% hein, et encore, en espérant que la latence entre 2 paquets IP soit inférieure ou égale à celle entre 2 cellules ATM : pas de miracle )

tu devrais peut etre compiler tout ça dans un topik (?) ; les grandes lignes ;  et laisser completer , discuter,  les trucs tres pointus éventuels ...
 
à toi de voir, bien sur

 
Merci!

ok, merci.....mais j'ai rien compris.   (désolé... )

c'est trop compliqué pour moi là.

en gros, tu me conseille de doubler mon TCP receive windows ? (le mettre donc à 1013760)

et de mettre le TTL à 127 ? (le mien est à 128 car j'ai lu je sais plus où qu'il fallait que çà soit un multiple de 64, et qu'avec free en dégroupé, il fallait mettre 128)

pour le MTU, je l'ai mis à 1480 en suivant le topic Grenouille qui disait qu'on perdait des trucs en mettant 1500.....

Pink

EDIT : autre chose, çà sert à quelque chose de faire çà :

http://www.pcastuces.com/pratique/ [...] /page6.htm

http://cs-fusion.com/ressources/vi [...] -adsl.html

perso, pour le max connection per server.... j'ai mis 20 et 20.....le site dit de mettre 10 et 10.

20, c'est trop ?

merci.

Pink

nb : je vais doubler mon TCP receive window pour voir...

bonsoir,  
 
s'il y a du partiel, il y a du total; enfin c'est ce que j'ai pu voir sur les deploiements et autres migrations dans les repartiteurs FT.
par contre il reste enormement de repartiteurs non equipés de dslam free donc free loue toujours les dslam a FT et donc pour la procedure free total je ne peux pas t'aider plus que cela. je pense quand meme que free doit avoir des applications à valider dans ces cas là (en tout cas c'est le cas chez FT lors de l'attribution des debit).
 
 

Il y a des retards en ce moment sur les livraisons de freebox HD ?

Possible, le temps qu'UPS se mette en jambe (les freebox HD, pour nouvel abonnement, sont livrés par UPS maintenant au lieu de la poste.)

Salut a tous !!
 
ca fait un peu plus de 2 semaines que j'ai un soucis avec ma connection, desque j'active la Tv j'ai le droit a une desynchro et pour la retrouver faut que je debranche ma freebox V4 au moins 10min.
Sinon internet fonctionne bien y a juste la Tv , j'ai essayé de changer les filtres mais rien y fait toujours pareil.