PRIQ Priority isn't working
-
Your need to set your bandwidth on your links. The whole point of traffic shaping is to order packets, but if you are letting your connection run at full 1gb link speed, then you'll only ever have 1 packet at a time. It is logically impossible to reorder packets if there is only ever 1 packet.
Set your WAN link to some value less than 100% of your actual Internet speed and the same for your download. Mind you, if your actual bandwidth via your ISP ever dips, then you lose some of the benefit of traffic shaping. If your ISP provides you unstable bandwidth, you may want to set the link rates closer to the low end of your expected bandwidth.
Remember, the whole point of traffic shaping is to manage congestion, so you want the congestion to happen on your firewall and not in your ISP.
Because HSFC almost exclusively cares about bandwidth and does very little with packet order, it is more sensitive to not knowing how much bandwidth you have. Couples that with being harder to configure and you have two good reasons to recommend PRIQ.
-
Set your WAN link to some value less than 100% of your actual Internet speed and the same for your download. Mind you, if your actual bandwidth via your ISP ever dips, then you lose some of the benefit of traffic shaping. If your ISP provides you unstable bandwidth, you may want to set the link rates closer to the low end of your expected bandwidth.
With my other post, another user, KOM, said that PRIQ doesn't care about the speeds and it doesn't need anything in there. You're saying that you need to put it in there, and I can also see that it needs something in there.
The problem I have is that the advertised rate is 50/10(mbps). Normally, it's about 45/8. Occasionally, it will be as low as 25/3. As you can see, the rate varies a lot, depending on time of day and what others in the neighborhood are doing.
Setting PRIQ bandwidth to 50mbps gives me about 45mbps, setting it to 45 gives me about 35 to 40, etc.
Ultimately, it would be nice to tell the traffic shaper to ignore bandwidth requirements from the ISP, and if you see web traffic, it gets top priority, followed by the others, regardless of the entered in bandwidth. This is the primary reason why I moved to PRIQ, but I'm getting two different answers about it.
Thank you though for responding and explaining it to me.
-
It really is a hard problem when your ISP can't provide you reliable bandwidth. Upload is much easier to shape because you are the sender. The problem with download is you are not the sender. Traffic shaping works best when done on the first hop, not the last hop.
Most people who come in here complaining about traffic shaping are complaining about latency that is usually caused by their upload because of the horribly asymmetric upload to download ratios and upload speeds tend to not vary as much because fewer people use upload compared to download, or issue with ACKing download streams. Your issue seems to be shaping download, not the upload so much.
-
Thanks for the information about it. So, if I understand everything correctly…
-
PRIQ needs to have bandwidth set in the interface
-
No matter what method you choose, traffic shaping traffic is extremely difficult when the ISP doesn't provide reliable bandwidth
-
PRIQ can queue traffic better than HFSC in situations like mine[?]
The last bullet is still a question I had. If I had everything working properly with HFSC, why did I switch to PRIQ? Another user said that PRIQ can deal better with bandwidth fluctuations….but since I'm not seeing it, is it doing me much good?
Thanks!
-
-
It's a yes and no for PRIQ "just works".
- It's A LOT simpler for people to understand single dimensional PRIQ priorities than multidimensional HFSC LinkShare, realtime, bursts, etc.
Even I got some really simple HFSC ideas wrong and had to make changes several times to my setup. Here's my latest setup, I think I finally got it "right": https://forum.pfsense.org/index.php?topic=86347.msg474756#msg474756
- Latency caused by upload bufferbloat is one of the biggest issues for what makes the internet "feel" slow. PRIQ handles most of this.
It is a decent rule of thumb to just say "PRIQ will work best". But yes, it does still need your expected up/down bandwidth, so it is a a bit incorrect to say it doesn't care about your bandwidth at all, but I think he meant it doesn't care about your fluctuating bandwidth nearly as much.
-
PRIQ definitely does not care about bandwidth values. The GUI may require you to insert them, but the actual values you supply are ignored. PRIQ only cares about priority levels, and will service higher priority packets before lower ones without any regard for bandwidth allocation.
-
@KOM:
PRIQ definitely does not care about bandwidth values. The GUI may require you to insert them, but the actual values you supply are ignored. PRIQ only cares about priority levels, and will service higher priority packets before lower ones without any regard for bandwidth allocation.
But if your WAN is 1Gb and your LAN is 1Gb, but your Internet is only 5Mb, you will almost never see more than one packet at a time in the firewall. They will enter and exit before any buffering occurs, ignoring anything like interrupt coalescing, etc. In this case, PRIQ will only see one packet. How do you order one packet? You can't QoS or Shape when your buffers are empty, you need to have some back pressure force buffering to happen, which is why you set your Interface rates.
I am not privy to how PRIQ is implemented, but I know it is logically impossible to QoS or shape unless you have more than one packet in your buffer. something might be automatically happening under the sheets, but I don't think it would hurt to set the limits.
-
From the pfSense 2.1 manual:
Priority Queueing (PRIQ)
PRIQ is one of the easiest disciplines to configure and understand. The queues are all directly under
the root queue, there is no structure to have queues under other queues with PRIQ as there is with
HFSC and CBQ. It does not care about bandwidth on interfaces, on the priority of the queues. The
values for priority go from 0 to 15, and the higher the priority number, the more likely the queue is
to have its packets processed.PRIQ can be pretty harsh to lesser queues, starving them when the higher priority queues need the
bandwidth. In extreme cases, it is possible for a lower priority queue to have little or no packets handled
if the higher priority queues are consuming all available resources.If there is no contention, then it's FIFO (first in, first out). If there is a load, then it buffers the traffic into its queues and then sends it based on queue priority.
From the OpenBSD manual:
Priority Queueing
Priority Queueing (PRIQ) assigns multiple queues to a network interface with each queue being given a priority level. A queue with a higher priority is always processed ahead of a queue with a lower priority. If two or more queues are assigned the same priority then those queues are processed in a round-robin fashion.
The queueing structure in PRIQ is flat – you cannot define queues within queues. The root queue is defined, which sets the total amount of bandwidth that is available, and then sub queues are defined under the root. Consider the following example:Root Queue (2Mbps)
Queue A (priority 1)
Queue B (priority 2)
Queue C (priority 3)
The root queue is defined as having 2Mbps of bandwidth available to it and three subqueues are defined. The queue with the highest priority (the highest priority number) is served first. Once all the packets in that queue are processed, or if the queue is found to be empty, PRIQ moves onto the queue with the next highest priority. Within a given queue, packets are processed in a First In First Out (FIFO) manner.It is important to note that when using PRIQ you must plan your queues very carefully. Because PRIQ always processes a higher priority queue before a lower priority one, it's possible for a high priority queue to cause packets in a lower priority queue to be delayed or dropped if the high priority queue is receiving a constant stream of packets.
The root queue takes a bandwidth value but then doesn't do anything with it.
-
The root queue takes a bandwidth value but then doesn't do anything with it.
The poster didn't have the root queue set. If you don't set your root queue(interface), PFSense will process the packets at full line rate, assuming it has enough CPU. PRIQ may always process high priority queues first, but all queues will be empty all the time(for the most part). In order to cause the queues to fill up, you need to limit your interface.
The firewall can only re-order packets in memory, once they're dropped on the line, there's no going back. The rate of which packets are processed needs to be artificially limited in order to cause packets to back-up so they can remain in memory.
-
I hear what you're saying, but I was certain that jimp told me last summer that the PRIQ didn't use the bandwidth value at all. I don't know how the internal buffering is done.
