I went with this setup lastnight. 20% for ACKs, but then qClassified is the golden ratio more than qUnclassified. qUnclassified is where my unclassified and P2P traffic goes, because P2P is so hard to classify. I have broken qUnclassified into to groups, UDP and the normal default queue, which will primarily be unclassified TCP. I have a floating rule at the very top to match all UDP traffic and place it in qUDP. The bandwidth is split 50/50 between qDefault and qUDP, but qUDP has a service curve that gives a 25% boost over 5ms. My connection is quite fast, so 5ms is a long time. Based on my limited understanding of service curves, m1 is the pseudo-bandwidth, for lack of a better term, and d is the target latency(must be a realistic value for your connection), and of course m2 is your actual real bandwidth. I don't want to get into the exactness of how service curve work, but the one example that I saw was a 64kb rate where they wanted to cut the jitter in 1/4, so they gave the queue an m1 of 128kb and m2 of 64kb, because they wanted a 64kb average but wanted the link to act like 128kb when it came to scheduling the packet. I saw "packet" and not "packets", because 64kb is such a slow rate and the size of the packets, that it worked out to take 10ms to transfer one packet. So they setup the curve to have a d(duration) of 20ms. The final result was 128kb 10 64kb m1/d/m2. The way I interpreted that one example, is if you have latency sensitive traffic there the intervals of traffic result in a burst relative to the provisioned sustained bandwidth, then you can set m1 and d such that if the queue is still within its average bandwidth, it can get a "burst"(term used very loosely), in order to allow the packets to get scheduled sooner than they would have otherwise for their sustained bandwidth. Of course in order to reduce the delay of one queue, you need to increase the delay of the other queues, not that I care for my "normal" traffic. The over all average bandwidth is still maintained, and the two queues will still have an average split of 50/50. This also implies that the "burst" is a debt to be repaid by consuming less bandwidth after the burst. [image: ShaperHierarchy.png] [image: ShaperHierarchy.png_thumb]

Make sure your WAN interface is properly throttled. Take your real-world, average maximum throughput/goodput value and set the interface ~3-10% less than said value. Until your interface is properly rate-limited, HFSC (or any pfSense/ALTQ sched algo) has no queue to manipulate. The interface needs to receive traffic slightly faster than it can send, otherwise there's no traffic in the buffer/queue for HFSC to intelligently (re)schedule. PS - Are you resetting states?

Are both your NICs the same?  I've seen cases where you don't see a queue if its NIC is unsupported.

I will tryout the dual port (82546) and keep you posted how it works  ;) Thanks KOM

using tcpdump with the pflog interface might be what you want google for more info

There is no Dropbox option in the Shaping wizard.  As stated earlier, it's almost impossible.  They use HTTPS to Amazon EC2.  Good luck blocking it without potentially causing other problems.  The only way to do it would be to get your hands on a definitive list of netblocks used by Dropbox, if there is even such a static list.

