What you describe is closer to the truth, but I think there is a little confusion in both areas. Traffic shaping does not happen on the interface it enters, it happens on the interface it leaves. That is a fact of life, it's the only way shaping can happen, because that's the only place it can possibly be limited. So, downloads are limited when they leave LAN, uploads are limited when they leave WAN. Content is not "cached" in any way, but if some packets are dropped, which will trigger a resend, eventually the sending side will throttle itself back. Through a combination of this dropping/throttling of packets, the traffic is effectively limited.

Hi people! After three weeks of intense research and to bother some great guys in the forums( ;D) I realized that the way to accomplish that I want it is easy(i am lair :D) to do with a pfSense 2.0 box, and almost impossible to do with pfSense 1.2.3. Finally I'm be able to configure the traffic shaper(ufffff) and I want to share my experiences with both newbies and old-mans in this matters. When I have a five(and I will have), I will post data of my network topology, the requeriments for my network and a guide how I accomplished the requeriments.

I believe the main difference is that PRIQ will reorder packets so that the higher priority ones are passed first, and can't control bandwidth used in the way that HSFC can. If you really want to reserve that bandwidth for VoIP, you may have better luck with HFSC. (but I may be wrong here, someone who knows the altq innards better than I do would probably know for certain)

You could specify 30Mbit as the size of the pipe, and fine tune the m1/m2/d parameters to account for the difference in the queues if you really wanted to get into it.

Thanks jimp! I'll try the book then  ;)

@jits: What you've done is fine. Good work on that. You want to make sure the tribox has that assigned bandwidth when it needs it. If you do a speed test, you'll see that your assigned bandwidth is there for the taking…until your tribox needs it, then the traffic will be shaped as you have configured it. Jits Awesome, thanks for the reply!

I found another cause for this error in this awesome guide for the pf filter """ realtime: the amount of bandwidth that is guaranteed to the queue no matter what any other queue needs. Realtime can be set from 0% to 80% of total connection bandwidth. Lets say you want to make sure that your web server gets 25KB/sec of bandwidth no matter what. Setting the realtime value will give the web server queue the bandwidth it needs even if other queues want to share its bandwidth. """ See the 80% limit of the realtime value. More on: "https://calomel.org/pf_hfsc.html"

I tried setting games to 7 (max) and lowering the ACK queues to 6, that didn't help either.

Any ideas?

The Linux Advanced Routing and Traffic Control HOWTO is the best reference I've found yet for the principles of traffic shaping. Try this section in particular for the explanation you're asking for: http://lartc.org/lartc.html#AEN691

yes I had the IP set and it didnt go to the voip queue till i checked off the ACK box…weird

Almost every dhcpd can do static leases. If you want to use pfsense for that you will be fine…

The trafficshaper in 1.2.3 is not MultiWAN-capable. You might consider taking a look at 2.0 (which is beta).

Actually… the traffic shaper wizard fails to create rules correctly.  So I guess I'll file a bug report, and have to manually create rules, which in 2.0 I have no freakin' clue how to do. Any help on describing the strong and weak points for each scheduler would be nice though.

I just bought a magicjack myself. I ordered a thin client which won't use much power. Go to http://www.magicjacksupport.com/ and click on the buy/sell directory. A user there sells preconfigured thin clients for about $50. His handle is alpman.