(Courriels de diversion: <chomerai@rentrerions-reintroduisons.com> <interviewais@arrêtera-fonctionnaliser.com> <fideliserez@aggravaient-opportunite.com> <jetable@eclore-envenimeraient.com> <subordonnais@liquideriez-abandonner.com> <consistiez@departagez-rectorales.com> <termines@divisionnaire-impressionne.com> <colla@pronait-attenuees.com> <subodorerions@indiquez-internationalisez.com> <javelliser@estival-recuperiez.com> )


>>>>> "sj" == Sebastien Josset <Sebastien.Josset@space.alcatel.fr> writes:
  sj> Dans le cadre du projet européen IST-Brahms (Internet haut débit
  sj> par satellite), nous avons procédé la semaine dernière à une
  sj> série de mesure de performances de liaisons TCP (via des
  sj> download ftp), dont le résultat, plutôt bluffant, est assez
  sj> interressant.

débit = taille fenêtre / RTT

RTT = Round Trip Time, le temps d'un aller retour, qui est élevé pour
les liens satellite. La fenêtre maximale normalement permise par TCP
est de 64kB, ce qui limite mécaniquement le débit maximal d'un lien.
RFC1323 "TCP Window Scaling" spécifie un mécanisme permettant
d'utiliser des fenêtres plus grandes, si l'émetteur et le recepteur le
supportent. C'est le cas par défaut de la pile TCP de Linux, mais
d'autres OS doivent être configurés manuellement pour activer le
support, et d'autres nécessitent des patchs. Voir

   <URL:http://www.psc.edu/networking/perf_tune.html>

Il y a d'autres facteurs qui rentrent en compte pour déterminer le
débit effectif: par exemple, les liens satellite ont généralement plus
de bruit que les liens ethernet, donc plus de paquets sont perdus.
Avec du TCP «classique», si plus d'un paquet est perdu par fenêtre, il
faut retransmettre tous les paquets de la fenêtre (ou alors attendre
assez longtemps avant de recevoir les ACKs). RFC2018 introduit le
SACK, pour aquittement séléctif, qui permet d'éviter ce problème.
Évidemment, il faut que les deux machines supportent cet option (ce
qui est le cas par défaut pour Linux, mais pas pour toutes les piles
IP). Ca peut expliquer les mauvaises perfs de HPUX, qui devraient être
améliorable en modifiant des options. 

Au fait, RFC2488 parle précisement de la performance de TCP sur les
liens satellites, donc pourrait être intéressant à lire.


   <URL:http://rfc.net/rfc1323.html>
   <URL:http://rfc.net/rfc2018.html>
   <URL:http://rfc.net/rfc2488.html>


J'appuie le commentaire de Laurent: il ne faudrait pas se limiter au
protocole FTP pour des mesures de perf, puisque d'autres protocoles
peuvent avoir des caractéristiques différents. Il existe plusieurs
outils de génération de traffic, programmables, par exemple NetSpec

   <URL:http://www.ittc.ku.edu/netspec/>

-- 
Eric Marsden                          <URL:http://www.laas.fr/~emarsden/>

---------------------------------------------------------------------
Aide sur la liste: <URL:mailto:linux-31-help@CULTe.org>Le CULTe sur le web: <URL:http://www.CULTe.org/>