@FuadG wrote:
When I use this formula:
Percentage of output drops = Total output drops / Total output bytes X 100 I get an extremely low value.
Where you get that formula?
First, you need determine whether you want to count drops in bytes or packets.
Second, using either bytes or packets drop % = total drops / (total drops + transmitted) * 100
Often when taken from interface counters, you're using values over hours, days, weeks, even months, so the percentage can be much, much (much) lower than during a short interval.
Drops count are no longer increasing on 9300 switch in the table from my initial post, but Enqueue numbers are increasing constantly - is it something abnormal or it is as it should be?
Before packets are dropped, they should be enqueued. Drops are overflows of queues.
Usually enqueuing a packet is better than dropping a packet, but not always. Enqueuing adds latency. For VoIP, both drops and latency (and jitter) are bad.
With VoIP, a dropped packet loses some actual voice sound. A too delayed packet, might be ignored (logically dropped), but the delayed packet can further delay other VoIP packets, which may cause those to be ignored too.
In contrast to real-time VoIP or video, steaming voice or video initially delays/buffers a few seconds. This initial pause, assumes, most of the time, the sender can send faster than needed, but temporary transmission delays are made up by the buffered data already received. For such applications, delay and jitter are covered by the buffer, but packets drops are still problematic.
BTW, any of you phones generate MOS scores?
If your VoIP is properly directed to a PQ queue, it shouldn't normally be dropped or enqueued.
What I don't know is whether your VoIP traffic is properly classified and treated.
