Hi Andrew
Your show command, makes a lot of sense when referenced alongside the
following excerpt from the config guide:
"This example shows how to assign the ingress bandwidths to the queues.
Queue 1 is the priority queue with 10 percent of the bandwidth allocated to
it. The bandwidth ratios allocated to queues 1 and 2 is 4/(4+4). *SRR
services queue 1 (the priority queue) first for its configured 10 percent
bandwidth*. Then SRR *equally shares* the remaining 90 percent of the
bandwidth between queues 1 and 2 by allocating 45 percent to each queue:"
Switch(config)# *mls qos s*rr-queue input priority-queue 1 bandwidth 10
Switch(config)# *mls qos s*rr-queue input bandwidth 4 4
Then this clarifies a bit further.....
"You can configure SRR on egress queues for sharing or for shaping. However,
*for ingress queues, sharing is the default mode, and it is the only mode
supported. *
In shaped mode, the egress queues are guaranteed a percentage of the
bandwidth, and they are rate-limited to that amount. Shaped traffic does not
use more than the allocated bandwidth even if the link is idle. Shaping
provides a more even flow of traffic over time and reduces the peaks and
valleys of bursty traffic. With shaping, the absolute value of each weight
is used to compute the bandwidth available for the queues.
*In shared mode, the queues share the bandwidth among them according to the
configured weights. The bandwidth is guaranteed at this level but not
limited to it. For example, if a queue is empty and no longer requires a
share of the link, the remaining queues can expand into the unused bandwidth
and share it among them. With sharing, the ratio of the weights controls the
frequency of dequeuing; the absolute values are meaningless."*
So in your output it reads that 30% bandwidth guaranteed by priority to Q2,
then 35% of total bandwidth guaranteed - but not limited to - for each
queue.
So for example, ALL other traffic is marked CoS 0, and CoS 0 is mapped to
Q1, then Q1 could effectively burst to 70% of the total bandwidth despite
your output referencing 35.
......at least that is my interpretation :-)
Cheers
Andy
2009/7/1 andrew <andrew.coates_at_internode.on.net>
> Hi all,
>
>
>
> I have a question about the priority queue function within ingress queueing
> on the 3560, first off I will take a section from the doc cd:
>
>
>
>
> http://www.cisco.com/en/US/customer/docs/switches/lan/catalyst3560/software/
> release/12.2_25_se/configuration/guide/swqos.html#wp1065146<http://www.cisco.com/en/US/customer/docs/switches/lan/catalyst3560/software/%0Arelease/12.2_25_se/configuration/guide/swqos.html#wp1065146>
>
>
>
> SRR services the priority queue for its configured weight as specified by
> the bandwidth keyword in the mls qos srr-queue input priority-queue
> queue-id
> bandwidth weight global configuration command. Then, SRR shares the
> remaining bandwidth with both ingress queues and services them as specified
> by the weights configured with the mls qos srr-queue input bandwidth
> weight1
> weight2 global configuration command.
>
>
>
> Now assuming the following with shared round robin:
>
>
>
> CAT-2#show mls qos input-queue
>
> Queue : 1 2
>
> ----------------------------------------------
>
> buffers : 60 40
>
> bandwidth : 35 35
>
> priority : 0 30
>
> threshold1: 50 30
>
> threshold2: 75 75
>
> CAT-2#
>
>
>
> Does this mean that queue two gets 30% of bandwidth in a priority fasion
> (serviced first) and then the remaining 70% is shared between both queues
> in
> a round robin fasion?
>
>
>
> I haven't seen it implicitly spelled out anywhere so I just want to
> confirm.
>
>
>
>
>
> Cheers
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Wed Jul 01 2009 - 15:39:22 ART
This archive was generated by hypermail 2.2.0 : Sat Aug 01 2009 - 13:10:21 ART