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?

I wanted to thank both of you for your input on this, but seemingly can't.  Thanks, and sorry for the delay in it; I stopped looking after a week!  I'll work on the assumption that even the basic queues created by the wizard should be treated with suspicion for now.

There is a link right there on the L7 page to upload patterns.

Patters are like those from the l7-filter project.
http://l7-filter.sourceforge.net/protocols

It's best if you don't use the wizard and manually create the queues to fully understand how it works.

The queues on the LAN interfaces are independent of each other therefore you cannot traffic shape downstream without setting a hard speed limit on each LAN interface which totals less than your total downstream speed.

To avoid capping the speeds on the LAN interfaces, one solution is to use a second pfSense box in transparent bridge mode to perform traffic shaping on the entire upstream & downstream WAN traffic.

If you have the MAC address of all the machines, I guess you can give them fixed IP addresses too?
Then you should be able to create two "Alias" with the IP addresses of the two groups and create firewall rules according to your needs.

With that in place you should be able to divide bandwidth between the two alias groups with the shaper.

I don't know if it's there or not, feel free to search on redmine

I don't know if that will ever be possible, but you can put in a feature request ticket (target=future) for it.