PRIQ Shaping Question - No limit on LAN, only limit WAN out
-
Hey everyone,
Trying to setup PRIQ as follows:
LAN Priority
None - I have a gigabit switch, so routing on my internal LAN doesn't need to be proritizedWAN Priority
I have a 30Mb/s download and 5Mb/s uplink. I like to download from newsgroups (which saturates my download and makes browsing laggy). I also have many VoIP phones in the home. I would like my WAN management prioritized as follows:1. VoIP
2. HTTP
3. Everything else
4. NTP/P2PI've used the traffic shaper but can't get my head around the following:
A. Why are the exact same attributes added to both WAN and LAN shapers? (i.e., qVoip on the LAN and WAN side). Shouldn't this only be needed on the WAN side?
B. In the Firewall Floating Rules - I'm confused with two things - Ackqueue/Queue, which "Queue" is this referring to (WAN or LAN), and why would I ever need an AckQueue (and again, is it referring to the WAN or LAN attribute).
C. Second question in the firewall rules, the traffic shaper wizard has only highlighted the "WAN" interface. Underneath it says "choose on which interface packets must come in to match this rule". In my VoIP scenario, isn't this counterintuitive? I'm worried about packets going TO the interface, not from it?
Any help is appreciated.
Thanks!!!
-
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.