[c-nsp] Dynamic output buffer allocation on Cisco 4948

[Terebizh, Evgeny]

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" <jneiberger at gmail.com> 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 <ikiris at gmail.com> 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
>><jneiberger at gmail.com>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  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>
>>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/