awww  :-[ thanks anyway

This is how I understand queue assignment and PFSense. When a new connection is trying to be created, it must pass the firewall rules. There will be 2 states created and attached to the appropriate interfaces. At the time the states are created, they get assigned to their queues based on the rules, but only one rule gets to apply. Example, if I'm trying to connect out to Netflix and the new connection is initialized on my LAN interface, the rule on my LAN interface that passes the connection gets to assign the queue. If the queue is qNetflix, then the state-pair will both attempt to be assigned to qNetflix, but only if qNetflix exists on both interfaces. If my WAN interface does not have qNetflix defined, then it will get dropped in the default queue of the WAN interface, but state on the LAN interface will be placed in qNetflix. It's generally a good idea to declare the same named queues on all of your interested interfaces, otherwise one or both states may be placed in the default queue if the name does not exist. CBQ is roughly the same as HFSC at the abstract level, but HFSC decouples bandwidth and delay in more than one way from the old round-robin ways of CBQ. HFSC does not need to create an artificial backlog of packets nor does it add additional latency to packets in order to maintain proper bandwidth. On top of that, if you know what you're doing, you can decouple bandwidth and latency even further by using service curves. I will not be pretend to know exactly what is going on, but the gist seems to be you can make low bandwidth queue have the delay of a high bandwidth queue without giving it more bandwidth.

The DHCP pass rules are hidden and are above that. Good luck.

@CaptainElmo: Is any part of the PRIQ queue processing offloaded in a manner which HFSC is not? Could there be a situation where I am hitting processing limits of an offloaded resources which are not reported as part of the main CPU statistics? The CPU needed for any sched algo will be minimal. Elegance and efficiency are perhaps more important than actual scheduling capability (Stochastic Fair Scheduling, for example). HFSC, perhaps the most complex and CPU intensive, was capable of 80,000+ packets per second on a 200Mhz Pentium Pro.

HI Harvy66, thank you for your clear answer, I got the point (although I don't like it  :)). You are right, I can have the shaping less effective (or not at all) when bandwidth drops down, but unfortunately is in that moments I need it most, so I figured another possibility. As VOIP traffic flows in the Lan2Lan tunnel, may be I can: Office2 (bad internet) On the WAN: PRIO on ipsec traffic for Lan2Lan without specifying the maximun bandwidth available In Ipsec interface: PRIO on VOIP traffic, again without specifying the maximun bandwidth available Office1 (good internet) On the WAN: shape on ipsec traffic for Lan2Lan (HFSC or even simpler CBQ or CODEL or any of those mix) with bandwidth set to a reasonable value, let's say 20Mb or so On Ipsec interface: shape on the VOIP traffic (HFSC or…) with a bandwidth set to sustain a bunch of concurrent calls, let say 512Kb or so Actually, the Lan2Lan tunnel is openvpn and serves traffic other than VOIP (smb, http, ssh...). May be is better to setup another Lan2Lan Ipsec just for VOIP (instead to substitute the openvpn one) to better try to guarantee low latency to VOIP (that is my only requirement at moment) with PRIO/shaping above. In my mind, this should at least help VOIP latency when bandwidth at Office2 falls down (PRIO), and the shaping on Office1 should help with queue starvation PRIO introduces when bandwidth at Office2 is not (too much) oversubscribed. Does this make sense to you? Thank you very much! Ciao, S.

The source addresses should be the mask on the in queue, dest addresses on the out queue.  Yes, that will create a pipe for each outside address using the characteristics you set.

@Harvy66: @Abhishek: control bandwidth getting used by p2p applications Just making sure because people tend to conflate bandwidth, latency, and fairness and assume everything is to be solved with bandwidth. not facing any latency issue

Is there a reason you don't want them to use all of the bandwidth if the bandwidth is not being used? I let my P2P use all of my bandwidth and I never notice it even when my connection is maxed. The only reason I ask is because most issues of "slowness" are caused by bufferbloat and lack of fairness, not a lack of bandwidth.

I found the issue and thought I'd post the how I "fixed" the issue, I use the fixed loosely. We had an issue a couple of months ago when we installed the pfsense router where lines were being dropped after a specific amount of time. To fix this I followed a number of guides on the internet, all of which said installing siproxd was the way to go… siproxd was the problem, or more accurately my lack of knowledge revolving around VOIP and siproxd was the issue. Until I develop my knowledge the fix was to remove siproxd, thankfully this hasn't recreated the original issue. What lead me to believe there was an issue with siproxd was that registered VOIP phones which show'd up on the list in siproxd weren't working, and phones which weren't registered with siproxd worked perfectly.... if I ever find out what I messed up with on siproxd I shall come back and post my findings.

@Derelict: I didn't see the post about the proxy. If you want to limit traffic to/from specific outside IP addresses I think your only choice is a floating match rule on WAN out to catch the connections being made to those addresses and setting the limiters. In/out will correspond to Upload/Download I think. I think I have had 3 or 4 distinct times where I thought I had a good grasp of limiters, but each time the level of confusion grows in a brand-new exciting way. Networking kryptonite or something.

Best to start your own thread, then we can help you better  :-)

New idea or temporary fix: If I map the whole WLAN traffic to a LAN interface, I could shape this LAN interface instead.

Can a single queue handle both In and Out traffic simultaneously? I think no. If you create "qArb" on both WAN and LAN, you only need to assign traffic once and the returning traffic will find the properly named queue automatically, iirc. I think the Wizard makes use of this method. As a general rule with pfSense, use precise, simple rules to ease later trouble-shooting. Broad rules with superfluous options can create an angry and frustrated admin.

Thanks for the detail - I'll give this a go after I have read it a few times…...! Appreciate your time in response.