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

John Neiberger jneiberger at gmail.com
Tue Sep 24 16:37:53 EDT 2013


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/
>>
>
>


More information about the cisco-nsp mailing list