Re: Getting current interface queue sizes

[Jim Gettys <jg@freedesktop.org>]

On 03/07/2011 02:21 AM, Fred Baker wrote:
>
> On Mar 6, 2011, at 2:31 PM, Justin McCann wrote:
>
>> Thanks for your response. This is more research-related, trying to detect what parts of the stack on an end host are exhibiting and/or causing network stalls a few RTTs or more in duration. I'm also watching the number of bytes and packets sent/received, and when activity stops altogether, looking at the queue sizes shows where things are getting held up. I don't think the approach would be as useful for a middlebox that is just doing best-effort forwarding, but it would probably work if the box was acting as a TCP proxy. So, it's not bufferbloat-related per se, but I figure having the information doesn't hurt, as long as it's not misused like you mention.
>
> No doubt. But I think you'll find that Cisco equipment tells you the maximum queue depth, not the current queue depth, or doesn't implement the object.
>

Cisco is far from unique.  I found it impossible to get this information 
from Linux.  Dunno about other operating systems.
It's one of the things we need to fix in general.

Exactly what the right metric(s) is (are), is interesting, of course. 
The problem with only providing instantaneous queue depth is that while 
it tells you you are currently suffering, it won't really help you 
detect transient bufferbloat due to web traffic, etc, unless you sample 
at a very high rate.  I really care about those frequent 100-200ms 
impulses I see in my traffic. So a bit of additional information would 
be goodness.g
			- Jim