QOS- How to twist the queue limit and min thresh, and max thresh

[alison.hou]

       please see the attached "show policy-map int" in my core MPLS router. here are some facts about my policy-map QOS-WAN:

VOIP : get 40% bandwidth,    

Multimedia: get 36% bandwidth, by default,  the router set the queue limit  to 13477(packets)

BUSCRIT:  get 18% bandwidth, by default, the router set the queue limit to 6738(packets)

Default class: get 6% bandwidth, by default, the router set the queue limit to 2246( packets)

It looked the queue limit for each queue is set by the router in proporsion to its bandwidth allocated.

I also saw the default class in class-default got a lot tail drops. I would like to twist the queue limit and min & max thresholds a little bit to have minimum drops for my default class, more drops for the dscp cs1 traffic. 

Can someone please help?

7609-A#show policy-map int

ATM3/0/0.777: VC 2/777

  Service-policy output: QOS-WAN

    queue stats for all priority classes:

      queue limit 14975 (packets)

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts queued/bytes queued) 39359214/3102276681

    Class-map: VOIP (match-any)

      39349678 packets, 3101570482 bytes

      5 minute offered rate 1972000 bps, drop rate 0 bps

      Match: ip dscp ef

      Priority:  40% (59904 kbps), burst 1497600 (bytes)

      QoS Set

       ip dscp ef

          Packets marked 39359215

    Class-map: MULTIMEDIA (match-any)

      229513 packets, 135856662 bytes

      5 minute offered rate 663000 bps, drop rate 0 bps

      Match: ip dscp af41

      Match: ip dscp af31

      Queueing

      queue limit 13477 (packets)

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts queued/bytes queued) 229513/135856662

      bandwidth remaining 60% (53913 kbps)

      QoS Set

       ip dscp af31

          Packets marked 229513

    Class-map: BUSCRIT (match-any)

      1052397 packets, 284828937 bytes

      5 minute offered rate 118000 bps, drop rate 0 bps

      Match: ip dscp af21

      Match: ip dscp af22

      Match: ip dscp cs2

      Match: ip dscp cs6

      Match: ip dscp cs3

      Match: ip dscp cs7

      Queueing

      queue limit 6738 (packets)

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts queued/bytes queued) 1053010/285008109

      bandwidth remaining 30% (26956 kbps)

    Class-map: class-default (match-any)

      221792641 packets, 148286927557 bytes

      5 minute offered rate 75829000 bps, drop rate 0 bps

      Match: any

      Queueing

      queue limit 2246 (packets)

      (queue depth/total drops/no-buffer drops/flowdrops) 0/10078/0/10078

      (pkts queued/bytes queued) 221933367/148373542301

      Fair-queue: per-flow queue limit 561

        Exp-weight-constant: 9 (1/512)

        Mean queue depth: 0

        class       Transmitted              Random drop      Tail/Flow drop            Minimum Maximum Mark

                        pkts/bytes                     pkts/bytes       pkts/bytes                   thresh  thresh  prob

        default   221807441/148345495442      0/0          10078/15233734                1051    1123  1/10

        cs1         79290/10238677                  0/0              0/0                                  631    1123  1/10

        af13           25/9550                           0/0              0/0                                   701    1123  1/10

        cs5         17868/3073296                   0/0              0/0                                    911    1123  1/10

        cs7            19/1786                          0/0              0/0                                   1051    1123  1/10

7609-A#

thanks,

Alison

[Vasilii Mikhailovskii]

Hello.

Actually your drops statistics for class-default DE looks good, because for the whole history there were about

10078/221807441 = 0,004% drops.

But anyway the drops are "flowdrops" that means that single flow bursted over "per-flow queue limit 561", so I would not worry about DE (at least on the interface).

PS: CS1 were no more than 79290 packets totally, so no reason to tune it.

PS2: my primary concern is that your configuration requires queue of about 20K packets on the physical interface - not sure if your device have them. I would say that summary queue of 2K-3K packets should be enough for 150M link.

