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
Laugh - although for the last couple of years I've been working as a "wage slave", for several decades before I had worked "free lance" (perhaps as an "expensive consultant" ) who on the network front pushed QoS.
In my last consulting gig, the client's senior WAN engineer didn't believe in QoS mumble jumble until one night a 7500 reloaded itself and dropped all its QoS settings. Next morning, the engineer noted his phone was lit like an XMAS tree with everyone complaining what's wrong with the network. He "found" the reload, discovered the missing QoS statements, reconfigured the device with QoS, and his phone stopped ringing! He then told me, why this QoS stuff really does something. (laugh)
That particular client was a large international. Interestingly, it was noted the other two regions kept buying additional WAN bandwidth, yet users kept complaining about network performance. Our region had very little bandwidth growth, and little user network performance complaints (well after our region implemented QoS ).
BTW just being an "expensive consultant" doesn't mean you really know what you're talking about, although it does probably mean you wear nice threads.
On LANs, bandwidth upgrades can indeed be a less expensive solution. On WANs, though, often QoS might be an less expensive solution.
On LANs, bandwidth, latency and buffer resources are such, if you need to implement QoS, it's likely more to deal with prioritization of packet drops rather than packet prioritization. I.e. ". . .except that the VoIP physical ports were not configured with a "priority queue out" statement, so not really fulfilling the requirements." might not really been needed, and PQ can starve all bandwidth from other queues."
Video can be very bandwidth bursty. It also may not try to regulate its bandwidth usage. If you're dealing with streaming (i.e. not RT) video, sufficient buffering usually is often all you need (NB: an issue with 3560/3750 series, they all seem a bit short on buffing resources). If you're dealing with RT video, generally you need sufficient bandwidth so there's no or little need to buffer (NB: which might be up to about 4x the video's "average" bandwidth).
For your 3750X, optimal buffering is obtained by disabling QoS, but that also disables different QoS treatment for different traffic types. If you (really) need different QoS treatment, you're very likely going to need to override QoS default settings.
On a 3750X, using the 2nd queue-set allows you to define different resource allocations. So, for example, you might insure your video server's port really does allow whatever queue is being used for video to obtain about 100% of buffer resources. Properly done, the reduction in drops might be dramatic.
