verrun, 0 ignored, 12 abort 1326931662 packets output, 2869922208 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up A quick look at the load stats shows us that we're looking at the right side now: reliability 255/255, txload 250/255, rxload 47/255 The errors look about the same, and are not of concern: Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 872 input errors, 472 CRC, 357 frame, 0 overrun, 0 ignored, 12 abort Now, let's look at the queues: Input queue: 0/75/0 (size/max/drops); Total output drops: 152195125 Queueing strategy: weighted fair Output queue: 63/1000/64/152195113 (size/max total/threshold/drops) Conversations 7/223/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) The first thing that pops out at me is that this end of the link is running with WFQ enabled (as it should be). Remember that the other side was FIFO. They don't need to match, but there's probably no reason for the other side to be FIFO. And wow! 152,195,113 packets dropped on the output queue! If we divide that into the total number of packets (152,195,113 / 1,326,931,662 * 100), we get 11.47 percent of all packets dropped. I'd say we've found our problem. This link is SO saturated that Determining Whether the Network Is Congested more than 1 out of every 10 packets is being discarded. It's no wonder users are com- plaining! A total of 11.47 percent might not seem like a lot of dropped packets, but remember that VoIP cannot stand to have packets dropped. Even 1 percent would be a problem for VoIP. And for protocols that can recover lost packets, the result is a perceived slow- down. So, what should your dropped-packet counters look like? In a perfect world, they should be zero. More practically, they should not increment as you watch them, and they should be as close as possible to 0 percent of your total packets sent. If you're dropping even 1 percent of your p