[alison.hou]

Thanks for posting and confirming.. which made me feel better.

I didn't get what you said in PS2. I attached the interface configuration and show interface command. I could not find anything about queue from output.

interface ATM3/0/0

no ip address

ip route-cache flow

logging event subif-link-status

!

interface ATM3/0/0.777 point-to-point

description MPLS EPVC

ip address 10.17.1.253 255.255.255.252

pvc 2/777

  oam-pvc manage 0

  encapsulation aal5snap

  service-policy out QOS-WAN

ATM3/0/0 is up, line protocol is up

  Hardware is cyBus ENHANCED ATM PA Plus, address is 000f.34b3.02c0 (bia 000f.34b3.02c0)

  MTU 4470 bytes, sub MTU 4470, BW 149760 Kbit, DLY 80 usec,

     reliability 255/255, txload 98/255, rxload 34/255

  Encapsulation ATM, loopback not set

  Keepalive not supported

  Encapsulation(s): AAL5, PVC mode

  8191 maximum active VCs, 1 current VCCs

  VC idle disconnect time: 300 seconds

  246 carrier transitions

  Last input 00:00:00, output 00:00:00, output hang never

  Last clearing of "show interface" counters 49w0d

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 939454

Queueing strategy: Class-based queueing

  Output queue: 0/40 (size/max)

  5 minute input rate 20268000 bits/sec, 10670 packets/sec

  5 minute output rate 57676000 bits/sec, 12277 packets/sec

     134148383482 packets input, 52069178727130 bytes, 0 no buffer

     Received 0 broadcasts (0 IP multicasts)

     0 runts, 0 giants, 0 throttles

     84 input errors, 89 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     140623034146 packets output, 75441120245009 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     0 output buffer failures, 0 output buffers swapped out

[alison.hou]

I did some research. the hold-queue shoudl be adjusted on the physical interface. or vc-hold-queue under the ATM sub interface.

[Joseph W. Doherty]

What's the line card you're using?

[alison.hou]

I think it is ws-x6582-2pa.

7609-A#show module

Mod Ports Card Type                              Model              Serial No.

--- ----- -------------------------------------- ------------------ -----------

  2    0  2 port adapter Enhanced FlexWAN        WS-X6582-2PA       JAE10160D8F

  3    0  2 port adapter Enhanced FlexWAN        WS-X6582-2PA       JAB08460320

  5    2  Supervisor Engine 720 (Hot)            WS-SUP720-BASE     SAD075101S0

  6    2  Supervisor Engine 720 (Active)         WS-SUP720-BASE     SAD08010388

Mod MAC addresses                       Hw    Fw           Sw           Status

--- ---------------------------------- ------ ------------ ------------ -------

  2  0017.5923.c3d0 to 0017.5923.c40f   2.2   12.2(18)SXF4 12.2(18)SXF4 Ok

  3  0011.2133.81f0 to 0011.2133.822f   1.6   12.2(18)SXF4 12.2(18)SXF4 Ok

  5  000e.385f.40cc to 000e.385f.40cf   3.1   7.7(1)       12.2(18)SXF4 Ok

  6  000d.2910.0994 to 000d.2910.0997   3.6   8.5(4)       12.2(18)SXF4 Ok

Mod  Sub-Module                  Model              Serial       Hw     Status

---- --------------------------- ------------------ ----------- ------- -------

  5  Policy Feature Card 3       WS-F6K-PFC3A       SAD075005FP  2.2    Ok

  5  MSFC3 Daughterboard         WS-SUP720          SAD075308BX  2.2    Ok

  6  Policy Feature Card 3       WS-F6K-PFC3A       SAD080105KV  2.7    Ok

  6  MSFC3 Daughterboard         WS-SUP720          SAD080100BX  2.12   Ok

Mod  Online Diag Status

---- -------------------

  2  Pass

  3  Pass

  5  Pass

  6  Pass