213900/40638220 (depth/total drops/no-buffer drops) 3/0/0 Notice that the queue is not dropping packets, even though it is now too small. This behavior is quite different from what we saw in the priority queue. When saturated, the priority queue will drop packets, even if there is additional bandwidth available on the link. Other queues do not drop packets unless the entire link is saturated. The 3/0/0 in the last line shows the queue depth, total drops, and no-buffer drops values. The queue depth indicates that there are three packets queued, but that's a rarity, even with the link now running at more than 50 percent utilization: R1#sho int s0/1 I include minute 5 minute input rate 883000 bits/sec, 830 packets/sec 5 minute output rate 897000 bits/sec, 846 packets/sec Even when I increase the traffic SO this queue is running at over triple capacity, as long as the link is not saturated, no packets are dropped: Class-map: Voice-Control (match-all) 281655 packets, 54324322 bytes 5 minute offered rate 237000 bps, drop rate 0 bps Match: ip precedence 3 Queueing Output Queue: Conversation 265 Bandwidth 5 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 281936/54381084 (depth/total drops/no-buffer drops) 0/0/0 With a saturated link, the queue will drop packets when full. Nonpriority Queue Too Large As with the priority queue, when a nonpriority queue is too large, the problem will not be obvious. The scheduler may spend too much time servicing the queue unnecessarily, Chapter 34: The Converged Network which can result in drops in lower-priority queues, but only after servicing the strict priority queue. Here, the HTTP queue is configured for 40 percent of the link's total speed. With the link being a T1, this translates to more than 600 Kbps. However, the queue is only showing 1 Kbps being offered: Class-map: HTTP (match-any) 79255 packets, 4690398 bytes 5 minute offered rate 1000 bps, drop rate 0 bps Match: access-group 101 79255 packets, 4690398 bytes 5 minute rate 1000 bps Queueing Output Queue: Conversat