Le Wednesday 28 December 2011 21:41:55, Radu-Adrian Feurdean a écrit : > On Wed, 28 Dec 2011 15:06:02 +0100, "Grégoire Leroy" > > <gregoire.le...@retenodus.net> said: > > 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 ? > > Ok, tu peux le faire, mais ca ne sert pas a grand chose : ton tuyau peut > etre deja sature avant que ca arrive chez toi. > Normalement, le Qos est effectif quand il est mis avant l'entree dans le > tuyau le plus petit. Dans ton cas c'est en uplink. Pour le downlink, il > faudra que c'est ton FAI qui le fait, mais ils doivent avoir d'autres > choses au program.
Effectivement, c'était probablement ça : le trafic effectif dépasse allègrement la limite imposée à la QoS. Cette limite joue, mais elle est dépassée d'environ 30%, ce qui fait que même avec une limite à 1.2 Mbit, je saturais la ligne. Merci à toi. > > 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. > > Ca ne change rien. Seule la latence entre la source et la destination > fait foi. La latence sur les routeurs intermediaires est TOUJOURS traite > par des CPU qui plus important a faire. D'accord, merci. > > Avec une seule machine qui fait du P2P ? > > Aieee !! Tu fais tes tests en P2P ??? Essaie deja de valider le debit > sur UNE seule connexion TCP, ou avec un flux UDP, avec differentes > tailles de paquet. J'avais aussi fait des tests en utilisant une connexion HTTP, pour des résultats similaires. Cordialement, Grégoire Leroy --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
