--- On Wed, 9/9/09, Pete Templin <[email protected]> wrote:
> Tony wrote:
>
> >> From the card above you can see that unclassified
> traffic (COS 0)
> >> will start getting discarded at 40% and as the
> queue gets fuller it
> >> will progressively discard more. If the queue gets
> to 70% then ALL
> >> COS0 traffic will be discarded. In queue 1 this
> 30% at the top of
> >> the queue is for COS 2 & 3 packets in
> threshold 2.
> >
> > This theoretically means that the maximum throughput
> you would see on
> > the above card with just enabling QOS and not
> configuring anything is
> > around 700Mbps (70% of 1Gbps). in reality it would
> probably be a bit
> > less, but that would be absolute maximum
>
> Can you clarify this for me? If 999Mbps of traffic is
> arriving on an 'ingress' port and is the only traffic
> leaving on an 'egress' port, there shouldn't be much if any
> queueing, right? Queueing should only be occurring
> when the (instantaneous) packet arrival rate exceeds the
> rate at which the device can dispatch the packets, and as
> those queues get to various thresholds of %-full, they'll
> execute WRR to manage the queue depth, correct?
>
> pt
>
I can see what you're getting at and it sounds correct.
It might hold true in a test environment where you only had two interfaces and
you pushed traffic in one and out the other. If I had access to the gear to
test this I would like to and see what happens with and without QoS enabled. In
most normal environments you would probably have bursty traffic and over
subscription somewhere even if it the egress interface wasn't being
over-utilised (ie average egress <1000Mbps).
There are also buffer limits that are applied to the queues. The below is from
the output of "show queueing int gigx/y":
queue-limit ratios: 70[queue 1] 15[queue 2] 15[Pri Queue]
The above output says that queue 1 (ie. default class, COS 0) is only allowed
70% of the buffers. I'm not sure whether the "queue-limit" is a hard limit
though (ie. it can't ever be exceeded). I'm not totally convinced of this part
of my argument myself. It a 1:1 situation, do the queues fill at all or can the
egress interface transmit as fast an ingress packets so that there is no
queueing at all (as you questioned above) ?
You then have the ratio of how the queues are serviced, which is:
WRR bandwidth ratios: 100[queue 1] 255[queue 2]
So queue 1 gets 100/(100+255) = 28% of the WRR scheduler and queue 2 gets 72%.
Even though queue 2 is smaller, because it gets serviced with a higher
weighting it will empty quicker than queue 1.
There is also the previous thread from the OP who stated that with default QoS
enabled he was only getting ~400Mbps out of his Gbps port.
http://puck.nether.net/pipermail/cisco-nsp/2009-July/062100.html
This suggests that stuff is being dropped to make sure the queue buffers aren't
filled so that there is room for any stuff with higher COS settings perhaps ?
If the queue was filled with COS 0 traffic and some higher COS traffic comes
along you would have to drop the higher COS traffic due to lack of space in
buffers which kind of defeats the purpose of QoS (give/reserve priority to
higher preferenced traffic).
I would point to the below reference on not enabling QOS globally without
looking at your traffic because you may get less performance than with QoS
disabled:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/qos.html#wp1750716
This next link also has some examples of how changing some of the queue values
affects what happens to the traffic in the queues.
http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a008015bf98.shtml
If someone else wants to correct me then please do. This is how I understand it
works, but I'm happy for it to be otherwise. I'm aware that this stuff gets
archived and people will be looking at it in the future, I don't want someting
that is incorrect to be left around for people to be looking at thinking it is
correct (peer reviewed == good).
Anyone more knowledgable on the subject wish to chime in ?
regards,
Tony.
__________________________________________________________________________________
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.com/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
