Bonour, comment fonctionne l'internet par Satellite ?
faut-il avoir une ligne de tph analogique ouverte comme voie de retour et
donc passer par un FAI analogique et le payer en plus du provider SAT ?
dites-moi ...
ça c'est ben vrai Jacques....j'ai testé le pb avec du VSAT et il fallait modifier les bases de registre des NT pour améliorer les perfs... car TCP interprète la latence comme de la congestion et ralentit comme un grand tout seul....et se relance doucement suivant l'algo du ....j'ai oublié tiens... slow start non ?
JM
"Jacques Caron" a écrit dans le message de news:
Salut,
On Mon, 24 May 2004 13:46:32 +0200, Patrick_91 wrote:
Non pas sous tcp/ip (internet Protocoles) le debit ne sera pas impacte par la latence puisque la taille ou le nombre de packets qui seront envoyes sans attendre d'ack seront ajustes automatiquement, ca ca fonctionne tres
bien,
Dans le cas de TCP, le nombre de paquets envoyés sans ack est limité par la taille de la fenête. Or, la plupart des implémentations ont des tailles de fenêtre assez petites, et sont assez sévèrement impactées par une latence importante. Un lien satellite bi-directionnel (donc une latence d'environ 500 ms pour un aller-retour), même s'il offre un débit total de plusieurs Mbit/s, limitera chaque connexion TCP à quelques dizaines de Ko/s, en fonction de la taille des fenêtres.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
ça c'est ben vrai Jacques....j'ai testé le pb avec du VSAT et il fallait
modifier les bases de registre des NT pour améliorer les perfs...
car TCP interprète la latence comme de la congestion et ralentit comme un
grand tout seul....et se relance doucement suivant l'algo du ....j'ai oublié
tiens...
slow start non ?
JM
"Jacques Caron" <jc@imfeurope.com> a écrit dans le message de news:
opr8h6xooiq1hokb@news.free.fr...
Salut,
On Mon, 24 May 2004 13:46:32 +0200, Patrick_91 <patrick_91@nospam.com>
wrote:
Non pas sous tcp/ip (internet Protocoles) le debit ne sera pas impacte
par la latence puisque la taille ou le nombre de packets qui seront
envoyes
sans attendre d'ack seront ajustes automatiquement, ca ca fonctionne
tres
bien,
Dans le cas de TCP, le nombre de paquets envoyés sans ack est limité par
la taille de la fenête. Or, la plupart des implémentations ont des tailles
de fenêtre assez petites, et sont assez sévèrement impactées par une
latence importante. Un lien satellite bi-directionnel (donc une latence
d'environ 500 ms pour un aller-retour), même s'il offre un débit total de
plusieurs Mbit/s, limitera chaque connexion TCP à quelques dizaines de
Ko/s, en fonction de la taille des fenêtres.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
ça c'est ben vrai Jacques....j'ai testé le pb avec du VSAT et il fallait modifier les bases de registre des NT pour améliorer les perfs... car TCP interprète la latence comme de la congestion et ralentit comme un grand tout seul....et se relance doucement suivant l'algo du ....j'ai oublié tiens... slow start non ?
JM
"Jacques Caron" a écrit dans le message de news:
Salut,
On Mon, 24 May 2004 13:46:32 +0200, Patrick_91 wrote:
Non pas sous tcp/ip (internet Protocoles) le debit ne sera pas impacte par la latence puisque la taille ou le nombre de packets qui seront envoyes sans attendre d'ack seront ajustes automatiquement, ca ca fonctionne tres
bien,
Dans le cas de TCP, le nombre de paquets envoyés sans ack est limité par la taille de la fenête. Or, la plupart des implémentations ont des tailles de fenêtre assez petites, et sont assez sévèrement impactées par une latence importante. Un lien satellite bi-directionnel (donc une latence d'environ 500 ms pour un aller-retour), même s'il offre un débit total de plusieurs Mbit/s, limitera chaque connexion TCP à quelques dizaines de Ko/s, en fonction de la taille des fenêtres.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Patrick_91
j3CubL4H wrote:
ça c'est ben vrai Jacques....j'ai testé le pb avec du VSAT et il fallait modifier les bases de registre des NT pour améliorer les perfs... car TCP interprète la latence comme de la congestion et ralentit comme un grand tout seul....et se relance doucement suivant l'algo du ....j'ai oublié tiens... slow start non ?
JM
"Jacques Caron" a écrit dans le message de news:
Salut,
On Mon, 24 May 2004 13:46:32 +0200, Patrick_91 wrote:
Non pas sous tcp/ip (internet Protocoles) le debit ne sera pas impacte par la latence puisque la taille ou le nombre de packets qui seront envoyes sans attendre d'ack seront ajustes automatiquement, ca ca fonctionne tres
bien,
Dans le cas de TCP, le nombre de paquets envoyés sans ack est limité par la taille de la fenête. Or, la plupart des implémentations ont des tailles de fenêtre assez petites, et sont assez sévèrement impactées par une latence importante. Un lien satellite bi-directionnel (donc une latence d'environ 500 ms pour un aller-retour), même s'il offre un débit total de plusieurs Mbit/s, limitera chaque connexion TCP à quelques dizaines de Ko/s, en fonction de la taille des fenêtres.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/ Oui c'est constate avec pas mal d'implementations tcp/ip , les timers de
retransmission (backoff) sont parfois arbitrairement brides a une valeur max inferieure a ce qu'il faut quand on rencontre un circuit 'long' ... Dans ce cas c'est dramatique en effet , ca bourre et ca casse au bout de "n retransmissions (un autre parametre important "retries" ) .... Normalement ceci ne devrait pas se produire, l'augmentation ou diminution de timers devant etre exponentielle , le nombre de packet pouvant etre envoyes sans attendre d'ack devant egalement s'ajuster automatiquement etc etc .... un timer de retransmission (retrans en cas de perte d'ack ) peut parfaitement atteindre 1 a 2 secondes , ca n'impacte pas les perfs, en revanche si les packets se perdent c'est la qu'il faut diminuer les fenetres tailles de packets etc ... encore une fois une grosse partie de tout ceci est en principe automatise ... En communication radio (voir wifi utilise a la marge .. ) il faut un mecanisme de gestion des retransmissions irreprochable et c'est a ca qu'on peut faire la difference entre les implementations tcp/ip .... A plus
j3CubL4H wrote:
ça c'est ben vrai Jacques....j'ai testé le pb avec du VSAT et il fallait
modifier les bases de registre des NT pour améliorer les perfs...
car TCP interprète la latence comme de la congestion et ralentit comme un
grand tout seul....et se relance doucement suivant l'algo du ....j'ai
oublié tiens...
slow start non ?
JM
"Jacques Caron" <jc@imfeurope.com> a écrit dans le message de news:
opr8h6xooiq1hokb@news.free.fr...
Salut,
On Mon, 24 May 2004 13:46:32 +0200, Patrick_91 <patrick_91@nospam.com>
wrote:
Non pas sous tcp/ip (internet Protocoles) le debit ne sera pas impacte
par la latence puisque la taille ou le nombre de packets qui seront
envoyes
sans attendre d'ack seront ajustes automatiquement, ca ca fonctionne
tres
bien,
Dans le cas de TCP, le nombre de paquets envoyés sans ack est limité par
la taille de la fenête. Or, la plupart des implémentations ont des
tailles de fenêtre assez petites, et sont assez sévèrement impactées par
une latence importante. Un lien satellite bi-directionnel (donc une
latence d'environ 500 ms pour un aller-retour), même s'il offre un débit
total de plusieurs Mbit/s, limitera chaque connexion TCP à quelques
dizaines de Ko/s, en fonction de la taille des fenêtres.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Oui c'est constate avec pas mal d'implementations tcp/ip , les timers de
retransmission (backoff) sont parfois arbitrairement brides a une valeur
max inferieure a ce qu'il faut quand on rencontre un circuit 'long' ...
Dans ce cas c'est dramatique en effet , ca bourre et ca casse au bout de "n
retransmissions (un autre parametre important "retries" ) ....
Normalement ceci ne devrait pas se produire, l'augmentation ou diminution de
timers devant etre exponentielle , le nombre de packet pouvant etre envoyes
sans attendre d'ack devant egalement s'ajuster automatiquement etc
etc .... un timer de retransmission (retrans en cas de perte d'ack ) peut
parfaitement atteindre 1 a 2 secondes , ca n'impacte pas les perfs, en
revanche si les packets se perdent c'est la qu'il faut diminuer les
fenetres tailles de packets etc ... encore une fois une grosse partie de
tout ceci est en principe automatise ...
En communication radio (voir wifi utilise a la marge .. ) il faut un
mecanisme de gestion des retransmissions irreprochable et c'est a ca qu'on
peut faire la difference entre les implementations tcp/ip ....
A plus
ça c'est ben vrai Jacques....j'ai testé le pb avec du VSAT et il fallait modifier les bases de registre des NT pour améliorer les perfs... car TCP interprète la latence comme de la congestion et ralentit comme un grand tout seul....et se relance doucement suivant l'algo du ....j'ai oublié tiens... slow start non ?
JM
"Jacques Caron" a écrit dans le message de news:
Salut,
On Mon, 24 May 2004 13:46:32 +0200, Patrick_91 wrote:
Non pas sous tcp/ip (internet Protocoles) le debit ne sera pas impacte par la latence puisque la taille ou le nombre de packets qui seront envoyes sans attendre d'ack seront ajustes automatiquement, ca ca fonctionne tres
bien,
Dans le cas de TCP, le nombre de paquets envoyés sans ack est limité par la taille de la fenête. Or, la plupart des implémentations ont des tailles de fenêtre assez petites, et sont assez sévèrement impactées par une latence importante. Un lien satellite bi-directionnel (donc une latence d'environ 500 ms pour un aller-retour), même s'il offre un débit total de plusieurs Mbit/s, limitera chaque connexion TCP à quelques dizaines de Ko/s, en fonction de la taille des fenêtres.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/ Oui c'est constate avec pas mal d'implementations tcp/ip , les timers de
retransmission (backoff) sont parfois arbitrairement brides a une valeur max inferieure a ce qu'il faut quand on rencontre un circuit 'long' ... Dans ce cas c'est dramatique en effet , ca bourre et ca casse au bout de "n retransmissions (un autre parametre important "retries" ) .... Normalement ceci ne devrait pas se produire, l'augmentation ou diminution de timers devant etre exponentielle , le nombre de packet pouvant etre envoyes sans attendre d'ack devant egalement s'ajuster automatiquement etc etc .... un timer de retransmission (retrans en cas de perte d'ack ) peut parfaitement atteindre 1 a 2 secondes , ca n'impacte pas les perfs, en revanche si les packets se perdent c'est la qu'il faut diminuer les fenetres tailles de packets etc ... encore une fois une grosse partie de tout ceci est en principe automatise ... En communication radio (voir wifi utilise a la marge .. ) il faut un mecanisme de gestion des retransmissions irreprochable et c'est a ca qu'on peut faire la difference entre les implementations tcp/ip .... A plus
Fabrice..Bacchella
On Mon, 24 May 2004 14:55:15 +0200, "j3CubL4H" wrote:
ça c'est ben vrai Jacques....j'ai testé le pb avec du VSAT et il fallait modifier les bases de registre des NT pour améliorer les perfs... car TCP interprète la latence comme de la congestion et ralentit comme un grand tout seul....et se relance doucement suivant l'algo du ....j'ai oublié tiens... slow start non ?
Le problème est decrit dans la RFC 1323, c'est le long, fat pipe : ftp://ftp.rfc-editor.org/in-notes/rfc1323.txt --- http://fba.homeip.net
On Mon, 24 May 2004 14:55:15 +0200, "j3CubL4H" <toto@toto.fr> wrote:
ça c'est ben vrai Jacques....j'ai testé le pb avec du VSAT et il fallait
modifier les bases de registre des NT pour améliorer les perfs...
car TCP interprète la latence comme de la congestion et ralentit comme un
grand tout seul....et se relance doucement suivant l'algo du ....j'ai oublié
tiens...
slow start non ?
Le problème est decrit dans la RFC 1323, c'est le long, fat pipe :
ftp://ftp.rfc-editor.org/in-notes/rfc1323.txt
---
http://fba.homeip.net
On Mon, 24 May 2004 14:55:15 +0200, "j3CubL4H" wrote:
ça c'est ben vrai Jacques....j'ai testé le pb avec du VSAT et il fallait modifier les bases de registre des NT pour améliorer les perfs... car TCP interprète la latence comme de la congestion et ralentit comme un grand tout seul....et se relance doucement suivant l'algo du ....j'ai oublié tiens... slow start non ?
Le problème est decrit dans la RFC 1323, c'est le long, fat pipe : ftp://ftp.rfc-editor.org/in-notes/rfc1323.txt --- http://fba.homeip.net
Patrick_91
Fabrice..Bacchella wrote:
On Mon, 24 May 2004 14:55:15 +0200, "j3CubL4H" wrote:
Le problème est decrit dans la RFC 1323, c'est le long, fat pipe : ftp://ftp.rfc-editor.org/in-notes/rfc1323.txt --- http://fba.homeip.net
Le papier ci dessus est excellent 'rfc1323' , juste un truc :
car TCP interprète la latence comme de la congestion et ralentit comme un grand tout seul....et se relance doucement suivant l'algo du ....j'ai oublié tiens...
En réalite tcp ne "ralentit " pas , comment ferait il ?? , non la latence peut etre confondue parfois avec une perte de datagram .. la oui , dans ce cas il y a re emission du datagram , mais l'ack en retard finira par parvenir a l'emetteur et le timer de retransmission sera double pour eviter ca la prochaine foi. De toute facon le rtt ou round trip time est mesure en permanence (ainsi que les variations sous forme d'ecart type) de facon a ce que les timers de retransmission s'ajustent à la bonne valeur le plus vite possible. Si c'est de la congestion, normalement des messages tupe : "source quench " doivent etre recus par l'emetteur, qui doit en tenir compte .
ça c'est ben vrai Jacques....j'ai testé le pb avec du VSAT et il fallait modifier les bases de registre des NT pour améliorer les perfs... Oui des implementations tcp/ip plus ou moins completes ou rigoureuses .. au
debut de la pile tcp/ip de win95 c'etait une catastrophe, une vrai nuisance pour un reseau local ...(puis c'est rentre dans l'odre au fil des revisions.. ) .. en regardant bien on a eu plus de problemes d'implementation que de soucils lies a la structure ou aux fondements des protocoles tcp et ip.
Amicalement
Fabrice..Bacchella wrote:
On Mon, 24 May 2004 14:55:15 +0200, "j3CubL4H" <toto@toto.fr> wrote:
Le problème est decrit dans la RFC 1323, c'est le long, fat pipe :
ftp://ftp.rfc-editor.org/in-notes/rfc1323.txt
---
http://fba.homeip.net
Le papier ci dessus est excellent 'rfc1323' , juste un truc :
car TCP interprète la latence comme de la congestion et ralentit comme un
grand tout seul....et se relance doucement suivant l'algo du ....j'ai
oublié tiens...
En réalite tcp ne "ralentit " pas , comment ferait il ?? , non la latence
peut etre confondue parfois avec une perte de datagram .. la oui , dans ce
cas il y a re emission du datagram , mais l'ack en retard finira par
parvenir a l'emetteur et le timer de retransmission sera double pour eviter
ca la prochaine foi. De toute facon le rtt ou round trip time est mesure en
permanence (ainsi que les variations sous forme d'ecart type) de facon a ce
que les timers de retransmission s'ajustent à la bonne valeur le plus vite
possible.
Si c'est de la congestion, normalement des messages tupe : "source quench "
doivent etre recus par l'emetteur, qui doit en tenir compte .
ça c'est ben vrai Jacques....j'ai testé le pb avec du VSAT et il fallait
modifier les bases de registre des NT pour améliorer les perfs...
Oui des implementations tcp/ip plus ou moins completes ou rigoureuses .. au
debut de la pile tcp/ip de win95 c'etait une catastrophe, une vrai nuisance
pour un reseau local ...(puis c'est rentre dans l'odre au fil des
revisions.. ) .. en regardant bien on a eu plus de problemes
d'implementation que de soucils lies a la structure ou aux fondements des
protocoles tcp et ip.
On Mon, 24 May 2004 14:55:15 +0200, "j3CubL4H" wrote:
Le problème est decrit dans la RFC 1323, c'est le long, fat pipe : ftp://ftp.rfc-editor.org/in-notes/rfc1323.txt --- http://fba.homeip.net
Le papier ci dessus est excellent 'rfc1323' , juste un truc :
car TCP interprète la latence comme de la congestion et ralentit comme un grand tout seul....et se relance doucement suivant l'algo du ....j'ai oublié tiens...
En réalite tcp ne "ralentit " pas , comment ferait il ?? , non la latence peut etre confondue parfois avec une perte de datagram .. la oui , dans ce cas il y a re emission du datagram , mais l'ack en retard finira par parvenir a l'emetteur et le timer de retransmission sera double pour eviter ca la prochaine foi. De toute facon le rtt ou round trip time est mesure en permanence (ainsi que les variations sous forme d'ecart type) de facon a ce que les timers de retransmission s'ajustent à la bonne valeur le plus vite possible. Si c'est de la congestion, normalement des messages tupe : "source quench " doivent etre recus par l'emetteur, qui doit en tenir compte .
ça c'est ben vrai Jacques....j'ai testé le pb avec du VSAT et il fallait modifier les bases de registre des NT pour améliorer les perfs... Oui des implementations tcp/ip plus ou moins completes ou rigoureuses .. au
debut de la pile tcp/ip de win95 c'etait une catastrophe, une vrai nuisance pour un reseau local ...(puis c'est rentre dans l'odre au fil des revisions.. ) .. en regardant bien on a eu plus de problemes d'implementation que de soucils lies a la structure ou aux fondements des protocoles tcp et ip.
Amicalement
Jacques Caron
On Tue, 25 May 2004 09:17:25 +0200, Patrick_91 wrote:
En réalite tcp ne "ralentit " pas , comment ferait il ??
En réduisant la taille de la fenêtre...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On Tue, 25 May 2004 09:17:25 +0200, Patrick_91 <patrick_91@nospam.com>
wrote:
En réalite tcp ne "ralentit " pas , comment ferait il ??
En réduisant la taille de la fenêtre...
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
