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/
