You should be able to do it with a HFSC scheduler

Great, that's what I hoped it meant from looking at the raw rules

Without shaping the entire traffic from everyone, you cannot shape a subset of the LAN. Shaping works by dropping / queueing packets. This can't work unless all traffic is classified. Once you have basic rules in place, you can create further rules for specific IP addresses. Either way you need to completely understand HFSC and how the queues work or you'll fail to get it working.

@shawniverson: Most definitely!  I am using both and it is working great.  No special/unusual configuration needed (in some cases) Here's a sticky post that may help: http://forum.pfsense.org/index.php/topic,14436.msg76415.html#msg76415 Do you know if that sticky is still relevant with pfSense 2.1 ? –--------- The easy way Traffic Shaping with Squid Transparent Proxy Add under Firewall Rules Action = Pass Interface= LAN Source= LAN subnet Protocol = TCP Source = LAN Destination = any Destination port range = (Squid Proxy port) eg. 3128

Just an update, go this working by moving the rule to the LAN tab used the ack queue for SSH interactive and used the main queue for SCP $ cat /tmp/rules.debug <snip>pass  in  quick  on $LAN  proto { tcp udp }  from any to any port 22  keep state  queue (qP2P,qOthersHigh)  dnpipe ( 4, 3)  label "USER_RULE: Prioritise SSH not SCP traffic"</snip>

Burst speed after being idle perhaps? In 2.1 theres an option to state normal speed and a burst speed when its been idle which might be what you are seeing, hence the above.

Yeah, ever since I have upgraded to 2.1-Rel my PRIQ queues just don't make sense. They show crazy numbers, sometimes in the Gb range, they take a minute or two to stabilize to real numbers. Like a VOIP queue should show roughly 50pps/64Kbits + 10% overhead or so per call. It used to show that pretty much instantly when a call was started in 2.0.X. Now it takes a minute for it to even crawl up to 64kbits.

Hi CSBS Please post a bug report. I have tried but could not back my findings up with fact so it was rejected. Sounds like you have good evidence. Else 2.1 final is out… you can try to upgrade if you dare upgrade your production router. Interesting to head if bug exist in 2.1 or if it is solved.

No, unfortunately. I have given up using limiters on this particular production router. I just bought some new routers and want to set one up with 2.1 and test that to see if issue with limiters has been solved in 2.1.

I am confused of how to define this rule or where to add it. Can you give me a push in the right direction? Im looking around but not sure i get it.

BTW: I've had your problems with wrapping my head around certain phenomena. Like, I also had cases where everything looked alright but still: no packets would show up in certain queues. My approach solved all those issues for me. Anyway, no matter how you do it, just remember: each queue works on exactly one interface in exactly one direction (outbound). "My" approach just implements this behaviour by putting the queueing rules directly "on top of" the corresponding interface. One rule for each queue.

I would use pftop via ssh or serial console. Launch pftop, order by connection age or something, launch game, check destination ports.

Such a "smart" shaper could be done with squid and delay pools.

Note that this only works for routed or NATed Internet traffic. If you're making a PPPoE connection from the internal router past pfSense in transparent firewall mode then it won't work

Does employing limiters impact ACK transit times?  Do ACK's need to be broke out and treated differently than the bulk of limited traffic so as not to cause unintended performance penalties?