". . . however my conscious reverts me back the cisco recommendation of no more than 33% guaranteed BW for a PQ ( assuming this still stands?) . . ."
Yea, I also recall Cisco does recommend not exceeding 33%. Further, recall, they recommend this to insure there's sufficient bandwidth for non LLQ/PQ traffic.
I consider Cisco's "why" (if I remember their "why" correctly) nonsense. Basically, whatever bandwidth other traffic "needs" should be determined just as if it were the only bandwidth available for that traffic. (Unfortunately, I believe, not many really know how to do that either.)
That said, a really worthwhile reason to keep LLQ/PQ traffic at 1/3 or less, is, if this is a generic queuing situation, generally because there's a low probability of queuing when your average utilization is 1/3 or less. Above 2/3, you can start to run into significant queuing. Between 1/3 and 2/3, you often have some queuing, but often not "a lot". (More or less, average utilization vs. queuing is a somewhat exponential curve.) In my experience, often, with real-time traffic like VoIP, you can even get up to about 50% utilization before you start to adversely impact the LLQ/PQ traffic. For real-time traffic like video, as it's much more variable in bandwidth demand, I would try to avoid exceeding 1/3, However, I, personally, have usually found up to about 35%, "safe" (with a mix of VoIP and video).
To your question about setting PIR, first as that traffic will be transmitted with LLQ/PQ priority, it would just be considered another part of your overall LLQ/PQ traffic allocation. For example, if your LLQ priority class 1 is 5 Mbps, and your LLQ priority class 2 is 50 CIR and 10 PIR, you total LLQ/PQ traffic allocation is 65 Mbps, which would be 65/200 = 32.5 %. Still within 33%, and, in my experience, you could push the PIR a bit more.
As to how much bandwidth your non LLQ/PQ traffic needs, again, it might be fine with just 1%, or it might need more. Depends on what that traffic needs.
For real-time traffic, we generally don't want drops, additional latency, and too much jitter. To guarantee that, again, you want, usually at least two (minimally) to three (safer) times the average bandwidth usage as available bandwidth for that traffic. As LLQ/PQ pushes other traffic "aside", effectively it's able to obtain the whole port's bandwidth for a burst. (I.e. 2 to 3 times, the inverse of 1/2 to 1/3.)
BTW, the above holds true for pre and post HQF QoS.
Possible
police cir 50mb pir 139
And with your other 5 Mbps, that's a total of 194/200 = 97%.
Yes, you can do that, if 1) all the other traffic is "happy" with 3% of bandwidth, and 2) you're not expecting any real benefit for using LLQ/PQ, with that kind of allocation, to minimize drops/latency/jitter issues.
Paul, if above is unclear, please let me know.
QoS often appears complicated. Actually it's not, but much has to be understood for it to make sense. I.e. it's not so much a deep subject but a wide subject.
Don't know whether this will help, but if we're supporting real-time video, like video conferencing, again, we probably want it in a LLQ/PQ class where it's average utilization is about 1/3 of possible (i.e. port's/link's maximum) bandwidth. The 2/3 bandwidth we can burst into, because of LLQ/PQ, it's what insures low drops/latency/jitter.
If we're dealing with streaming video, which often has multi-second buffers, we still want to very much avoid drops, but variable latency/jitter are, more-or-less, non-issues. I.e. we can queue those packets. For such traffic, we might be fine with supporting an average utilization of up to about 90 to 95% of possible bandwidth. We want some "excess" bandwidth, because when average usage approaches 100% we can start to get almost "infinitely" deep queues.
