From what I've heard, Skype is particularly hard to classify. Like bittorrent, its clients don't always use the same port, and it opens whatever it wants via UPnP. However you can set a specific port inside of the skype client.

With only 10 people it wouldn't be hard to ensure that they were all set to use a small range of ports, and then manually set those ports to make it into the proper queue. That doesn't solve the problem of the outgoing traffic, which will still be to a random client port, but it may at least help.

thanks for your reply ermal,any documentation about new shaper?

@jhabers:

Thanks dusan, dumb question but for the values you gave me for the ack queues, do i put those nubers in the real time m2 or in the bandwidth for the queue (the one at the top)

That's not a trivial problem.

1. Actually, the numbers say that for 6M/384K ACK packets occupy 63.15% (or 51.28% if you believe in formulas) of uplink if uplink and downlink are both saturated by TCP only. (The underlying model is robust enough to cover virtually all TCP protocols so there are no needs to care about the specific TCP protocols in use.) In reality, however, there are UDP, ESP and other traffics which may reduce the ACK queue size requirements. It would be therefore reasonable if you start at about 40% and increment it a bit in case of need.

2. Real-time curve protects queue's bandwidth better. But real-time bandwidth is a resource that should be allocated very carefully. So, don't use the entire 40% of real-time bandwidth for the qWANack. Rather, set qWANack linkshare's m2 (i.e. the Bandwidth) = 40% and real-time's m2 = 5-10%.

3. The rest (70-75%) of real-time bandwidth should be allocated to other traffics, again, with great care. Therefore, for the most bandwidth demanding traffic (VoIP) I've recommended to try with 200 kb/s = 52%.

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?