Cat3850 - qos queue-softmax-multiplier - settings

[oguarisco]

Hi to all,

Reading through the CCO document "Catalyst 3850: Troubleshooting Output drops" I came across the command qos queue-softmax-multiplier, by default in latest IOS XE3.6/3.7 is set to a value of 100 which corresponds to 1200 soft buffers per each gigabit port with no QoS enabled.

Those 1200 soft buffers are distributed in 2 queues

• queue 0 = 480 (40% of the total buffers reserved)
• queue 1 = 720 (the rest => 60%)

The value of the command qos queue-softmax-multiplier could be increased to a max of 1200...
If I configure it as 200 means a total of 2400 soft buffers per Gigabit port

• queue 0 = 960(40% of the total buffers reserved)
• queue 1 = 1440(the rest => 60%)

since it's configured globally each Gigabit port "receive" new values and I was wondering where those soft buffers come from?

A global shared pool? What happens when you increase it on all port? is there a chance that this will create buffer availability problem since by default is very low?

Thanks for any suggestion
BR
Omar

[markchristy]

Old post, but exactly what I am experiencing. I get a random drop as seen in XMIT-ERR and OUTPUTDISCARDS, which are always equal in number, always.

UDP packets that are trying (buffered or queued) egress the port will drop catastrophically. No Ack/Nack UDP, so broken processes show up (on hosts).

Someone, somewhere, I hope; can concisely explain how to fix? QOS or softmax multiplier? 

searching for a fix...

[Joseph W. Doherty]

Firstly I should note I'm unfamiliar with 3650/3850 series, but pretty familiar with the 3560/3750 series, which, I suspect, is similar if architecture design and function.

On the 3750 series, they only had 2 MB RAM for/per 24 copper ports or for the uplink ports. The architecture, with QoS enabled, "reserved" physical RAM for each port and also set aside RAM as a common pool. When a port ran short of its "reserved" RAM, it would attempt to acquire more from the common pool.

Output discards would happen either when a logical egress limit was exceeded or when there was not physical buffer RAM available.

During short term bursts, ports often would first hit the logical limits, so increasing those often mitigated port drops. (On the 3850, I believe the queue-max-multiplier adjusts the logical limits.)

To deal with running short of physical buffer RAM, you had to adjust buffer allocations. What I found usually worked well was decreasing the per port reservations and providing more RAM to the common pool. (BTW, I believe this was how the even earlier 3550 managed its buffer resources.)