le LARTC fait des miracles avec notre connexion ADSL

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
18
mar.
2002
Linux
Sur le site du Linux Advanced Routing & Traffic Control est disponible le "wondershaper". Ce script permet de :
- maintenir une bonne réactivité pour le traffic interactif (ssh, telnet..)
- permettre de surfer sans souci lors de gros downloads
- s'assurer que l'upload ne défavorise pas le download et inversement (il est reconnu que l'upload casse le download, cf linux advanced routing howto)
Pour ceux qui se sont intéressés au lartc (linux advanced routing et traffic control), ce "wondershaper" est une aubaine :
- un exemple appliqué pour mieux comprendre le peu de doc dispo sur tc
- un exemple qui fait du bien à nos modem

Aller plus loin

  • # Très intéressant

    Posté par  . Évalué à 10.

    C'est vrai que la doc de tc est un peu légère et que son fonctionnement est imbitable.

    J'avoue avoir abandonné la configuration poussée et ne pas avoir dépassé le :

    tc qdisc replace dev $PPP_IFACE root tbf rate 128kbit latency 50ms burst 1540

    Ce qui a tout de même amélioré grandement ma connexion, puisqu'il devient alors possible de downloader en même temps qu'un upload...

    Par contre, la latence est toujours très haute quand la BP est utilisée (ça passe de 60ms à plus de 600ms quand y a du trafic)

    Le résultats énoncés dans le README du wondershaper sont vraiment enthousiasmant... je vais installer ça le plus tôt possible...

    Baseline latency:
    round-trip min/avg/max = 14.4/17.1/21.7 ms

    Without traffic conditioner, while downloading:
    round-trip min/avg/max = 560.9/573.6/586.4 ms

    Without traffic conditioner, while uploading:
    round-trip min/avg/max = 2041.4/2332.1/2427.6 ms

    With conditioner, during 220kbit/s upload:
    round-trip min/avg/max = 15.7/51.8/79.9 ms

    With conditioner, during 850kbit/s download:
    round-trip min/avg/max = 20.4/46.9/74.0 ms

    • [^] # Re: Très intéressant

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

      " Ce qui a tout de même amélioré grandement ma connexion, puisqu'il devient alors possible de downloader en même temps qu'un upload..."

      J'ai toujours pu faire du download en même temps que de l'upload... ? même sans tc.
      Une amélioration de la disponibilité en charge est cependant très intéressante... Enfin on peut jouer à Quake 3 sur le net, tout en faisaint serveur HTTP sur ADSL ? Alors la ce serait c00l !!

      • [^] # Re: Très intéressant

        Posté par  . Évalué à 10.

        J'ai toujours pu faire du download en même temps que de l'upload... ?

        Tous ceux que je connais et qui ont l'ADSL ont ce même problème : quand la BP en upload est saturée, la BP en download est quasi nulle. C'est d'autant plus vrai que le nombre de connexions en upload est élevé.

        • [^] # Re: Très intéressant

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

          Ce n'est pas specifique a l'adsl, le probleme est la peut importe le type de connection (RTC, cable...)

          Si tu telecharge a 64ko/s, tu verra que tu upload a environ 1,2ko/s (en FTP) correspondant aux "accusés de reception" envoyés en TCP.

          Si ces 1,2ko/s ne sont absolument pas disponible, la vitesse en download sera reduite.

          C'est pour cela que les utilisateurs du satellite (a une epoque) avais quelques probleme pour downloader en temps reel a de grandes vitesses (33600 en upload ne suffisais pas)

          Personellement quand j'upload vers un ftp je bloque la vitesse a 13 ou 14ko/s, ça me permet de telecharger sans reduction de vitesse.

          [moua]

          • [^] # Re: Très intéressant

            Posté par  . Évalué à 10.

            Pour le cas de l'ADSL, il semble que ce soit différent. Il y a une histoire de buffer saturé en plus (c'est ce que j'avais lu dans ma quête de la solution miracle à base de QoS). Sinon, comment expliquer que limiter l'utilisation de la BP à la limite théorique (ce que je fais avec mon tc) suffise à libérer la BP nécessaire aux "accusés de réception" ? (sachant que cette conf ne fait aucune distinction entre les paquets, donc les ACK et autres n'ont pas plus de chance de passer avec la limitation que sans, sauf s'il y a effectivement cette histoire de buffer)

            • [^] # Re: Très intéressant

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

              Juste une question :
              Je possede une connection cablé a 1 200 000 bps en downstream et 128 000 bps en upstream (geré par mon modem, en QoS en plus ;) mais mon pc n'en sait rien)

              Seulement mon FAI propose des chaines en multicast sur le reseau, donc ma bande passante en download est de 1 200 000 bps PLUS chaque chaine multicast (de plus d'1Mbps chaqun) .

              Donc comment faire pour limmiter la bande passante en download sans pour autant me priver du multicast, mais en gerant bien la repartition ?

              Est il possible de mettre un filtre qui ignore les packets multicast du QoS ?

              [moua]

              • [^] # Re: Très intéressant

                Posté par  . Évalué à 6.

                Le QoS que l'on peut appliquer au niveau de l'ordinateur concerne seulement l'upload.
                Il n'est pas possible de controler directement le débit en download.
                On peut décider de la vitesse a laquelle on envoie les paquets, mais on a aucun contrôle sur la vitesse à laquelle les autres ordinateurs nous en envoient, on peut tout au plus ignorer des paquets.

                Le QoS permet seulement de rendre plus prioritaire certains paquets en upload (entre autres les paquets ACK d'acquittement des paquets reçus),ce qui permet d'acquitter plus de paquets donc d'avoir un meilleur débit en download.

          • [^] # Re: Très intéressant

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

            c'est clair que l'adsl a quand même une grosse différence. Quand j'upload à fond je peux encore telecharger à des vitesse largement raisonnable (up 10ko, down 45ko) et d'après ce que j'ai vu, avec l'adsl c'est pas trop ce genre de chiffres...
            (j'ai le cable moi)

  • # Commentaire supprimé

    Posté par  . Évalué à 10.

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

  • # héhé :)

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

    très très bon how to qui existe depuis très très longtemps ;))

    d ailleurs ce how to ne s applique pas seulement à l adsl, mais à tout type de connection (voir multi modem )... Il paraitrait meme qu'il y en a qui font de l accès internet avec ça ...

    (petit hic sur la news portrait : Lawrence Lessig : la privatisation du réseau se précise... Allez, on oublie tout, et on passe à autre chose :)) )
    http://linuxfr.org/2002/03/15/7563,0,0,0,0.php3(...)

    quant au shaper, je vais me lancer dans l exp :()

    @+
    Code34

  • # Dans le même genre

    Posté par  . Évalué à 10.

    J'utilise depuis plusieurs mois le script suivant:

    script: http://www.prout.be/qos/QoS-connection-tuning-HOWTO-6.html(...)
    le howto complet: http://www.prout.be/qos/QoS-connection-tuning-HOWTO.html#toc6(...)

    Et c'est vrai que les resultats sont très interessants. Je m'en sert pour limiter l'utilisation de la bande passante des autres postes a part le mien (bofh), pour limiter l'utilisation de la bande passante par le serveur ftp, et pour m'assurer des pings corrects sur les serveurs quake meme quand j'upload et je downloade.
    Et je dois dire que les résultats sont au rendez vous!

    Ce script présente l'avantage d'etre (a mon avis) bien plus simple a lire et à comprendre, ce qui rend la customisation plus facile. En effet, on marque les packets avec iptables, dont la syntaxe est moins difficile a apprehender & mieux documentee que celle de iproute2 / tc

    Par example pour classer les paquets vers les serveurs q3 dans une classe de haute priorité (qui tournent en general sur le port 27960 et un peu au dessus), il suffit de faire:

    iptables -t mangle -A OUTPUT -o ppp0 -p tcp --dport 27960:27975 -j MARK --set-mark 3

    (bon il est vrai que rien n'empeche de combiner les 2 methodes)


    Il faut aussi signaler que ces 2 scripts se basent sur CBQ (qui est dans le kernel) pour implementer QoS. Il est aussi possible d'utiliser HBT (le futur!) via des patchs mais je n'ai pas encore eu le courage d'essayer

  • # HTB est bien mieux que CBQ

    Posté par  . Évalué à 10.

    Je vous conseille grandement d'utiliser HTB à la place de CBQ comme "queuing discipline".

    Il est bien plus simple à configurer, il consomme moins de ressources, et surtout il n'est pas approximatif quant au calcul du débit.

    En effet, pour calculer le débit utilisé, CBQ nécessite de connaître la taille moyenne des paquets et la vitesse maximale de la connexion. Il utilise ensuite le temps d'inactivité de la connexion pour calculer une approximation du débit utilisé.
    Avec un modem ADSL-ethernet, le débit maximal et le temps d'innactvité est basé sur celui de la carte ethernet. Avec mon modem ADSL USB, j'ai jammais réussi a avaoir un résultat acceptable avec CBQ.

    HTB, lui ne fait aucune approximation, il ne necessite que la débit maximal du modem. le résultat est excellent.

    Pour installer HTB, il faut aller voir sur le site:
    http://luxik.cdi.cz/~devik/qos/htb/(...)

    Il suffit de patcher le noyeau avec:
    http://luxik.cdi.cz/~devik/qos/htb/v2/htb2_2.4.17.diff(...)

    Et de remplacer le programme /sbin/tc par celui là:
    http://luxik.cdi.cz/~devik/qos/htb/v2/tc.gz(...)


    Je vais de ce pas tester le script wshaper.htb :-)

    • [^] # Re: HTB est bien mieux que CBQ

      Posté par  . Évalué à 2.

      Je suis toujours en kernel 2.2 et je n'ai pas compris s'il fallait le 2.4 ou pas (pour le CBQ au moins) ?
      Est-ce que quelqu'un peut me préciser ce qui marche en 2.2 et ce qui a besoin du 2.4 ?

  • # et QoS rien à voir?

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

    Je pensais que QoS permettait de faire sensiblement la meme chose non?

    • [^] # Re: et QoS rien à voir?

      Posté par  . Évalué à -1.

      ce script c'est justement du QoS

    • [^] # Re: et QoS rien à voir?

      Posté par  . Évalué à -6.

      Paneau de configuration -> Connexions réseau -> <ta_connexion> -> Propriétés -> Ajouter -> Service -> Planificateur de Packets QoS


      -1 parce que non la franchement ..

  • # Vous me copierez dix fois

    Posté par  . Évalué à 4.

    La traduction du mot anglais traffic est trafic.
    La traduction du mot anglais traffic est trafic.
    La traduction du mot anglais traffic est trafic.
    La traduction du mot anglais traffic est trafic.
    La traduction du mot anglais traffic est trafic.
    La traduction du mot anglais traffic est trafic.
    La traduction du mot anglais traffic est trafic.
    La traduction du mot anglais traffic est trafic.
    La traduction du mot anglais traffic est trafic.
    La traduction du mot anglais traffic est trafic.

    Après, vous passerez au mot galerie.

    Ceci était un commentaire à but rebarbato-éducatif, donc logiquement scoré -1.

    • [^] # Re: Vous me copierez dix fois

      Posté par  . Évalué à 2.

      Je serais toi je dirais demanderais au gens de copier 1000 fois :
      "La traduction du mot anglais connection est connexion"

  • # Du feu de dieu ce tuning

    Posté par  . Évalué à 1.

    Les résultats obtenus sont simplement incroyables : download moyen à 62 Ko/s et upload à 15 Ko/s ! :) Alors que sans je fais du download à 30~40 Ko/s avec un upload à 16~17 Ko/s.

    À essayer d'urgence.

    PS : Personnelement, je ne limite que la bande passante en upload à 110 Kbits/s

Suivre le flux des commentaires

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