Hi, I made something simple in my network. I made A queue for a specific ip followed by 2 child queue.
The Parent is set to 50 MBPS up and down .
Voip child queue to 2mps up and down
Another child queue for other trafic. Wich is set to 45M up and down.
I made a simple mangle rule to identify voip data.
Other trafic is in fact no-mark traffic
So everything was fin but I got upload dropped pckts for no specific reason. Queues wasnt maxed.
I was on the phone then got cuting voice then I noticed dropped upload packets.
As you can see, SIP-VOIP child queue has dopped packets and that is normal since I maxed it earlier. But RTP-VOIP is not normal. IT’s actualy impossible to max this cap, since I only have 10 voip phone here. 80kbs x 10 != 10M or more.
Not a very usefull picture … You could at least have enlarged the column widths so that the statistics could be read. Too many “…”. How am I to see what ratio of dropped packets you have when half of the number is hidden? You went through all of that trouble, and didn’t spend the last 5 seconds to post a usefull picture.
You also did not show a print out of parent queue “BR-WIFI”, or “ether1-WAN1”. And you also did not mention if you have any other QOS enabled, or higher priority traffic in other queues, what types of WAN internet lines you have (fiber, dsl, cable), if they are dedicated/guaranteed or can vary … All very usefull information that is missing, and that could have been included in less time than it is taking me to respond …
Reread @checito’s request … Had you posted what he asked for, maybe we could help you.
Based on the few details that have been correctly communicated, try increasing queue size, default-small leads to a lot of dropped packets, especially with high latency internet lines.
In your original post you were using the “default-small” queue type. This is equal to a queue size of 10 packets. This is way too small for a saturated line. If the queue length is not long enough, packets just get dropped. With a stateful protocol, the packets are then re-requested, which adds latency but works well enough. Imagine what happens with a stateless protocol …
This is also why I want to see your statistics. Queue size is the main reason why packets are dropped, and it would be interesting to see the percentage of dropped packets in all of your queues. Show us “TOTAL downloded packets”, “TOTAL uploaded packets”, “Upload Dropped”, and “Download Dropped” for all queues.
Also Increase the queue size to a large number and test. I use up to 2000, not quite as high as @chechito recommended, but test out different large values.
Queue size is the maximum number of packets that the queue can have. IT IS NOT the packet size. Packets that come into the queue in excess of the queue size get dropped, and therefore do not consume any more cpu resources, and do not add more to latency. You should give high priority (low priority value, like 1 or 2) to voip queues so that they get processed more quickly and therefore do not get very long, and choose the lowest queue size that results in very few dropped packets. You should give lower priority to non-voip traffic, and a much lower queue size. That way, when there is a lot of non-voip traffic, the non-voip packets get dropped, and need to be re-transmitted, thereby not clogging up the queue processing.
It is like when there are a few lines at the bank, all going to the same group of bank tellers, and each line is for a different priority level of customers: Let’s take the simplest case of 2 priority levels. One line is high priority, and those customers can use the first available bank teller, but every nth customer must yield to a lower priority customer. The other line is low priority, and they can use a teller only when there are no high priority customers waiting, or after every nth high priority customer, whichever comes first. If you consider this for a moment, it becomes obvious that It is beneficial to the high priority customers to never get dropped (not allowed into the bank). It is also beneficial to the high priority customers to have the low priority customers get dropped. When and how exactly to drop, and the value of “n” is highly specific to your circumstances, and up to you to configure.