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.


Can someone tell me why?


I<m trying to reproduce it with no luck.

no body?

please post all your queue configuration, and statistics of the queues

Try giving higher Priority to VOIP child queue. For example leave other traffic as 8, put voip as 2

please see the code and the picture :



https://docs.google.com/document/d/e/2P ... utyJ8C/pub

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.

please see the code and the picture :



https://docs.google.com/document/d/e/2P ... utyJ8C/pub

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.

change "limit-at" in D-no-mark to 100M
change "limit-at" in U-no-mark to 10M

please share queue type of all queues and the specific parameters of each queue type you use

please see the code and the picture :
https://docs.google.com/document/d/e/2P ... utyJ8C/pub

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.

Please don't be so mean to me. I though it was use full info since the picture was only to show you that I have dropped packets.

Yes I have a fiber connection not dedicated but very stable and constent 200/30

The router is a CCR1009 running v6.37.1. I don't want to upgrade now since P2P is absent.

here is me full print QOS :

**** Voip_Network is my voip provider address range

ip firewall mangle export :
queue tree export :

look like you are using "default small" queue type, change it to "default" and modify size from 50 to 5000 packets


please share your results

50 to 5000 , are you talking about bucket size?

50 to 5000 , are you talking about bucket size?

@ checito is referring to Queue size. I also mentioned this in my last post. In winbox look at "Queue Types" tab under Queues menu item. Also read:

https://wiki.mikrotik.com/wiki/Manual:Queue#Queue_Types

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.

thank you

@checito
@stoser

for helpfull comment. I though that smaller pkts help voip for low jitter and less delay. Ill give it a try and post results here.

no more dropped packets. I'm trying queue size to 1000 pckts.

p2p option was capturing lots of false positives, so it was removed, i suggest to get rid of any configuration that uses those options.

I'm glad to know you've had good results

p2p option was capturing lots of false positives, so it was removed, i suggest to get rid of any configuration that uses those options.

no I don't use p2p


Bigger Queue size fix my problem.

I though that smaller pkts help voip for low jitter and less delay. Ill give it a try and post results here.

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.

Kind regards

not sure, you suggest to make lower queue size for voip? Priority already set to 1 for voip an 8 for generic data.