[c-nsp] WRR Confusion on 6748 blades

[Chris Evans]

This is where I ask the question whether you need QoS and its queues or
not? At my old employer we never enabled QoS on our 6500s in the data
centers because of this buffer carving issue. When you disable QoS on the
6500 platform it lets the dscp/802.1p bits pass, which we were fine with.
We never wanted to do tagging for applications, it was always do it
yourself or its not getting done. Anytime we enabled QoS we ran into issues
such as you are having.

If you don't need QoS features, disable it and you will have the full
interface buffer for any traffic. If you do need QoS perhaps remap your
queues to reduce the amount of queues that will be in contention for
bandwidth.   In my experience QoS on the 6500 has always caused more issues
than its solved due to its limited interface queuing capabilties.

On Wed, Jun 27, 2012 at 12:01 PM, John Neiberger <jneiberger at gmail.com>wrote:

> On Wed, Jun 27, 2012 at 9:58 AM, John Neiberger <jneiberger at gmail.com>
> wrote:
> > On Wed, Jun 27, 2012 at 8:24 AM, Janez Novak <jnovak123 at gmail.com>
> wrote:
> >> 6748 can't do shaping. Would love to have them do that. So you must be
> >> experiencing drops somewhere else and not from WRR BW settings or WRED
> >> settings. They both kick in when congestion is happening (queues are
> >> filling up). For exaple linecard is oversubscribed etc
> >>
> >> Look at second bullet
> >> (
> http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/qos.html#wp1728810
> ).
> >>
> >> Kind regards,
> >> Bostjan
> >
> > This is very confusing and I'm getting a lot of conflicting
> > information. I've been told by three Cisco engineers that these queue
> > bandwidths limits are fairly hard limits. That is in line with what we
> > were experiencing because we were seeing output queue drops when the
> > interface was not fully utilized. Increasing the queue bandwidth got
> > rid of the output queue drops. For one particular application
> > traversing this link, that resulted in a file transfer rate increase
> > from 2.5 MB/s to 25 MB/s. That's a really huge difference and all we
> > did was increase the allocated queue bandwidth. At no point was that
> > link overutilized. In fact, during our testing of that particular
> > application, the link output never went above 350 Mbps. We used very
> > large files so that the transfer would take a while and we'd get a
> > good feel for what was happening. Doing nothing but increasing the
> > queue bandwidth fixed the problem there and has fixed the same sort of
> > issue elsewhere.
> >
> > I'm still researching this and trying to get to the bottom of it. I
> > think we're missing something important that would make this all make
> > more sense. I appreciate everyone's help!
> >
> > John
>
> Also, these 6748 linecards are 1p3q8t. According to that doc these use
> DWRR. Does the second bullet apply to DWRR, as well? I'm not quite
> sure of the differences.
>
> Thanks again,
> John
>