Getting current interface queue sizes

[Fred Baker]

On Feb 28, 2011, at 2:26 PM, Justin McCann wrote:

> This may be well-known, but how does one retrieve the current outgoing and incoming queue sizes from the link-layer interfaces? I mean the number of packets/bytes in the various queues, not the size of the buffers (potential queue size). I've mucked around with ethtool and netlink to grab other statistics, but haven't found any way to pull the current queue sizes into userspace. 

When the SNMP MIB was first developed, they originally specified ifOutQLen as "The length of the output packet queue (in packets)." One problem: Cisco implements that as "how many packets can I put into the queue in the deepest possible case". The outfit I worked for before Cisco implemented it as "what is the current depth of the output queue". Interoperable implementation...


There are a few issues with the "current" model. Suppose you are in this network

         +---+        +------+
         |NMS|        |Target|
         +-+-+        +---+--+
           |              |
        ---+--------------+----

and you ask the target what the length of its Ethernet queue is. When you get the answer, what is the length of its Ethernet queue?

To determine the answer, think through the process.

   - NMS sends a question to Target
   - Target thinks about it, concocts an answer, and puts it in the Ethernet queue
   - Packets ahead of response in Ethernet queue drain
   - response packet is transmitted.
   - NMS receives response

At the time the NMS receives the response, there's a reasonable chance that the queue is absolutely empty. Or that it is twice as full as it was before. Or some other number. All you can really say is that at the time the agent answered the question, the queue had ifOutQLen packets in it.

The object got deprecated on the grounds that it didn't make a lot of sense.

When I try to measure queue lengths, I do so by trying to pass a message though the queue. That lets me measure the impact of the queue on delay, which is actually far more interesting.