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.
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@mailman.ds9a.nl > 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.
From: "Santiago" <santiago@elportal.net.ec>> The prio qdisc is the solution. Try this. >I wonder if that''s speaking from experience or speaking from theoretical standpoint ? I have always been told, to control the traffic, I have to be the slowest link in the chain. And my question is how slow I should be ! If you are not the slowest, you can''t control. If you are damn slow, you are under-utilizing your bandwidth. Read this section of LARTC :- http://lartc.org/howto/lartc.qdisc.html You also have to be sure you are controlling the bottleneck of the link. If you have a 100Mbit NIC and you have a router that has a 256kbit link, you have to make sure you are not sending more data than your router can handle. Otherwise, it will be the router who is controlling the link and shaping the available bandwith. We need to ''own the queue'' so to speak, and be the slowest link in the chain. Luckily this is easily possible.
On Fri, 28 Sep 2007 09:09:20 +0800, Ming-Ching Tiew wrote> From: "Santiago" <santiago@elportal.net.ec> > > > The prio qdisc is the solution. Try this. > > > > I wonder if that''s speaking from experience or speaking from > theoretical standpoint ? I have always been told, to control > the traffic, I have to be the slowest link in the chain. > > And my question is how slow I should be ! If you are > not the slowest, you can''t control. If you are damn slow, > you are under-utilizing your bandwidth. > > Read this section of LARTC :- > > http://lartc.org/howto/lartc.qdisc.html > > You also have to be sure you are controlling the bottleneck of the > link. If you have a 100Mbit NIC and you have a router that has a > 256kbit link, you have to make sure you are not sending more data > than your router can handle. Otherwise, it will be the router who is > controlling the link and shaping the available bandwith. We need to > ''own the queue'' so to speak, and be the slowest link in the chain. > Luckily this is easily possible. > > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > 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.
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@mailman.ds9a.nl > > 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@mailman.ds9a.nl > 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.
From: "Santiago" <santiago@elportal.net.ec>> 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 qdiscto> this class, mark the voip packets and send to class :1 in the prio qdisc. >That''s what I am talking about. You said it **VERY** easily that "If you have for example 1024 Kbps, you have to create a class about 920 Kbps ...". But what''s the reality. The reality is that you might not have a 1024 Kbps link, even though the ISP you sign up with might claim that. You don''t know for sure. Even perhaps for most of the days you have 1024 Kbps, certain peak hours you might be clamped down to a lower figure due to congestion at the BRAS of the ISP. And how do you arrive at your magic figure of 920 kbps ? And bear in mind that most ADSL are asymmetric, your uplink is usually lower than your downlink. Even if you clamp down your down link, if you don''t police ( or rate limit ) your uplink, you still can''t really control the link. So in practice you will actually police the rate of download to a figure slightly smaller than your uplink speed. There you can see, your overall throughput of the internet (download ) is significantly slowed down.