Quick question: does it sound bad when the bandwidth maxes are set to "experience levels" and there's no other traffic present?
Anyhow, setting the bandwidth to 85-90% of experience levels is not a bad idea. Setting it lower should yield better results than setting it higher. There are issues with shaping that depend on the hardware and software. For example, if more traffic than your bandwidth cap can pass through your interface between polls by the software, you're effectively limited in how low you can throttle traffic. You should be above those levels, but that's just a guess without knowing what hardware you're using. What queues and rules do you have setup in the shaper? Thanks, Adrian ----- Original Message ----- From: "Joe Lagreca" <lagr...@gmail.com> To: discussion@pfsense.com Sent: Tuesday, December 15, 2009 3:48:59 PM GMT -05:00 US/Canada Eastern Subject: Re: [pfSense-discussion] Traffic shaping VOIP on low bandwidth connections? The problem is that I have already done this (set bandwidth to real experienced levels) and it sounds bad. I get better results with the way its set right now, however it still has periods where it sounds bad. I'm considering setting it to 90% of real experienced levels to see if that helps. I'd like it to be as good as in my office, but I also have alot more bandwidth. But the shaping seems to work MUCH better when it has more bandwidth to deal with. Joe LaGreca Founder & Owner, BIG Net Online 619-393-1733 x200 Office 619-318-3246 Cell www.BIGnetOnline.com On Tue, Dec 15, 2009 at 12:11 PM, Adrian Wenzel <adr...@lostland.net> wrote: > > You should set the in/out maxes to the real available bandwidth you > experience. Do several tests against different test sites. If you set those > max values too high, the shaper will allow you to clog your pipe (it let's > too much traffic pass without shaping because it thinks it has more bandwidth > to play with). > > The reserve value for VoIP tells the shaper to make sure VoIP traffic never > has less than that amount of bandwidth available. If you're using G.729 and > want to have a max of 10 channels active at one time, you'd want to put > 320Kbps (10 x 32Kbps (the bandwidth used for one G.729 channel)), perhaps > 384Kbps to play it safe. > > Regards, > Adrian > > > ----- Original Message ----- > From: "Joe Lagreca" <lagr...@gmail.com> > To: discussion@pfsense.com > Sent: Tuesday, December 15, 2009 2:43:26 PM GMT -05:00 US/Canada Eastern > Subject: Re: [pfSense-discussion] Traffic shaping VOIP on low bandwidth > connections? > > With the traffic shaper turned off, I get about 1340 kb/sec both ways. > What should I set the traffic shapers inbound bandwidth to? Should > the outbound be the same? > > Also, when it asks for reserving bandwidth for VOIP, what should I set > that to? I have it set to 384 or 512 right now. But I'm not even > sure what that is for. > > Joe LaGreca > Founder & Owner, BIG Net Online > 619-393-1733 x200 Office > 619-318-3246 Cell > www.BIGnetOnline.com > > > > On Tue, Dec 15, 2009 at 10:47 AM, Chris Buechler <c...@pfsense.org> wrote: >> On Mon, Dec 14, 2009 at 11:12 PM, Joe Lagreca <lagr...@gmail.com> wrote: >>> I have a T-1 (1.54mb symmetrical) for our data connection. Whenever >>> there is a big download filling the pipe, the inbound voice chops. >>> >>> When I set the inbound traffic to 1450kb (tested all the way down to >>> 1000kb), I got VERY bad results. Audio was VERY choppy inbound, and >>> ping latency to the internal interface of the firewall would jump from >>> 1ms to 700ms. >>> >>> I was told you can't effectively rate limit the inbound traffic, >> >> Wrong. >> >>> so I >>> set the inbound bandwidth to 5,000 kb. The outbound is set to 1450kb. >>> It sounds much better, but I still have chops when a big download is >>> initiated. >>> >> >> Because of the above excessive limit. You can't do anything once >> traffic is on your downstream, but limiting on the download side >> delays traffic after it gets to you, causing TCP's congestion control >> to slow down the connection, and hence not overfill your downstream. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: discussion-unsubscr...@pfsense.com >> For additional commands, e-mail: discussion-h...@pfsense.com >> >> Commercial support available - https://portal.pfsense.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: discussion-unsubscr...@pfsense.com > For additional commands, e-mail: discussion-h...@pfsense.com > > Commercial support available - https://portal.pfsense.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: discussion-unsubscr...@pfsense.com > For additional commands, e-mail: discussion-h...@pfsense.com > > Commercial support available - https://portal.pfsense.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: discussion-unsubscr...@pfsense.com For additional commands, e-mail: discussion-h...@pfsense.com Commercial support available - https://portal.pfsense.org --------------------------------------------------------------------- To unsubscribe, e-mail: discussion-unsubscr...@pfsense.com For additional commands, e-mail: discussion-h...@pfsense.com Commercial support available - https://portal.pfsense.org
