Je suis chez Free, et je n'ai jamais eu de gros problèmes, tout
fonctionne très correctement.
Juste que depuis 3 ou 4 jours, je n'arrive pas à avoir de débits
corrects. Par exemple, je ne peux télécharger qu'à 3 ko/s, alors que
les valeurs annoncées par mon routeur (DG834G NetGear) sont :
Version Firmware ADSL 1.00.09.00
Etat du Modem Connected
Vitesse de connexion descendante 7616 kbps
Vitesse de connexion montante 960 kbps
VPI 8
VCI 35
L'atténuation est très raisonnable :
Lien ADSL Downstream Upstream
Vitesse de connexion 7616 kbps 960 kbps
Atténuation lignen 23 db 13 db
Marge de bruit 17 db 7 db
Pour vérifier que cela ne venait pas d'une machine précisément, j'ai
essayé sur 3 machines, avec des OS différents (Linux et Mac OS X et
autre) : même problèmes. Or cela fonctionnait parfaitement il y a
seulement quelques jours.
Autre précision : j'ai essayé un traceroute avec plusieurs URL, et il
semble qu'une machine demande systématiquement plus de temps pour
répondre. Mais comme je ne suis pas un spécialiste, je dois me tromper.
Enfin, est-il possible que mes téléchargements soient "limités?" en
vitesse par quelque moyen technique ?
Les pages web s'affichent, pas très vite, mais c'est très loin
d'atteindre la lenteur de chaque téléchargement :-/
Je précise que je ne télécharge pas de musique, ni quoi que ce soit
illégallement, et j'utilise surtout ftp, ssh (via un tunnel sécurisé),
et cvs pour un projet libre. Et j'ai vraiment besoin de bande passante.
Peut-être des travaux ... ou une machine qui a des problèmes ? Le
routeur ? (pourquoi pas ... )
Merci d'avance pour toute information et/ou aide.
Cordialement,
eric bachard
--
<ericb@openoffice.org>
Francophone OpenOffice.org Commmunity developer (Linux PPC / Mac OS X /
X11)
See : <http://fr.openoffice.org>
Mais par curiosité, dans quelle doc Apple préconise cette modification ?
BroadbandTuner.dmg
fournie par la Pomme elle même. Donc, il doit être facile de trouver un article de la KB qui détaille ?
-- Je cherche comme cherche celui qui veut trouver, et je trouve comme trouve celui qui a cherché. :o)
ericb
Apparemment, tout va mieux maintenant (aucune idée du pourquoi). Comme workaround, j'avais essayé en utilisant le proxy (proxy.free.fr), mais seul le port http avait un débit correct.
Pour à peu près tout, je dépasse maintenant les 3,5 ko/s en download (c'était quand même pas beaucoup...). J'ai même retrouvé des valeurs très correctes.
Merci à celle ou celui qui a résolu le probleme :-)
--
Francophone OpenOffice.org Commmunity developer (Linux PPC / Mac OS X / X11) See : <http://fr.openoffice.org>
Apparemment, tout va mieux maintenant (aucune idée du pourquoi). Comme
workaround, j'avais essayé en utilisant le proxy (proxy.free.fr), mais
seul le port http avait un débit correct.
Pour à peu près tout, je dépasse maintenant les 3,5 ko/s en download
(c'était quand même pas beaucoup...). J'ai même retrouvé des valeurs
très correctes.
Merci à celle ou celui qui a résolu le probleme :-)
--
<ericb@openoffice.org>
Francophone OpenOffice.org Commmunity developer (Linux PPC / Mac OS X /
X11)
See : <http://fr.openoffice.org>
Apparemment, tout va mieux maintenant (aucune idée du pourquoi). Comme workaround, j'avais essayé en utilisant le proxy (proxy.free.fr), mais seul le port http avait un débit correct.
Pour à peu près tout, je dépasse maintenant les 3,5 ko/s en download (c'était quand même pas beaucoup...). J'ai même retrouvé des valeurs très correctes.
Merci à celle ou celui qui a résolu le probleme :-)
--
Francophone OpenOffice.org Commmunity developer (Linux PPC / Mac OS X / X11) See : <http://fr.openoffice.org>
Eric Levenez
Le 5/12/05 19:00, dans <1h741up.4l32pnczwop2N%, « Anne Le Guennec » a écrit :
Eric Levenez wrote:
Mais par curiosité, dans quelle doc Apple préconise cette modification ?
BroadbandTuner.dmg
fournie par la Pomme elle même. Donc, il doit être facile de trouver un article de la KB qui détaille ?
Je ne connaissais pas. J'ai trouvé la doc sur le site Apple :
En fait ce package modifie juste les 3 paramètres classiques de la pile TCP, et comme je l'ai dit, chez moi cela ralenti les transferts. Il ne faut donc pas appliquer ce patch sans faire un bench (ou taper les 3 lignes de shells) avant et après pour voir si cela marche bien.
Ne pas oublier que l'accès Internet ADSL2+ c'est du 20 Mbits/s alors que les Mac pros sont équipés en 1 Gbits/s depuis longtemps.
Le cas où le patch est intéressant est lorsque l'accès Ethernet est de très bonne qualité (très peu de retry) et que les paquets IP mettent longtemps à être acquittés (cela se traduit par un "ping" long).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 5/12/05 19:00, dans <1h741up.4l32pnczwop2N%c.moi@free.fr>, « Anne Le
Guennec » <c.moi@free.fr> a écrit :
Eric Levenez <news@levenez.com> wrote:
Mais par curiosité, dans quelle doc Apple préconise cette modification ?
BroadbandTuner.dmg
fournie par la Pomme elle même. Donc, il doit être facile de trouver un
article de la KB qui détaille ?
Je ne connaissais pas. J'ai trouvé la doc sur le site Apple :
En fait ce package modifie juste les 3 paramètres classiques de la pile TCP,
et comme je l'ai dit, chez moi cela ralenti les transferts. Il ne faut donc
pas appliquer ce patch sans faire un bench (ou taper les 3 lignes de shells)
avant et après pour voir si cela marche bien.
Ne pas oublier que l'accès Internet ADSL2+ c'est du 20 Mbits/s alors que les
Mac pros sont équipés en 1 Gbits/s depuis longtemps.
Le cas où le patch est intéressant est lorsque l'accès Ethernet est de très
bonne qualité (très peu de retry) et que les paquets IP mettent longtemps à
être acquittés (cela se traduit par un "ping" long).
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
En fait ce package modifie juste les 3 paramètres classiques de la pile TCP, et comme je l'ai dit, chez moi cela ralenti les transferts. Il ne faut donc pas appliquer ce patch sans faire un bench (ou taper les 3 lignes de shells) avant et après pour voir si cela marche bien.
Ne pas oublier que l'accès Internet ADSL2+ c'est du 20 Mbits/s alors que les Mac pros sont équipés en 1 Gbits/s depuis longtemps.
Le cas où le patch est intéressant est lorsque l'accès Ethernet est de très bonne qualité (très peu de retry) et que les paquets IP mettent longtemps à être acquittés (cela se traduit par un "ping" long).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
c.moi
Eric Levenez wrote:
Le cas où le patch est intéressant est lorsque l'accès Ethernet est de très bonne qualité (très peu de retry) et que les paquets IP mettent longtemps à être acquittés (cela se traduit par un "ping" long).
Cas d'une connexion Wanadoo à 512Ko/s alors ?
-- Je cherche comme cherche celui qui veut trouver, et je trouve comme trouve celui qui a cherché. :o)
Eric Levenez <news@levenez.com> wrote:
Le cas où le patch est intéressant est lorsque l'accès Ethernet est de très
bonne qualité (très peu de retry) et que les paquets IP mettent longtemps à
être acquittés (cela se traduit par un "ping" long).
Cas d'une connexion Wanadoo à 512Ko/s alors ?
--
Je cherche comme cherche celui qui veut trouver,
et je trouve comme trouve celui qui a cherché. :o)
Le cas où le patch est intéressant est lorsque l'accès Ethernet est de très bonne qualité (très peu de retry) et que les paquets IP mettent longtemps à être acquittés (cela se traduit par un "ping" long).
Cas d'une connexion Wanadoo à 512Ko/s alors ?
-- Je cherche comme cherche celui qui veut trouver, et je trouve comme trouve celui qui a cherché. :o)
Eric Levenez
Le 6/12/05 20:14, dans <1h75hvu.1fk6ukk12qmu58N%, « Anne Le Guennec » a écrit :
Eric Levenez wrote:
Le cas où le patch est intéressant est lorsque l'accès Ethernet est de très bonne qualité (très peu de retry) et que les paquets IP mettent longtemps à être acquittés (cela se traduit par un "ping" long).
Cas d'une connexion Wanadoo à 512Ko/s alors ?
Cela dépend fortement de la qualité de la ligne, pas juste du débit.
Apple préconise le patch pour les liaisons Internet à fibre optique quand même, et pas pour les liaisons ADSL cuivre.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 6/12/05 20:14, dans <1h75hvu.1fk6ukk12qmu58N%c.moi@free.fr>, « Anne Le
Guennec » <c.moi@free.fr> a écrit :
Eric Levenez <news@levenez.com> wrote:
Le cas où le patch est intéressant est lorsque l'accès Ethernet est de très
bonne qualité (très peu de retry) et que les paquets IP mettent longtemps à
être acquittés (cela se traduit par un "ping" long).
Cas d'une connexion Wanadoo à 512Ko/s alors ?
Cela dépend fortement de la qualité de la ligne, pas juste du débit.
Apple préconise le patch pour les liaisons Internet à fibre optique quand
même, et pas pour les liaisons ADSL cuivre.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 6/12/05 20:14, dans <1h75hvu.1fk6ukk12qmu58N%, « Anne Le Guennec » a écrit :
Eric Levenez wrote:
Le cas où le patch est intéressant est lorsque l'accès Ethernet est de très bonne qualité (très peu de retry) et que les paquets IP mettent longtemps à être acquittés (cela se traduit par un "ping" long).
Cas d'une connexion Wanadoo à 512Ko/s alors ?
Cela dépend fortement de la qualité de la ligne, pas juste du débit.
Apple préconise le patch pour les liaisons Internet à fibre optique quand même, et pas pour les liaisons ADSL cuivre.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Herm
"Eric Levenez" a écrit dans le message de news: ...
Eric Levenez wrote:
Le cas où le patch est intéressant est lorsque l'accès Ethernet est de très bonne qualité (très peu de retry) et que les paquets IP mettent longtemps à être acquittés (cela se traduit par un "ping" long).
Cas d'une connexion Wanadoo à 512Ko/s alors ?
Cela dépend fortement de la qualité de la ligne, pas juste du débit.
Apple préconise le patch pour les liaisons Internet à fibre optique quand même, et pas pour les liaisons ADSL cuivre.
Ça dépend de la conjonction de deux facteurs :
- Vitesse élevée (débit émission + débit réception). - Latence importante (délais entre l'envoi effectif d'un paquet IP et la réception par ce même poste d'un accusé de réception).
Si l'on veut un débit de données continu, il faut que l'émetteur accepte d'émettre "dans le vide" suffisament longtemps pour qu'un accusé de réception lui indique que l'envoi fait il y a n milisecondes est bien arrivé à bon port.
Le truc pour y arriver, c'est la valeur contenue dans tous les accusés de réception, et qui est la mesure de la taille libre dans le tampon de réception du reçeveur - tampon appelé RWIN -. Cette gauge mesure la quantité de données qu'il est encore possible d'envoyer sans saturer le reçeveur.
Ce que l'émetteur ne peut pas savoir en temps réel, par contre, c'est qu'en fait les paquets arrivés dans l'ordre ne sont pas stockés dans RWIN, mais transmis directement à l'application de la couche supérieure. Seuls sont stockés, brièvement le plus souvent, des paquets qui arriveraient après celui attendu. Et dès que ce paquet manquant parvient au reçeveur, le paquet plus tous ceux qui le suivent et qui ont été placés dans RWIN sont "dépilés" d'un coup. Dans un transfert normal, les paquets arrivent la plupart du temps dans l'ordre.
Chaque accusé de réception contenant une valeur réactualisée de cette mesure, l'émetteur peut réinitialiser son compteur d'octets émissibles, et ça repart. Comme un accusé de réception est toujours positif (en TCP/IP), et qu'il contient en plus le n° d'ordre du dernier paquet correctement arrivé, cette indication vaut pour les autres paquets précédement arrivés. Dit de façon plus courte, le reçeveur n'est pas obligé d'accuser réception de chaque paquet arrivé. Un accusé tous les deux paquets (ou plus si on a pioché des paquets dans RWIN) suffit. Ça a l'avantage de moins congestionner la voie retour (On est pas forcément en full duplex sur tous les segments du chemin entre émetteur et reçeveur !), avec l'inconvénient de se reposer encore un peu plus sur RWIN pour assurer un débit constant.
Et c'est pour ça que l'on a l'influence des deux facteurs de vitesse et de latence...
* A latence constance, un débit rapide épuisera plus rapidement la place libre de RWIN, et passé un stade, le tampon RWIN semblera être consommé plus vite que le temps mis pour un accusé de réception à revenir et indiquer qu'en fait, non, y'a de la place libre !
* A vitesse constante, une latence augmentée fera de même : RWIN semblera complètement plein du point de vue de l'émetteur, avant même que l'accusé de réception ne parvienne par la voie retour pour réactualiser le compteur...
En débit 512k ADSL classique (Interleave), la latence est loin d'être négligeable...
Essais de calculs en PPPoA, en supposant un MTU de 1500 octets sur la liaison :
Si je suppose que la latence est directement proportionnelle au débit, donc à la taille des paquets (c'est faux quand on fait des mesures, mais j'ai du mal à calculer autrement), on a réception de gros paquets : Ping d'un paquet de 1500 octets sur liaison 512/128 : 170 ms minimum. La plus grande part de ce délais, c'est le retour du ping sur la voie 128... Règle de 3 pour ne garder que la part du ping lié au débit 512 : 170 ms * ( (512+128)/128 ) = 170ms * 0.2 =~ 35 ms
Et émission de petits paquets d'accusé de réception (2 cellules ATM a minima) : Ping d'un paquet de 63 octets sur liaison 512/128 : 62 ms minimum. Règle de 3 comme ci-dessus, mais on garde la latence émission : 62 * ( (512+128)/512 ) = 62 * 0.8 = 50 ms
Et comme beaucoup d'OS attendent la réception de deux paquets pour envoyer un accusé de réception, on obtient une latence mini de : 35 * 2 + 50 = 120 ms
Pendant 120 ms, à 512 kb/s, on peut reçevoir 512 000 * 0,12 = 61 440 bits, soit 7 680 octets... Un poil plus que 5 paquets IP de 1500 octets.
RWIN stockant des contenus de paquets TCP/IP, des MSS (avec 40 octets d'en-tête IP+TCP, MSS=MTU-40= 1460 octets ), il faudrait un RWIN d'au moins 6 * MSS = 8 760 octets.
D'après http://support.microsoft.com/default.aspx?scid=kb;en-us;158474 , pour les windows 9x, RWIN est fixé à 8192 par défaut, cela fait seulement le contenu de 5 paquets... Pour ces OS, on verrait une petite amélioration des téléchargement en augmentant ce RWIN au multiple suivant du MSS (8760 ou plus) ...
D'après http://support.microsoft.com/kb/314053/EN-US , pour les windows xp, RWIN est calculé à 8760 octets, 6 paquets, de justesse le minimum.
Ces valeurs restent minimalistes... Si le site a contacter possède une latence supplémentaire, et/ou si les réseaux situé entre l'émetteur et le récepteur font que des paquets arrivent dans le désordre, ces RWIN ne sont plus du tout adaptés !
Quant aux Macs, si j'en crois la doc d'IP Net tuner : http://www.sustworks.com/site/prod_otat_faq.html, le RWIN par défaut d'Open Transport serait aux alentours de 16k (16 384 octets)... Voila qui est bien plus confortable que les valeurs par défaut de chez Microsoft !
Néamoins, IP Net tuner semble vouloir régler, sur une ligne ADSL/Cable, un RWIN valant 36*MSS, avec MSS obtenu d'un MTU auto-détecté. Avec un MTU à 1500 octets, MSS 1460 octets, ça fait un RWIN à 52 560 octets. De quoi aider à maintenir un bon débit même avec des serveurs "difficiles"...
Enfin bref, et au risque d'enclancher une flamme... les Macs semblent mieux armés que les PCs pour le haut débit, dans leurs jus d'origines. En contrepartie, faire des réglages d'optimisation sur Mac semble bien moins commode que sur PC (enfin, avec les Mac OS d'avant X) ...
-- Herm (Pardon pour la longueur)
"Eric Levenez" a écrit dans le message de news: ...
Eric Levenez wrote:
Le cas où le patch est intéressant est lorsque l'accès Ethernet est de
très
bonne qualité (très peu de retry) et que les paquets IP mettent
longtemps à
être acquittés (cela se traduit par un "ping" long).
Cas d'une connexion Wanadoo à 512Ko/s alors ?
Cela dépend fortement de la qualité de la ligne, pas juste du débit.
Apple préconise le patch pour les liaisons Internet à fibre optique quand
même, et pas pour les liaisons ADSL cuivre.
Ça dépend de la conjonction de deux facteurs :
- Vitesse élevée (débit émission + débit réception).
- Latence importante (délais entre l'envoi effectif d'un paquet IP et la
réception par ce même poste d'un accusé de réception).
Si l'on veut un débit de données continu, il faut que l'émetteur accepte
d'émettre "dans le vide" suffisament longtemps pour qu'un accusé de
réception lui indique que l'envoi fait il y a n milisecondes est bien arrivé
à bon port.
Le truc pour y arriver, c'est la valeur contenue dans tous les accusés de
réception, et qui est la mesure de la taille libre dans le tampon de
réception du reçeveur - tampon appelé RWIN -. Cette gauge mesure la quantité
de données qu'il est encore possible d'envoyer sans saturer le reçeveur.
Ce que l'émetteur ne peut pas savoir en temps réel, par contre, c'est qu'en
fait les paquets arrivés dans l'ordre ne sont pas stockés dans RWIN, mais
transmis directement à l'application de la couche supérieure. Seuls sont
stockés, brièvement le plus souvent, des paquets qui arriveraient après
celui attendu. Et dès que ce paquet manquant parvient au reçeveur, le paquet
plus tous ceux qui le suivent et qui ont été placés dans RWIN sont "dépilés"
d'un coup. Dans un transfert normal, les paquets arrivent la plupart du
temps dans l'ordre.
Chaque accusé de réception contenant une valeur réactualisée de cette
mesure, l'émetteur peut réinitialiser son compteur d'octets émissibles, et
ça repart. Comme un accusé de réception est toujours positif (en TCP/IP), et
qu'il contient en plus le n° d'ordre du dernier paquet correctement arrivé,
cette indication vaut pour les autres paquets précédement arrivés. Dit de
façon plus courte, le reçeveur n'est pas obligé d'accuser réception de
chaque paquet arrivé. Un accusé tous les deux paquets (ou plus si on a
pioché des paquets dans RWIN) suffit. Ça a l'avantage de moins congestionner
la voie retour (On est pas forcément en full duplex sur tous les segments du
chemin entre émetteur et reçeveur !), avec l'inconvénient de se reposer
encore un peu plus sur RWIN pour assurer un débit constant.
Et c'est pour ça que l'on a l'influence des deux facteurs de vitesse et de
latence...
* A latence constance, un débit rapide épuisera plus rapidement la place
libre de RWIN, et passé un stade, le tampon RWIN semblera être consommé plus
vite que le temps mis pour un accusé de réception à revenir et indiquer
qu'en fait, non, y'a de la place libre !
* A vitesse constante, une latence augmentée fera de même : RWIN semblera
complètement plein du point de vue de l'émetteur, avant même que l'accusé de
réception ne parvienne par la voie retour pour réactualiser le compteur...
En débit 512k ADSL classique (Interleave), la latence est loin d'être
négligeable...
Essais de calculs en PPPoA, en supposant un MTU de 1500 octets sur la
liaison :
Si je suppose que la latence est directement proportionnelle au débit, donc
à la taille des paquets (c'est faux quand on fait des mesures, mais j'ai du
mal à calculer autrement), on a réception de gros paquets :
Ping d'un paquet de 1500 octets sur liaison 512/128 : 170 ms minimum.
La plus grande part de ce délais, c'est le retour du ping sur la voie
128...
Règle de 3 pour ne garder que la part du ping lié au débit 512 :
170 ms * ( (512+128)/128 ) = 170ms * 0.2 =~ 35 ms
Et émission de petits paquets d'accusé de réception (2 cellules ATM a
minima) :
Ping d'un paquet de 63 octets sur liaison 512/128 : 62 ms minimum.
Règle de 3 comme ci-dessus, mais on garde la latence émission :
62 * ( (512+128)/512 ) = 62 * 0.8 = 50 ms
Et comme beaucoup d'OS attendent la réception de deux paquets pour envoyer
un accusé de réception, on obtient une latence mini de : 35 * 2 + 50 = 120
ms
Pendant 120 ms, à 512 kb/s, on peut reçevoir 512 000 * 0,12 = 61 440 bits,
soit 7 680 octets... Un poil plus que 5 paquets IP de 1500 octets.
RWIN stockant des contenus de paquets TCP/IP, des MSS (avec 40 octets
d'en-tête IP+TCP, MSS=MTU-40= 1460 octets ), il faudrait un RWIN d'au moins
6 * MSS = 8 760 octets.
D'après http://support.microsoft.com/default.aspx?scid=kb;en-us;158474 ,
pour les windows 9x, RWIN est fixé à 8192 par défaut, cela fait seulement le
contenu de 5 paquets... Pour ces OS, on verrait une petite amélioration des
téléchargement en augmentant ce RWIN au multiple suivant du MSS (8760 ou
plus) ...
D'après http://support.microsoft.com/kb/314053/EN-US , pour les windows xp,
RWIN est calculé à 8760 octets, 6 paquets, de justesse le minimum.
Ces valeurs restent minimalistes... Si le site a contacter possède une
latence supplémentaire, et/ou si les réseaux situé entre l'émetteur et le
récepteur font que des paquets arrivent dans le désordre, ces RWIN ne sont
plus du tout adaptés !
Quant aux Macs, si j'en crois la doc d'IP Net tuner :
http://www.sustworks.com/site/prod_otat_faq.html, le RWIN par défaut d'Open
Transport serait aux alentours de 16k (16 384 octets)... Voila qui est bien
plus confortable que les valeurs par défaut de chez Microsoft !
Néamoins, IP Net tuner semble vouloir régler, sur une ligne ADSL/Cable, un
RWIN valant 36*MSS, avec MSS obtenu d'un MTU auto-détecté. Avec un MTU à
1500 octets, MSS 1460 octets, ça fait un RWIN à 52 560 octets. De quoi aider
à maintenir un bon débit même avec des serveurs "difficiles"...
Enfin bref, et au risque d'enclancher une flamme... les Macs semblent mieux
armés que les PCs pour le haut débit, dans leurs jus d'origines. En
contrepartie, faire des réglages d'optimisation sur Mac semble bien moins
commode que sur PC (enfin, avec les Mac OS d'avant X) ...
"Eric Levenez" a écrit dans le message de news: ...
Eric Levenez wrote:
Le cas où le patch est intéressant est lorsque l'accès Ethernet est de très bonne qualité (très peu de retry) et que les paquets IP mettent longtemps à être acquittés (cela se traduit par un "ping" long).
Cas d'une connexion Wanadoo à 512Ko/s alors ?
Cela dépend fortement de la qualité de la ligne, pas juste du débit.
Apple préconise le patch pour les liaisons Internet à fibre optique quand même, et pas pour les liaisons ADSL cuivre.
Ça dépend de la conjonction de deux facteurs :
- Vitesse élevée (débit émission + débit réception). - Latence importante (délais entre l'envoi effectif d'un paquet IP et la réception par ce même poste d'un accusé de réception).
Si l'on veut un débit de données continu, il faut que l'émetteur accepte d'émettre "dans le vide" suffisament longtemps pour qu'un accusé de réception lui indique que l'envoi fait il y a n milisecondes est bien arrivé à bon port.
Le truc pour y arriver, c'est la valeur contenue dans tous les accusés de réception, et qui est la mesure de la taille libre dans le tampon de réception du reçeveur - tampon appelé RWIN -. Cette gauge mesure la quantité de données qu'il est encore possible d'envoyer sans saturer le reçeveur.
Ce que l'émetteur ne peut pas savoir en temps réel, par contre, c'est qu'en fait les paquets arrivés dans l'ordre ne sont pas stockés dans RWIN, mais transmis directement à l'application de la couche supérieure. Seuls sont stockés, brièvement le plus souvent, des paquets qui arriveraient après celui attendu. Et dès que ce paquet manquant parvient au reçeveur, le paquet plus tous ceux qui le suivent et qui ont été placés dans RWIN sont "dépilés" d'un coup. Dans un transfert normal, les paquets arrivent la plupart du temps dans l'ordre.
Chaque accusé de réception contenant une valeur réactualisée de cette mesure, l'émetteur peut réinitialiser son compteur d'octets émissibles, et ça repart. Comme un accusé de réception est toujours positif (en TCP/IP), et qu'il contient en plus le n° d'ordre du dernier paquet correctement arrivé, cette indication vaut pour les autres paquets précédement arrivés. Dit de façon plus courte, le reçeveur n'est pas obligé d'accuser réception de chaque paquet arrivé. Un accusé tous les deux paquets (ou plus si on a pioché des paquets dans RWIN) suffit. Ça a l'avantage de moins congestionner la voie retour (On est pas forcément en full duplex sur tous les segments du chemin entre émetteur et reçeveur !), avec l'inconvénient de se reposer encore un peu plus sur RWIN pour assurer un débit constant.
Et c'est pour ça que l'on a l'influence des deux facteurs de vitesse et de latence...
* A latence constance, un débit rapide épuisera plus rapidement la place libre de RWIN, et passé un stade, le tampon RWIN semblera être consommé plus vite que le temps mis pour un accusé de réception à revenir et indiquer qu'en fait, non, y'a de la place libre !
* A vitesse constante, une latence augmentée fera de même : RWIN semblera complètement plein du point de vue de l'émetteur, avant même que l'accusé de réception ne parvienne par la voie retour pour réactualiser le compteur...
En débit 512k ADSL classique (Interleave), la latence est loin d'être négligeable...
Essais de calculs en PPPoA, en supposant un MTU de 1500 octets sur la liaison :
Si je suppose que la latence est directement proportionnelle au débit, donc à la taille des paquets (c'est faux quand on fait des mesures, mais j'ai du mal à calculer autrement), on a réception de gros paquets : Ping d'un paquet de 1500 octets sur liaison 512/128 : 170 ms minimum. La plus grande part de ce délais, c'est le retour du ping sur la voie 128... Règle de 3 pour ne garder que la part du ping lié au débit 512 : 170 ms * ( (512+128)/128 ) = 170ms * 0.2 =~ 35 ms
Et émission de petits paquets d'accusé de réception (2 cellules ATM a minima) : Ping d'un paquet de 63 octets sur liaison 512/128 : 62 ms minimum. Règle de 3 comme ci-dessus, mais on garde la latence émission : 62 * ( (512+128)/512 ) = 62 * 0.8 = 50 ms
Et comme beaucoup d'OS attendent la réception de deux paquets pour envoyer un accusé de réception, on obtient une latence mini de : 35 * 2 + 50 = 120 ms
Pendant 120 ms, à 512 kb/s, on peut reçevoir 512 000 * 0,12 = 61 440 bits, soit 7 680 octets... Un poil plus que 5 paquets IP de 1500 octets.
RWIN stockant des contenus de paquets TCP/IP, des MSS (avec 40 octets d'en-tête IP+TCP, MSS=MTU-40= 1460 octets ), il faudrait un RWIN d'au moins 6 * MSS = 8 760 octets.
D'après http://support.microsoft.com/default.aspx?scid=kb;en-us;158474 , pour les windows 9x, RWIN est fixé à 8192 par défaut, cela fait seulement le contenu de 5 paquets... Pour ces OS, on verrait une petite amélioration des téléchargement en augmentant ce RWIN au multiple suivant du MSS (8760 ou plus) ...
D'après http://support.microsoft.com/kb/314053/EN-US , pour les windows xp, RWIN est calculé à 8760 octets, 6 paquets, de justesse le minimum.
Ces valeurs restent minimalistes... Si le site a contacter possède une latence supplémentaire, et/ou si les réseaux situé entre l'émetteur et le récepteur font que des paquets arrivent dans le désordre, ces RWIN ne sont plus du tout adaptés !
Quant aux Macs, si j'en crois la doc d'IP Net tuner : http://www.sustworks.com/site/prod_otat_faq.html, le RWIN par défaut d'Open Transport serait aux alentours de 16k (16 384 octets)... Voila qui est bien plus confortable que les valeurs par défaut de chez Microsoft !
Néamoins, IP Net tuner semble vouloir régler, sur une ligne ADSL/Cable, un RWIN valant 36*MSS, avec MSS obtenu d'un MTU auto-détecté. Avec un MTU à 1500 octets, MSS 1460 octets, ça fait un RWIN à 52 560 octets. De quoi aider à maintenir un bon débit même avec des serveurs "difficiles"...
Enfin bref, et au risque d'enclancher une flamme... les Macs semblent mieux armés que les PCs pour le haut débit, dans leurs jus d'origines. En contrepartie, faire des réglages d'optimisation sur Mac semble bien moins commode que sur PC (enfin, avec les Mac OS d'avant X) ...
-- Herm (Pardon pour la longueur)
Grognon et Cie
[...]
Diable, t'en sais des choses ! (c'est pas moqueur, bien au contraire)
Enfin bref, et au risque d'enclancher une flamme... les Macs semblent mieux armés que les PCs pour le haut débit, dans leurs jus d'origines. En contrepartie, faire des réglages d'optimisation sur Mac semble bien moins commode que sur PC (enfin, avec les Mac OS d'avant X) ...
Ne serait-ce pas plutôt que l'OS du Mac est mieux fichu que l'OS répandu sur les PC ? Sinon, que donnerait une comparaison Mac / PC sous linux ? (c'est par curiosité)
-- Grognon et Cie Plus on est de fous, plus on rit
[...]
Diable, t'en sais des choses ! (c'est pas moqueur, bien au contraire)
Enfin bref, et au risque d'enclancher une flamme... les Macs semblent mieux
armés que les PCs pour le haut débit, dans leurs jus d'origines. En
contrepartie, faire des réglages d'optimisation sur Mac semble bien moins
commode que sur PC (enfin, avec les Mac OS d'avant X) ...
Ne serait-ce pas plutôt que l'OS du Mac est mieux fichu que l'OS répandu
sur les PC ? Sinon, que donnerait une comparaison Mac / PC sous linux ?
(c'est par curiosité)
--
Grognon et Cie
Plus on est de fous, plus on rit
Diable, t'en sais des choses ! (c'est pas moqueur, bien au contraire)
Enfin bref, et au risque d'enclancher une flamme... les Macs semblent mieux armés que les PCs pour le haut débit, dans leurs jus d'origines. En contrepartie, faire des réglages d'optimisation sur Mac semble bien moins commode que sur PC (enfin, avec les Mac OS d'avant X) ...
Ne serait-ce pas plutôt que l'OS du Mac est mieux fichu que l'OS répandu sur les PC ? Sinon, que donnerait une comparaison Mac / PC sous linux ? (c'est par curiosité)
-- Grognon et Cie Plus on est de fous, plus on rit
Herm
"Grognon et Cie" a écrit dans le message de news:...
[...]
Diable, t'en sais des choses ! (c'est pas moqueur, bien au contraire)
Merci, mais en fait, je sais ... que je ne sais pas !
La recherche documentaire et les calculs ont été faits au fur et a mesure de la rédaction du message... Au départ, même si je le soupçonnais, je ne savais pas si ces RWIN de base suffisaient dans un cas concret : 512kb/s en ADSL, et s'ils étaient trop petit, de combien étaient-ils éloignés des bonnes valeurs : de peu ou de beaucoup ?
Pour les windows 9x, c'est de très peu. Pour Win XP, c'est juste bon. Ceci explique que certains ne voient pas de différences entre le RWIN de base et un autre un peu plus grand en ADSL 512kb/s.
Pour les Macs, il n'y a pas beaucoup d'information sur les réglages de l'OS... Néamoins, avec un tampon valant le double de celui par défaut sur les PCs, si IP Net tuner dit vrai, c'est clair qu'il y a de la marge !
Ne serait-ce pas plutôt que l'OS du Mac est mieux fichu que l'OS répandu sur les PC ? Sinon, que donnerait une comparaison Mac / PC sous linux ? (c'est par curiosité)
Ces réglages sont des réglages d'OS. Ça ne préjuge en rien de l'architecture materielle/logicielle. Même un PC sous 386, avec carte Ethernet, est capable de soutenir un bon débit ADSL, avec de bons réglages... Enfin, tant qu'il n'y a pas d'accès au disque dur :-) .
Il m'est avis qu'à OS identique, Mac et PC auraient des performances identiques...
Et si c'est Linux (ou Mac OS X !)... Et bien les choses ne sont pas simples ! Cet OS semble capable de gérer des RWIN de tailles variables (!), a l'interieur d'une limite globale de mémoire... http://www.psc.edu/networking/projects/tcptune/ (en anglais)
Impressionnant, côté réseau, le Linux... Mais je crois qu'il a été, pour bonne partie, conçu pour ça :-D !
-- Herm
"Grognon et Cie" a écrit dans le message de news:...
[...]
Diable, t'en sais des choses ! (c'est pas moqueur, bien au contraire)
Merci, mais en fait, je sais ... que je ne sais pas !
La recherche documentaire et les calculs ont été faits au fur et a mesure de
la rédaction du message... Au départ, même si je le soupçonnais, je ne
savais pas si ces RWIN de base suffisaient dans un cas concret : 512kb/s en
ADSL, et s'ils étaient trop petit, de combien étaient-ils éloignés des
bonnes valeurs : de peu ou de beaucoup ?
Pour les windows 9x, c'est de très peu. Pour Win XP, c'est juste bon. Ceci
explique que certains ne voient pas de différences entre le RWIN de base et
un autre un peu plus grand en ADSL 512kb/s.
Pour les Macs, il n'y a pas beaucoup d'information sur les réglages de
l'OS... Néamoins, avec un tampon valant le double de celui par défaut sur
les PCs, si IP Net tuner dit vrai, c'est clair qu'il y a de la marge !
Ne serait-ce pas plutôt que l'OS du Mac est mieux fichu que l'OS répandu
sur les PC ? Sinon, que donnerait une comparaison Mac / PC sous linux ?
(c'est par curiosité)
Ces réglages sont des réglages d'OS. Ça ne préjuge en rien de l'architecture
materielle/logicielle. Même un PC sous 386, avec carte Ethernet, est capable
de soutenir un bon débit ADSL, avec de bons réglages... Enfin, tant qu'il
n'y a pas d'accès au disque dur :-) .
Il m'est avis qu'à OS identique, Mac et PC auraient des performances
identiques...
Et si c'est Linux (ou Mac OS X !)... Et bien les choses ne sont pas simples
! Cet OS semble capable de gérer des RWIN de tailles variables (!), a
l'interieur d'une limite globale de mémoire...
http://www.psc.edu/networking/projects/tcptune/ (en anglais)
Impressionnant, côté réseau, le Linux... Mais je crois qu'il a été, pour
bonne partie, conçu pour ça :-D !
"Grognon et Cie" a écrit dans le message de news:...
[...]
Diable, t'en sais des choses ! (c'est pas moqueur, bien au contraire)
Merci, mais en fait, je sais ... que je ne sais pas !
La recherche documentaire et les calculs ont été faits au fur et a mesure de la rédaction du message... Au départ, même si je le soupçonnais, je ne savais pas si ces RWIN de base suffisaient dans un cas concret : 512kb/s en ADSL, et s'ils étaient trop petit, de combien étaient-ils éloignés des bonnes valeurs : de peu ou de beaucoup ?
Pour les windows 9x, c'est de très peu. Pour Win XP, c'est juste bon. Ceci explique que certains ne voient pas de différences entre le RWIN de base et un autre un peu plus grand en ADSL 512kb/s.
Pour les Macs, il n'y a pas beaucoup d'information sur les réglages de l'OS... Néamoins, avec un tampon valant le double de celui par défaut sur les PCs, si IP Net tuner dit vrai, c'est clair qu'il y a de la marge !
Ne serait-ce pas plutôt que l'OS du Mac est mieux fichu que l'OS répandu sur les PC ? Sinon, que donnerait une comparaison Mac / PC sous linux ? (c'est par curiosité)
Ces réglages sont des réglages d'OS. Ça ne préjuge en rien de l'architecture materielle/logicielle. Même un PC sous 386, avec carte Ethernet, est capable de soutenir un bon débit ADSL, avec de bons réglages... Enfin, tant qu'il n'y a pas d'accès au disque dur :-) .
Il m'est avis qu'à OS identique, Mac et PC auraient des performances identiques...
Et si c'est Linux (ou Mac OS X !)... Et bien les choses ne sont pas simples ! Cet OS semble capable de gérer des RWIN de tailles variables (!), a l'interieur d'une limite globale de mémoire... http://www.psc.edu/networking/projects/tcptune/ (en anglais)
Impressionnant, côté réseau, le Linux... Mais je crois qu'il a été, pour bonne partie, conçu pour ça :-D !
-- Herm
Eric Levenez
Le 7/12/05 16:50, dans <439704c2$0$18579$, « Herm » a écrit :
D'après http://support.microsoft.com/kb/314053/EN-US , pour les windows xp, RWIN est calculé à 8760 octets, 6 paquets, de justesse le minimum.
Sûr.
Quant aux Macs, si j'en crois la doc d'IP Net tuner : http://www.sustworks.com/site/prod_otat_faq.html, le RWIN par défaut d'Open Transport serait aux alentours de 16k (16 384 octets)...
Pour info, Mac OS X n'est pas Mac OS et n'utilise plus Open Transport qui était la couche STREAMS de Mac OS.
Dans tes calculs tu as oublié les problèmes liés aux erreurs TCP, et c'est justement cela qui réduit les débits (comme dans mon cas) si l'on augmente trop la taille des fenêtres TCP.
La pile IPV4 et IPv6 Mac OS X est BSD et utilise sysctl pour son contrôle. Il y a de la doc partout sur Internet sur le sujet et les sources de cette pile sont, de plus, en Open Source.
Sous Mac OS X 10.4, la valeurs des fenêtres TCP en IPv4 en émission et réception est de 32768 par défaut et est adaptée aux accès Ethernet 1 Gb/s des Macs et aux accès 20 Mb/s de l'ADSL2+.
Les modifications dans ce thread, concernant Mac OS X, proposent de passer la fenêtre réception à 131072 et celle de réception à 358400 et sont applicables principalement aux accès FiOS. Je suppose que dans ce cas le RFC 1323 est utilisé pour passer les limites des 65535 des fenêtres TCP classique, mais est-ce que ce RFC est beaucoup appliqué, je ne sais pas.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 7/12/05 16:50, dans <439704c2$0$18579$7a628cd7@news.club-internet.fr>,
« Herm » <a@a.invalid> a écrit :
D'après http://support.microsoft.com/kb/314053/EN-US , pour les windows xp,
RWIN est calculé à 8760 octets, 6 paquets, de justesse le minimum.
Sûr.
Quant aux Macs, si j'en crois la doc d'IP Net tuner :
http://www.sustworks.com/site/prod_otat_faq.html, le RWIN par défaut d'Open
Transport serait aux alentours de 16k (16 384 octets)...
Pour info, Mac OS X n'est pas Mac OS et n'utilise plus Open Transport qui
était la couche STREAMS de Mac OS.
Dans tes calculs tu as oublié les problèmes liés aux erreurs TCP, et c'est
justement cela qui réduit les débits (comme dans mon cas) si l'on augmente
trop la taille des fenêtres TCP.
La pile IPV4 et IPv6 Mac OS X est BSD et utilise sysctl pour son contrôle.
Il y a de la doc partout sur Internet sur le sujet et les sources de cette
pile sont, de plus, en Open Source.
Sous Mac OS X 10.4, la valeurs des fenêtres TCP en IPv4 en émission et
réception est de 32768 par défaut et est adaptée aux accès Ethernet 1 Gb/s
des Macs et aux accès 20 Mb/s de l'ADSL2+.
Les modifications dans ce thread, concernant Mac OS X, proposent de passer
la fenêtre réception à 131072 et celle de réception à 358400 et sont
applicables principalement aux accès FiOS. Je suppose que dans ce cas le RFC
1323 est utilisé pour passer les limites des 65535 des fenêtres TCP
classique, mais est-ce que ce RFC est beaucoup appliqué, je ne sais pas.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 7/12/05 16:50, dans <439704c2$0$18579$, « Herm » a écrit :
D'après http://support.microsoft.com/kb/314053/EN-US , pour les windows xp, RWIN est calculé à 8760 octets, 6 paquets, de justesse le minimum.
Sûr.
Quant aux Macs, si j'en crois la doc d'IP Net tuner : http://www.sustworks.com/site/prod_otat_faq.html, le RWIN par défaut d'Open Transport serait aux alentours de 16k (16 384 octets)...
Pour info, Mac OS X n'est pas Mac OS et n'utilise plus Open Transport qui était la couche STREAMS de Mac OS.
Dans tes calculs tu as oublié les problèmes liés aux erreurs TCP, et c'est justement cela qui réduit les débits (comme dans mon cas) si l'on augmente trop la taille des fenêtres TCP.
La pile IPV4 et IPv6 Mac OS X est BSD et utilise sysctl pour son contrôle. Il y a de la doc partout sur Internet sur le sujet et les sources de cette pile sont, de plus, en Open Source.
Sous Mac OS X 10.4, la valeurs des fenêtres TCP en IPv4 en émission et réception est de 32768 par défaut et est adaptée aux accès Ethernet 1 Gb/s des Macs et aux accès 20 Mb/s de l'ADSL2+.
Les modifications dans ce thread, concernant Mac OS X, proposent de passer la fenêtre réception à 131072 et celle de réception à 358400 et sont applicables principalement aux accès FiOS. Je suppose que dans ce cas le RFC 1323 est utilisé pour passer les limites des 65535 des fenêtres TCP classique, mais est-ce que ce RFC est beaucoup appliqué, je ne sais pas.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
