Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
You describe PQ and shaping, but the former is usually a part of doing QoS on L2/L3 switches, and the latter on routers. What device(s) and their IOS versions and the WAN media are you working with?
On "routers", interfaces generally have FIFO tx-rings, only when they overflow, are packets placed in CBWFQ queues. Within CBWFQ, LLQ will be dequeued first, but such packets might have already been queued behind other non-LLQ traffic within the interface tx-ring. (NB: for routers, with tx-rings, when supporting VoIP, you may want to minimize the size of the tx-ring.)
Shapers, in my experience, are "interesting". First, I believe many shapers don't account for L2 overhead, but provider CIRs often do. So unless you shape slower than the nomimal CIR rate, you can send faster than the available bandwidth. (Often I've found shaping 10 to 15% slower allows for average L2 overhead.)
Second, shapers work on averages over time intervals. For VoIP, you'll often want to insure the shaper is using a small Tc, otherwise it will allow FIFO bursts. (I've found a Tc of 10ms seems to support VoIP fairly well.)
Third, I suspect some shapers might have their own queues between the interface and the defined policy queues. If they do, unknown what their queuing organization is or their supported queuing depths. If this is the case, makes it difficult to engineer QoS.
Whenever possible, I've found it beneficial to work to avoid using shapers especially for timing sensitive traffic, like VoIP. In your case, I would suggest, if possible, obtaining 10 Mbps of WAN bandwidth and somewhere passing the traffic through a physical 10 Mbps interface, with a QoS policy.
But to more directly answer your question, PQ (or LQ) will dequeue its packets next compared to other "peer" queues. This should always help VoIP for delay and jitter, but there's more involved whether this is necessary and/or whether it's helpful enough when necessary.
You ask about when a link is saturated, but a link is 100% saturated everytime a packet is being transmitted. Often link usage is represented in percentages of usage of possible maximum transmission rate over some time period, but when it comes to QoS, 100% utilization might be just fine while 1% utilization is not. Much, much more information, about your situation, might be needed to offer truly constructive recommendations.
