Parent Queue Limits do not apply.

I am attempting to create a two child queues with one parent queue. One queue catches traffic with a packet mark and the other catches everything else. I would like the parent queue to limit the total bandwidth for both child queues. In the example below, 10.0.3.4 is limited to 10M, 10.0.3.4s is limited to 3M, and 10.0.3.4.g is limited to 10M. I am able to consume 13Mbps with this setup and the parent queue displays this rate while in use. It seems that once a queue becomes a parent queue, limits no longer apply. The only way I know how to do this is with two routers.

add name=10.0.3.4 queue=pcq-upload-extended/pcq-download-5-test target=10.0.3.4/32
add name=10.0.3.4s packet-marks=heavy_traffic parent=10.0.3.4 queue=pcq-upload-extended-streaming/pcq-download-extended-streaming target=10.0.3.4/32
add name=10.0.3.4g parent=10.0.3.4 queue=pcq-upload-extended/pcq-download-5-test target=10.0.3.4/32

I’m attempting to address bufferbloat on our network. We have excess bandwidth and are not currently oversubscribing. However, user can reach the capacity of their purchased plans, which is where we wish to begin shaping traffic for a better user experience.

The solution we are being recommended is a third party product that will perform modern queuing like cake or codel designed to address latency in connections since Mikrotik does not yet support these.

Child Queues and priority seems to be Mikrotiks means to address this for now. However, I’ve not been able to create these child queues and have them overall limited by a parent queue to match purchased bandwidth.

Does anyone have any suggestions?

Currently we use PCQ for all clients using simple queues, a queue size of 10, and a classifier that results in one queue per client address (default setting). Our interface queue is multi-queue-ether-default with a size of 2500. The router is serving 1000 unique addresses. We’ve experienced queue bottlenecks in the past as a result of our interface queue size. Hardware-only, the default setting results in extreme packet loss.

Try to setup 0.0.0.0/0 as target IP for child queues.

parent queues is responsible for distributing the bandwidth, not limits

if you are using PCQ, then you should not have child queues, the system will automatically create sub streams with limits for each client based on the pcq queue type configuration, here you can specify a limit for all sub streams as it is not a parent queue

Unfortunately it is the same result. The parent queue does not bandwidth limit the connection, but does display the total of the two child queues as a statistic.

The purpose of the child queues are to distinguish between bulk traffic (streaming/downloading) and general traffic so that one doesn’t slow the experience of the other. I wish to place limits on the bulk traffic to allow the general traffic to pass with the lowest amount of latency. My current child queues are effectively separating this traffic and connections are perceivably faster. However, keeping the clients tied to a total purchased service rate on the same router is the issue. Currently, the only way I know how to do this is by limiting the clients total throughput with another device. This could be a second router or a queue on the CPE. I would like to be able to do this on the one router. Or better yet, have a queue type designed to address bufferbloat, which I think we are hopeful will come with version 7 of routerOS.

Your mention of PCQ inspired me to try other queue types, which do allow the parent to limit the total throughput. I see now that the manner in which PCQ provides limits is not compatible with what I was trying to accomplish. So far, RED appears to provide the best performance. Thanks!

Final Update:
My issue was due to the way PCQ limits streams. To use parent queues to limit throughput required that I use a different queue type. Also, RED may have performed better than PFIFO, but it did not perform as well as SFQ when testing for latency under load.

ncats can we contact each other? I would like to have help on pcq queues.