Hi John, You might try issuing "show interfaces gigabitEthernet 1/1 counters detail" command. It's gonna show drops in particular output queues. Didn¹t find a command showing actual queue utilisation though.
/ET On 9/25/13 12:37 AM, "John Neiberger" <[email protected]> wrote: >Sure, I get that. I'm just curious to know if there is a way to tell the >depth of the queue on an interface at any given time. I'm nearly certain >this is the cause of the variable latency we were seeing. What I don't >know >is if there is a way to see it happening on the switch. We may need to >tweak the output queue settings for this particular application. It sounds >like it is extremely sensitive to variable latency. > >Thanks, >John > > >On Tue, Sep 24, 2013 at 2:32 PM, Blake Dunlap <[email protected]> wrote: > >> The point of the large buffers of that switch is to prevent drops under >> port congestion. If you want drops or something like LLQ to occur >>instead >> for your app traffic, you can tweak the QoS settings appropriately for >>your >> app / switch. >> >> -Blake >> >> >> On Tue, Sep 24, 2013 at 2:17 PM, John Neiberger >><[email protected]>wrote: >> >>> I've been helping to troubleshoot an interesting problem with variable >>> latency through a 4948. I haven't run into this before. I usually have >>> seen >>> really low latency through 4948s, but this particular application >>>requires >>> consistent low latency and they've been noticing that latency goes up >>>on >>> average as load goes up. It didn't seem to be a problem on their >>>servers, >>> but communication through busy interfaces seemed to dramatically >>>increase >>> the latency. They were used to <1ms latency and it was bouncing up to >>>20+ >>> ms at times. I'm starting to think this is due to the shared output >>>buffer >>> in the 4948 causing the output buffer on the uplink to dynamically get >>> bigger. >>> >>> I've been trying to find more details on how the 4948 handles its >>>shared >>> output queue space, but I haven't been able to find anything. Do any of >>> you >>> know more about how this works and what commands I could use to >>> troubleshoot? I can't find anything that might show how much buffer >>>space >>> a >>> particular interface is using at any given time, or if it even makes >>>sense >>> to think of it that way. If I knew the size of the buffer at any given >>> moment, I could calculate the expected latency and prove whether or not >>> that was the problem. >>> >>> Thanks! >>> John >>> _______________________________________________ >>> cisco-nsp mailing list [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>> >> >> >_______________________________________________ >cisco-nsp mailing list [email protected] >https://puck.nether.net/mailman/listinfo/cisco-nsp >archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
