Bonjour,
Voilà ce que j'aimerais faire. J'essaye de faire tourner une application du style visioconférence sur mon PC, sans aucune autre application internet dessus. Ma connexion est une 128/512k.
Dans cette connexion, j'aimerais privilégier l'audio (éh oui, c'est le plus important je pense) à la vidéo. Je voudrais donc allouer une bande passante à l'audio que la vidéo ne pourrait emprunter.
L'audio sort par les ports 5000 ou 5004 ou 5008 ou 5012. Le codec est le GSM-06 (13.2kbit/s). Voici le script que j'ai fait et qui semble marcher, mais qui donne un énorme délai (5-10s parfois) au niveau de la sortie de l'audio:
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 11
tc class add dev eth0 parent 1: classid 1:1 htb rate 128kbit ceil 128kbit
tc class add dev eth0 parent 1: classid 1:10 htb rate 15kbit ceil 15kbit
tc class add dev eth0 parent 1: classid 1:11 htb rate 113 ceil 113kbit
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip sport 5000 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip sport 5004 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip sport 5008 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip sport 5012 0xffff flowid 1:10
Pourriez vous me dire si
- j'ai utiliser la bonne méthode?
- j'ai complètement fait fausse route?
- pourquoi ai-je ce délai qui rend une conversation impossible?
Merci!
Billoute
Forum Linux.noyau Optimisation d'une application visoconférence avec TC
18
avr.
2005
# limiter plus l'upload
Posté par tinodeleste . Évalué à 1.
Sinon, tu peux aussi essayer de passer le paramètre prio à 2 pour la video et au trafic bulk...
# gestion des quotas minimums
Posté par or zax . Évalué à 2.
tu as 128k d'upload
et tu garantis à la fois 128k + 15k + 113 o donc 143k +114 o soit plus que tu ne dispose.
Normalement il faut que le cumul des taux que tu garantis fasse les 128k.
Une chose intéressante aussi est que si au réel tu ne peux envoyer pas plus de 128k, pour éviter de saturer la mémoire tampon de ton modem, que tu envoi que 80% de ton upload maximal, car dès que le tampon de ton modem est plein, tu peux causer des perturbations sur ton download.
[^] # Re: gestion des quotas minimums
Posté par Billoute . Évalué à 1.
--------------------------------------------------
A moins que je ne me trompe, la classe mère garantit 128k.
$ tc class add dev eth0 parent 1: classid 1:1 htb rate 128kbit ceil 128kbit
Et ensuite la bande passante de allouée à la classe mère est partagée pour les deux classes filles.
$ tc class add dev eth0 parent 1: classid 1:10 htb rate 15kbit ceil 15kbit
$ tc class add dev eth0 parent 1: classid 1:11 htb rate 113 ceil 113kbit
Ai-je mal compris?
Quotas max de la classe mère
--------------------------------------------------
Oui, je pense que tu as raison. Il faut que je limite la BP max de la classe mère à 80, 90% de l'upload théorique de mon modem, pour ne pas le saturer.
Merci !
[^] # Re: gestion des quotas minimums
Posté par or zax . Évalué à 2.
puisque tu met
tc class add dev eth0 parent 1: classid 1:11 htb rate 113 ceil 113kbit
si 1:1 doit être la mère des autres classes
met
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 113 ceil 113kbit
et là 1:1 est le parent de 1:10 et 1:11
Donc tu profiles tes différentes utilisation, tu te débrouilles pour répartir le quota pour que le total fasse ton maximum d'upload et c'est gagné
pour la partie voix, le but du jeu est d'attribuer peu de bande passante mais un maximum de priorité. Car là ou tu donnes une priorité il faut pas qu'il puisse prendre tout l'upload, donc tu indique ton prio mais ceil tu met juste le nécessaire
[^] # Délai sur le flux vidéo
Posté par Billoute . Évalué à 1.
J'ai maintenant mon audio qui passe sans délai et en priorité devant la vidéo (le codec audio choisit prend environ 4.1ko/s de bande passante)
tc qdisc add dev eth0 root handle 1: htb default 11
tc class add dev eth0 parent 1: classid 1:1 htb rate 14400bps ceil 14400bps
tc class add dev eth0 parent 1:1 classid 1:10 htb prio 0 rate 4200bps ceil 4200bps
tc class add dev eth0 parent 1:1 classid 1:11 htb prio 2 rate 10200bps ceil 10200bps
tc filter add dev eth0 protocol ip parent 1: u32 match ip sport 5000 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1: u32 match ip sport 5004 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1: u32 match ip sport 5008 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1: u32 match ip sport 5012 0xffff flowid 1:10
Voici maintenant l'objectif suivant:
Avec cette configuration, le flux vidéo est énormément retardé quand le logiciel de visioconférence envoie trop de vidéo. J'aimerais que ce soit linux qui gère ce surplus en le "droppant" sans retarder de plusieurs secondes l'envoie des trames vidéos.
il y a t-il une solution? J'ai déjà cherché sur le net mais sans grands succés...
Merci pour les conseils!
[^] # Re: Délai sur le flux vidéo
Posté par or zax . Évalué à 2.
Le principe est que ce n'est que quand les prio sont vides que il passe à la suite, donc de freiner sur l'utilisation de la bande passante sera peut-être suffisant vu que ce sont des flux constant.
Le prio c' vrai que c'est prévu pour assurer le ssh ou des trucs commes çà.
[^] # Re: Délai sur le flux vidéo
Posté par Billoute . Évalué à 1.
Et c'est encore mieux, tu as raison: les deux flux gardent leur band passante (l'audio n'est plus pris par la vidéo puisque dans deux classes séparées) et la vidéo n'est plus retardée car les deux classes ont la même priorité.
Merci encore!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.