If you have for example 1024 Kbps, you have to create a class (maybe htb) about 920Kpbs to create the queue. Then you have to attach the prio qdisc to this class, mark the voip packets and send to class :1 in the prio qdisc. Santiago Ecuador On Thu, 27 Sep 2007 12:05:16 -0400, Santiago wrote > The prio qdisc is the solution. Try this. > > On Thu, 27 Sep 2007 10:31:08 +0800, Ming-Ching Tiew wrote > > As you are probably aware, this is a ever green topic. > > > > I have personally tried doing it, testing it and verifying it > > and I am myself finding this problem challenging and frustrating. > > > > Most of the scripts will recommend some form of rate limiting > > ( or policing ) on the download. But the challenge is how to > > determine the correct value for the policing ? > > > > Lot of the recommendation says use x % over the sales package > > figure. Is this the correct way to do it ? Should it be a more > > engineering way to empirically determine it ? > > > > What I noticed is that if I over-specify the x %, then I > > will greatly limit the utilizable bandwidth. The LAN users will > > noticed significant difference in download speed compared > > to when QoS is not running. But if I under specify the > > x %, then the entire VoIP QoS has no significance, and > > the VoIP quality will be bad. > > > > Any views or comments ? > > > > -------------------------------------------- > > Important Warning! > > > > *************************** > > > > This electronic communication (including any attached files) may > > contain confidential and/or legally privileged information and is > > only intended for the use of the person to whom it is addressed. If > > you are not the intended recipient, you do not have permission to > > read, use, disseminate, distribute, copy or retain any part of this > > communication or its attachments in any form. If this e-mail was > > sent to you by mistake, please take the time to notify the sender so > > that they can identify the problem and avoid any more mistakes in > > sending e-mail to you. The unauthorised use of information contained > > in this communication or its attachments may result in legal action > > against any person who uses it. > > > > _______________________________________________ > > LARTC mailing list > > LARTC@xxxxxxxxxxxxxxx > > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > > > -- > > Este mensaje ha sido analizado por MailScanner > > en busca de virus y otros contenidos peligrosos, > > y se considera que está limpio. > > MailScanner agradece a transtec Computers por su apoyo. > > -- > Open WebMail Project (http://openwebmail.org) > > -- > Este mensaje ha sido analizado por MailScanner > en busca de virus y otros contenidos peligrosos, > y se considera que está limpio. > MailScanner agradece a transtec Computers por su apoyo. > > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Open WebMail Project (http://openwebmail.org) -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que está limpio. MailScanner agradece a transtec Computers por su apoyo. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
