Tx-ring-limit and tx-queue-limit commands on 3845

[alex_hannah]

Hello,

I have a new customer who I feel is "shooting themselves in the foot" when it comes to their QoS commands on their 3845, I am looking for more of a sanity check than anything, here is the config:  ( 30mb Fract DS3 )

serial 2/0

   tx-ring-limit 1

   tx-queue-limit 1

I know that from the QoS SRND these commands limit the number of packets that are on the hardware ring and hardware queue to 1, my question is why the heck do you do that?  In all actuality that would allow smaller delay in voice packets ( especially if a 1500byte packet came along ), but on a modern router wouldn't that also make the CPU Utilization go up because now ALL other packets are going to the software queue for queueing?  In addition if the software queue is full then tail drop would occur...

If these commands are not best practice would anyone have a link to more info?  Also, does anyone know what the tx-ring size ( by default ) is on a 3845 and what the hardware queue size is as well?  I am trying to determine what the defaults are so we can take this back to the customer and basically tell them to "let the router do it's job queueing the packets"...

Thoughts?

Thanks!

Alex

[paolo bevilacqua]

There is no hardware queue in software-base routers like ISR. So 1 or 1000 queue size, doesn't make a difference.

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

The reason for reducing the tx-ring-limit is because that queue is FIFO.  Depending on its depth, it can have an adverse impact to time sensitive packets that are queued behind other traffic.

When the hardware queue is smaller, packets overflow into the software queues "sooner", where they can be selectively prioritized.

The disadvange of reducing the hardware's FIFO queue, it may increase overall system loading.  So, ideally you don't reduce it any more than necessary to meet your service level requirements.

Default queue sizes, I believe, vary.  If you remove the explicit configuration and use a show controllers command, you can often see the current hardware buffer setting.

(3845 12.4[13e])#sh controllers g0/0 | in ring

  ring sizes: RX = 256, TX = 256

  rxring = 0x2E012100, shadow = 0x6504F2EC, head = 252 (0x2E0130C0)

  txring = 0x2E013140, shadow = 0x6504F720, head = 242, tail = 243, tx_count = 1

My experience, defaults, especially on older IOS versions, and with "slower" interfaces, are too large vis-a-vis VoIP.  Supposedly, newer IOS version better adjust the ring limit although I'll often still manually downsize ring limits.

Using a ring-size of 1 for 30 Mbps, is too small.  Depending on your time budget, take your maximum packet size and figure how long it takes to transmit such a sized packet.  Then you'll know how many you can allow to queue to meet any timing constraint.