Journal ADSL: du 2048 Kbits en non-degroupé, question

Posté par  .
Étiquettes : aucune
0
19
mai
2004
Vu sur clubic via cette news http://www.clubic.com/n/n12711.html.(...)

Apparement ca sera du 2048/128 d'ou une tit question pour ceux qui ont déjà du 2048.

Il me semble, mais la mes cours de réseaux sont loin, qu'on emmet globalement 10% de ce que l'on recoit (TCP/IP donc mode connecté, je ne parle pas pour du streaming UDP).

Donc trés globalement, si on download (tcp/ip connecté) a 1024 full , on emmet globalement a 128 full , les 128 représentant les 10% cités plus haut.

Qu'en est t il du 2048 ? est ce que cela suffisant pour faire du 2048 full (sachant que dans ce cas , c'est plutot 256 qui representerai 10%).

Est ce que je me gourre completement ?

Help.

  • # Euh...

    Posté par  . Évalué à 0.

    il me semble que cela n'a rien à voir avec la vitesse non ? Tu émets en volume 10% de ce que tu as reçu indépendemment du fait que tu as reçu en 512 kbps ou 1024.

    Me trompe-je ?

    • [^] # Re: Euh...

      Posté par  . Évalué à 4.

      oui mais une vitesse, ca n'est rien d'autre qu'un volume par unité de temps :
      si tu reçois 200ko en 1 seconde, tu devrait en renvoyer ~ 10% (i.e. 20ko) en à peu près 1 seconde. Et comme tu ne download géneralement pas que pendant une seconde, tu ne peux pas dire 'tant pis! j'uploaderai plus tard'.
      Les 3/4 du temps, il faut d'abord confirmer que tu as bien reçu un paquet pour que l'expediteur t'envoie le prochain. Si tu ne peux pas confirmer (=uploader) suffisement vite, l'expedireur ne pourras pas saturer ta bande passante en download.

      En me relisant, je suis pas sûr d'avoir été très clair...

      • [^] # Re: Euh...

        Posté par  . Évalué à 2.

        Je ne suis pas aussi sure que toi, si g compris ce que tu dis, parceque pour ce qui es de la connection via satellite, celle-ci est groupée avec une connection sur une ligne rtc standard et pourtant le sat n'est pas limité a 16ko en reception...

        • [^] # Re: Euh...

          Posté par  (site web personnel) . Évalué à 0.

          Ca j'ai sur un site j'sé plus lequel:
          ils magouillent la pile IP pour qu'il y ai plus le retour udp........
          tres propre

      • [^] # Re: Euh...

        Posté par  . Évalué à 1.

        Ba oué, le TCP/IP signifi Transfert Controle Protocol / Internet Protocol. en fait tu valide chacun des des paquets que tu reçois avec la clef incluse. Alors si tu ne valide pas les paquets, cela signifi que tu ne les as pas bien reçu, le serveur decide donc de les renvoyer.
        Ainsi, tu penses faire du gros débit mais tu balance 10, 20 voir 30% des paquet que tu reçois.

        • [^] # Re: Euh...

          Posté par  (site web personnel) . Évalué à 1.

          C'est clair que TCP/IP est très parano sur les accusé de récéption, c'est un defaut de ce protocole. Du coup, les erreurs avec ce protocole sont sensé etre 'rare'

          • [^] # Re: Euh...

            Posté par  . Évalué à 0.

            C'est clair que TCP/IP est très parano sur les accusé de récéption, c'est un defaut de ce protocole.

            Ce n'est pas un "défaut", si on ne veut pas controlé l'aquittement, on utilise UDP

    • [^] # Re: Euh...

      Posté par  . Évalué à 4.

      En fait cela dépend fortement du protocole du haut niveau que tu utilises, par ex. un download en http utilise environ 2.5% de la bande passant en upload. Dans ce cas (2048/128), c'est donc parfaitement utilisable.

      • [^] # Re: Euh...

        Posté par  (site web personnel) . Évalué à 4.

        Tu es sûr de ça ?

        Si je télécharge un fichier en HTTP, ce n'est pas HTTP qui décide des ACK à envoyer. Ca se passe à un niveau en dessous (TCP).

        A mon avis c'est plutôt une histoire de fenêtre de réception (RWIN). C'est à un paramèter à régler : plus elle est grande, plus on reçoit de données entrantes avant d'envoyer un ACK.

        Notons cependant que le client n'est pas le seul à imposer une taille de fenêtre, le serveur peut décider de la diminuer ou de l'augmenter au besoin.

        Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

    • [^] # Re: Euh...

      Posté par  (site web personnel) . Évalué à 1.

      Le protocole UDP et le Streaming ne nécessite pas de ACK (confirmation de réception) donc pour ces protocoles là, c'est pas trop grave d'avoir que 128... pour les autres... c'est sûr, ça limite :-(

  • # Ca doit passer

    Posté par  (site web personnel) . Évalué à 5.

    On emmet effectivement un certain %, mais tes 10% me paraissent plutot élevé. Il faut voir que ca dépend de pas mal de choses en fait.
    Ce 10% doit plutot correspondre a l'utilisation qui en est fait d'une manière général pour un utilisateur lambda, mais pas juste une "mesure" d'un flux TCP constant (style un download d'un gros fichier en FTP/http)
    Après, un truc assez bavard genre p2p aurra probablement un peu plus de mal.

  • # re

    Posté par  (site web personnel) . Évalué à 0.

    Les offres 2048 sont basé toujours en 128 en upload, car rien que de passer en 256 d'upload ca doublerai les tarif assez méchamment.

    L'upload ca coute cher, la ligne 1024/256 chez France Telecom est Extense+ pour 69 € par mois contre 49 pour le 1024/128.


    Bien sur je parle en zone non dégroupée.

    • [^] # Re: re

      Posté par  . Évalué à 4.

      je ne vois pas ce qui peut couter plus cher dans l'upload que dans le download. Certes il s'agit d'une liaison Adsl (le A c'est assymétrique) ; mais derriere le DSLAM le tout se transforme en traffic IP. Sur internet on ne retrouve que du traffic IP. Et jusqu'a preuve du contraire, les FAI ont des connexions Internet completement symétriques.

      Si les tarifs sont élevés, c'est surment pour une pure raison commerciale ou eventuellement d'ethique : on veut brider les ordinateurs finaux en terme de service internet, en particulier le p2p.

      Concernant les questions de Sylvain, visiblement, les 10% de traffic réseau seraient dus, si j'ai bien compris aux couches réseau et en particulier a TCP/IP. Effectivement ce protocole est un protocole avec acquitements et controle de flux. Il y a forcement un petit overhead.

      • [^] # Re: re

        Posté par  . Évalué à 3.

        je ne vois pas ce qui peut couter plus cher dans l'upload que dans le download.

        Le transit que les operateurs télécoms facturent aux FAI se base sur l'upload. Le download est 'gratuit'.

        C'est la version brève.

    • [^] # Re: re

      Posté par  . Évalué à 1.

      tele2 est en 1024/256 chez moi...
      Bon, par contre j'ai jamais rien compris à savoir si j'étais dégroupée chez eux ou pas :)

    • [^] # Re: re

      Posté par  . Évalué à 2.

      http://www.nerim.net/index.php3?file=faq.php3#14(...)

      "Pourquoi ne faîtes-vous pas de l'accès 1024/128, moins cher que le pack Nerim Pro ?
      Pour Nerim, un accès haut débit d'1 Mbits doit nécessairement comporter au moins 256 Kbps dans la voie remontante, car sinon cela bride la connexion et l'on ne profite pas entièrement du débit offert."
      Ceci dit, il faut y mettre le prix chez eux aussi (une soixantaine d'euros/mois je crois)

      Bon, étant chez free en non-dégroupé (1024/128) je peux constater que ça passe quand même, mais il est vrai que lorsqu'on utilise toute la bande passante en réception il devient nettement plus long/difficile d'émettre.
      Alors en 2Mbps, j'ai quelques doutes sur la capacité à en profiter; en plus pour les jeux en réseau l'augmentation du débit remontant diminue le ping.

    • [^] # Re: re

      Posté par  (site web personnel) . Évalué à 6.

      L'upload ca coute cher

      Bon il faut arrêter avec ça. Si c'était pas totalement faux il y a quelques années, c'est aujourd'hui hors de propos.

      Les opérateurs qui dégroupent proposent bien du 2048/256 (LDCOM), du 4700/320 (Free) pour le même prix que ce que va proposer Wanadoo.

      Faut pas exagérer quand même, on parle juste de 128kbit/s en plus. Pas de 1 ou 2 Mbit/s...


      Non, la vraie raison est marketing : ça permet de maintenir l'offre "pro" (mouhahahah) 1024/256 à un prix totalement délirant. Et tant que les entreprises payent, FT est pas prête de se passer de cette manne généreuse.


      Notons aussi qu'une grosse part des internautes ne savent pas ce qu'est le débit remontant (ni son importance). Toutes les campagnes de pub se font sur le débit descendant.

      Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

  • # ack priority

    Posté par  . Évalué à 2.

    Su les graphs suivant, on voit que pour un download à 435kb/s on utilise grosso modo 20kb/s en upload. Le calcul vite fait me dit que le 2048 devrait passer dans le 128.

    http://www.benzedrine.cx/ackpri.html(...)

  • # Des chiffres

    Posté par  (site web personnel) . Évalué à 7.

    C'est assez marrant que tout le monde y aille de son commentaire sans même chercher à trouver l'information en question... Essayons.

    Théorie

    Il semble que la taille max d'un paquet IP soit 65,535 octets et la taille d'un simple ACK TCP soit de 40 octets.

    http://www.rhyshaden.com/ipdgram.htm(...)
    http://www.erg.abdn.ac.uk/users/gorry/course/inet-pages/packet-deco(...)

    Ce qui donnerait un pourcentage de 0,06%.

    Il faut aussi savoir que dans le protocole TCP, il n'est pas indispensable d'envoyer un ACK pour chaque paquet entrant. Si on reçoit un deuxième paquet avant d'avoir envoyé le ACK du premier, on peut envoyer le ACK du deuxième seulement, on est sûr d'être bon car chaque paquet contient un numéro de séquence.

    Pratique

    En pratique, j'ai un petit serveur TCP/IP programmé en C qui ne fait que bloquer sur recv, à qui j'envoie (localement) 200 Ko par un wget --post-file. En utilisant tcpdump sur l'interface lo je vois que le client envoie des paquets qui font 8244 octets souvent, 16436 parfois, les ACK du serveur font eux 52 octets et il en transmet pour environ 70% des paquets.

    En moyenne haute, pourcentage de 0,5%.

    Comme je suppute que la fenêtre de transmission max soit moins élevée dans le cas d'une connexion distante, j'essaie de regarder sur un simple wget sur un site distant, à travers une ligne DSL 512/512 : j'obtiens 1500 octets dans un sens pour 52 octets dans l'autre.

    Ça donne 3,4%.

    On est encore loin des 10% annoncés, même si on s'en rapproche. Par contre, on peut se demander si avec une meilleure ligne, la fenêtre n'a pas tendance à augmenter au-delà de 1500 octets, et autoriser donc un 2048/128 sans soucis.

    Un dernier point : ça m'étonnerait que les providers soient suffisamment débiles pour offrir du 2048/128 qui soit théoriquement jamais atteignable. Enfin, sauf peut-être en UDP, et il paraît que les jeux en réseau l'utilisent pour la performance, d'ailleurs.

    • [^] # Re: Des chiffres

      Posté par  . Évalué à 2.

      Le providers pourraient proposer ce genre d'offre pour de la TV , ou de la telephonie par exemple. Sachant qu'in s'agit alors la de streaming udp avec beaucoup moins (voire pas du tout) de retransmission. Donc, la meme du 10 Mbits / 128Kbits passerait.

      Sinon, d'aprés ta demonstration ca passe effectivement, c'est moi qui me suis vautré avec mes 10%. J'ai du confondre avec autre chose.

    • [^] # Re: Des chiffres

      Posté par  . Évalué à 1.



      Un dernier point : ça m'étonnerait que les providers soient suffisamment débiles pour offrir du 2048/128 qui soit théoriquement jamais atteignable.

      pour certains , ca fait toujours du bien de cracher sur FT , c est pas nouveau ...

  • # Commentaire supprimé

    Posté par  . Évalué à 1.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # exemple

    Posté par  . Évalué à 2.

    prenons MTU de 1500
    fenetre de 1
    taille du ack 60 octets

    download à 256ko/s = 256*1024/1500 = 174.8 pkt/s
    en upload dans les conditions de cet exemple: 174.8*60/1024 = 10.2 ko/s
    reste un tout petit peu de place pour ceux qui veulent uploader :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.