I have a 25Mbps/25Mbps symmetrical fibre line (pppoe1), and have been testing cake queues with good success recently

But today, while downloading some torrents and a game on a playstation (several demanding concurrent connections from different hosts on my LAN), I then noticed that the queues seemed to lose control over the download shaping, and actual download could be nearly twice as much as the queue limit... This seems to almost defeat the point of using queues especially if your queues were configured with tight margins to actual line capacity when first setting everything up and everything seemed fine at the time..

To test the theory (and rule out cake as a problem), I created a new simple queue using default queue type, with hard limit of 5Mbps. The problem persists as per screenshot (I manually enabled the queue where the left graph starts showing 5Mbps traffic):
Here we can see that the queue is showing 5Mbps traffic cap, while in reality pppoe1 is doing closer to 9Mbps..

The simple queue graph shows that it is shaping to 5Mbps and doing its job correctly from the moment it is enabled, while actual interface traffic shows a different story (steady 8+Mbps of actual traffic passing through). I confirmed with a torch of pppoe1 that all the incoming traffic is flowing to the bridge, so in theory it should be going through the queue too?

At first I thought it was maybe incoming UDP, but I've blocked UDP traffic and it's still forwarding the same throughputs.

Fasttrack is disabled, and disabling hw offload on bridge ports also doesn't seem to have any effect with this. Can anyone point out what I may be missing, or is this normal behavior of queues ??

Rule in question is as follows:

Early bump just to emphasize my bepuzzlement with this one...

I've also now added the following rules: Looking at the traffic passing through those rules, I could confirm:
1) only about 100kbps (negligible) coming to "input" chain
2) actual 8Mbps passing through from the pppoe to bridge interface

So I still can't understand how the QoS rule shows a clean 5Mbps limit but in reality there's 8mbps+ flowing from pppoe1 to bridge_lan ? it's also tricky to debug because there are hundreds of torrent connections in the torch so I can't figure out if it's just some connections being "missed" by the queue, or cumulative connections being improperly shaped by the algorithm

Maybe I'm just impatient, but no responses yet leads me to believe that this could be some kind of bug ? Surely not? ... I guess I'll need to file a support ticket if this gets no community feedback

Ros v7.3beta37 although i doubt that makes any difference.

Anyone a bit more experienced with QoS know whats going on here , or is this a bug?

Change queue type to ethernet-default

Exactly same issue here for some time, sent numerous tickets and talked to many people never found answer or proper solution.

This happens the most with downloaders like Epic games or Steam or even worse case with Adobe Products downloader which opens a lot of simultaneous https connections to server.

Anyone can test this for them self just install https://creativecloud.adobe.com/apps/do ... tive-cloud with free account and try download any product.

Set simple queue with your pcs IP as target and make max limit for example 10mbit, it will actually download near 2-3x times more for this kind of traffic but If you run speed test it will 100% respect limit.

Same issue with packet marking and queue tree.

Change queue type to ethernet-default

Tried every possible queue type, bucket sizes, routeros versions past few years, empty routers with zero config just ONE simple queue and it still makes no difference for this kinda of scenarios.

keep in mind that on ip networks we don't have any direct control of packets you are receiving, if a packet is sent to you it will reach your router no matter you do what

after traffic reach your router then you apply limits and the traffic passing is where you can see your queue limits applied

So why do queues work?

because most ip applications have mechanisms to detect the available bandwidth to regulate the packet flow, so when a queue put some packets to wait or drop it to regulate bandwidth the application detects that and regulates itself the flow

Change queue type to ethernet-default

Tried every possible queue type, bucket sizes, routeros versions past few years, empty routers with zero config just ONE simple queue and it still makes no difference for this kinda of scenarios.

Ditto. I tried ethernet-default and still the exact same phenomenon. Relieved to see I'm not the only one confused by this. SUP-81506 opened with support, hopefully we can get some clarity about this.