Le Wednesday 28 December 2011 13:43:29, Pierre Jaury a écrit : > En vérité j'ai probablement lu de travers : où appliquez-vous la QOS ? > l'algorithme et les paramètres sont également importants dans ce genre > de cas (a fortiori sur de faibles débits très variables). Les filtres à > base de bucket entre autres, lorsque mal configurés, ont une tendance > malsaine à écraser la fenêtre TCP et le débit qui va avec, spécialement > si tu fais tes tests avec une connexion unique qui plafonne.
La QoS est appliquée sur notre passerelle, juste avant la livebox. Il s'agit d'une QoS de type Fair-Queueing par utilisateur (réalisée à l'aide d'IPFW/Dummynet), l'algorithme est QFQ. En revanche, les flux d'un utilisateur ne sont pas régulés. Le Wednesday 28 December 2011 14:16:06, Thomas Mangin a écrit : > Ce n'est pas mon domaine de pointe, mais tes conclusion sont fausses : > - le nombre d'utilisateurs compte Par "le nombre d'utilisateurs n'a rien à voir", je voulais juste indiquer que, que ce soit avec 1 ou 15 utilisateurs (les 135 autres vont sur Facebook/Youtube et utilisent donc les lignes ADSL de toute façon), j'ai les mêmes problèmes. En faisant les tests, j'ai pris soin que rien d'autre que mon unique utilisateur qui ne fait que du P2P ne passe sur la SDSL (plus précisément cet "utilisateur" est un de mes serveurs). > Un_ etudiant utilisant BT peut causer beaucoup de paquets a entrer sur la ligne (depuis le net). Comme le QOS ne marche qu'en SORTIE d'une interface, la ligne DSL peux etre sature avant meme que ton routeur soit touche. Tu ne peux rien y faire. La QoS est effectuée par résident (ip source en upload, ip de destination en download) et est faite des deux côtés. Si on peut réguler le trafic en sortie de l'interface externe, on peut aussi le réguler en sortie de l'interface interne non ? > Avec 150 étudiants, tu risques de passer les limites en terme de PPS de ton BRAS par ligne avant de saturer ta bande passante. Je n'ai jamais vu aucune specification pour le nombre de PPS sure un produit DSL (mais je ne suis pas en France). Comme indiqué plus haut, les tests ont été réalisés avec un seul utilisateur connecté. > Utilise le QOS pour donner priorite a : > - Requête DNS vers les resolveurs utilises (sinon tu va avoir de la > retransmission que tu peux éviter) À ce niveau là, pas de problèmes, le DNS passe par les lignes ADSL. > - TCP ACK, SYN, SYN/ACK, FIN (oui, FIN aussi !!) Ça va être testé, merci. > Si tu utilise un routeur cisco, utilise NBAR. Limite tous les protocoles inconnus a pas grand chose et donne aux protocols connus ( HTTP, HTTPS, FTP, SMTP, POP, IMAP, etc.) la part du lion. La principale utilisation de la ligne c'est du protocole non connu (jeux en ligne / teamspeak), l'IMAP / POP / FTP est minoritaire (et le HTTP/HTTPS passe par les lignes ADSL). > Ceci dit, un utilisateur seul pourra toujours telecharger plus que la ligne ne permet, affectant le service de tous les autres usagers. Je ne comprends pas comment : la QoS met justement une limite à ce que les utilisateurs téléchargent et uploadent : on définit arbitrairement la bande passante (comme indiqué dans le précédent mail, j'ai testé avec 1.4 méga, 1.080 méga, 800kbit/s), et elle est équitablement répartie entre utilisateurs (en fonctions de leurs besoins). Et j'ai pu le vérifier, en aucun cas cette limite n'est dépassée. > Pour ta question sur mtr, les FAI limitent les resources donnees aux routeurs pour repondre a ICMP. Oublie la latence des routeurs, le role d'un routeur est de router, pas de répondre a des requêtes ICMP. > Si un HOP est lent mais le suivant ne l'est pas, il est clair que le routeur ne ralenti pas les paquets qui le traverse. > Si un HOP a 100% de packet loss mais que le suivant n'en a pas, il est clair que le routeur ne pert pas de paquets. Oui, on m'avait déjà fait la remarque, et j'avais testé mtr over UDP (avec le flag -u), pour des résultats identiques. Visiblement pas un problème d'ICMP donc. De plus, le ressenti utilisateur (disons la réactivité du SSH, par exemple), correspond bien à la latence. > Rapelle-toi que tu utilises un produit partage (Avec les produits DSL, il y a de la contention sur la connexion du DSLAM/BRAS au reseau) pour un grand nombre d'utilisateur. > Ce n'est pas la maniere d'utiliser ce produit. Il est aussi possible que tu arrives a atteindre des limites materielles ou du produit. Avec une seule machine qui fait du P2P ? Merci à vous et bonnes fêtes, Cordialement, Grégoire Leroy --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
