"QoS allows traffic to be managed by queues . . ."
QoS management can be a bit more complex than per queue.
". . . and prioritization takes place?"
Depends on your QoS policy.
"So in a situation where the pipe is backing up, and drops are taking place, is it simply the fact that the higher priority traffic is processed first that results in failure to process the lesser traffic (drops)?
Possibly, possibly not. Congestion is due to trying to send more traffic than egress can physically send, but how that impacts traffic, vis-à-vis prioritization, depends on the policy being used and the nature of the traffic kind(s) when there's congestion.
"Yes, that is exactly what we are wondering. Is there any way to reduce the average time period in order to give a more accurate utilization reading? I believe the chart was generated from data taken from the router."
Depends on how stats are being collected. Often, NMS can set a polling interval, but reducing that, although it may provide for more granular analysis often has adverse side effects. Again, as drops happen down in the millisecond time range, difficult to "see" that level of detail. (It's so problematic, for a while Cisco even incorporated Corvil Bandwidth Estimation Technology in some versions of IOS for analysis of traffic bandwidth need to meets service goals.)
"It is possible that more packets are being dropped than is optimal."
That's very often the case. However, you often don't really need to graph out thoughput vs. drops, just looking at the QoS stats provides much information. If your drops are due to transient bursts (i.e. microbursts), just increasing some queue limits will often dramatically reduce drop stats.
If you're using AutoQoS, personally I believe it's often only suitable for those who want to insure prioritization for real-time traffic like VolP or video conferencing, what it does beyond that, IMO, assumes too much about QoS needs and/or creates an overly complex QoS policy.
