PRIQ Shaping Question - No limit on LAN, only limit WAN out
-
A. Shaping only affects egress, not ingress. If you want to shape download data, you need to have queues on your LAN interface
B. The queues are relative to the interface one which the rule is matching. What confuses me about floating rules is if they can match both ingress and egress, which floating rule wins when one rule matches on the ingress of one interface and another rule matches on the egress of the other interface. Can the queue change once set?
C. not sure
-
From my understanding if a floating rule creates a queue on the WAN interface it should apply that automatically to matching traffic going out on the LAN.
I think I read that in a forum post on here somewhere.
-
That's not my experience. I had it a few weeks back where my games were getting assigned to my games queue on my WAN, but the default queue on my LAN. I had to set the floating rule for both interfaces and set direction to Any before it put my games in both queues.
The reason I could tell this is what was happening is because both queues were at 0, then I'd open a game, and my WAN queue would increment, but not my LAN queue. I assumed it was going to Default. I can't know for sure because there doesn't seem to be a way to see which queue a given state is assigned.
At one point I was messing around and I got my games to go to qGames on WAN and qVoIP on LAN. Bah.. I haven't figured out floating yet.
-
Hmm. it seems to put them in the right ones for me with HFSC by using direction ANY and interface WAN on my rules and I see both queues increment.
I can test it again and see if that is still the case. I dont set queues for anything on the LAN side and let the floating rules handle it all.
-
My issue might be that I have a catch all floating rules that apply to all traffic on both interfaces. Maybe it's matching on the LAN interface before reaching the WAN interface and causes my issues.
I could see about setting all of my rules to the WAN and ignore the LAN. I really wish there was a manual with all of the cases for floating rules. I haven't found one yet.
-
Yea i dont have a catch all rule. I just let it go into the default queue because at the LAN parties that works for me.
-
I use catch all because TCP and UDP typically have different characteristics, so I like to break them into their own separate queues. I'll try just setting them to WAN and not LAN and see what happens. UDP is typically low bandwidth and latency sensitive and TCP is typically bulky.
-
Give CoDel a try. Apply it to both your LAN and WAN port. Don't worry about the up/down speeds. See if that doesn't help.
Save you current setup so you can re apply it if desired.
-
Give CoDel a try. Apply it to both your LAN and WAN port. Don't worry about the up/down speeds. See if that doesn't help.
Save you current setup so you can re apply it if desired.
Thanks for the tip. Really seems to work - and virtually no config (didn't even put in bandwidth settings)! I wasted a day of my life setting up PRIQ for nothing :(
-
Glad it is working. I am hoping that the developers will implement fg-codel. That brings dynamic queue separation for the flows with codel working on each queue individually.