Try setting up a max-limit

Code: Select all

queue simple add name="Full Speed" target="0.0.0.0/0" parent=none packet-marks="" priority=8/8 queue=default-small/default-small limit-at=0/0 max-limit=5M
/5M burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s

Traffic Shaping Objectives

Traffic shaping operates by measuring and queuing IP packets with respect to a number of
configurable parameters. The objectives are:
• Applying bandwidth limits and queuing packets that exceed configured limits, then sending
them later when bandwidth demands are lower.
• Dropping packets if packet buffers are full. The packets to be dropped should be chosen from
those that are responsible for the congestion.
• Prioritizing traffic according to administrator decisions. If traffic with a high priority increases
while a communication line is full, traffic with a low priority can be temporarily limited to
make room for the higher priority traffic.
• Providing bandwidth guarantees. This is typically accomplished by treating a certain amount
of traffic (the guaranteed amount) as high priority. The traffic that is in excess of the
guarantee then has the same priority as other traffic, competing with all the other
non-prioritized traffic.
Traffic shaping does not typically work by queuing up immense amounts of data and then
sorting out the prioritized traffic to send before sending non-prioritized traffic. Instead, the
amount of prioritized traffic is measured and the non-prioritized traffic is limited dynamically so
that it will not interfere with the throughput of prioritized traffic.


Limits should not be more than the Available Bandwidth
If queue limits are set higher than the available bandwidth, the queue will not know when the
physical connection has reached its capacity. If the connection is 500 Kbps but the total queue
limit is set to 600 Kbps, the queue will believe that it is not full and it will not throttle lower
priorities.

Limits should be less than Available Bandwidth
queue limits should be below the network bandwidth. A recommended value is to make
the queue limit 80-90% of the physical limit. The need for this difference becomes less with increasing
bandwidth since represents an increasingly larger piece of the total.
The reason for the lower pipe limit is For outbound
connections where packets leave the router, there is always the possibility that
might slightly overload the connection because of the software delays involved in
deciding to send packets and the packets actually being dispatched from buffers.
For inbound connections, there is less control over what is arriving and what has to be processed
by the traffic shaping system and it is therefore more important to set pipe limits slightly
below the real connection limit to account for the time needed for queuing to adapt to
changing conditions.

Watching for Leaks
When setting out to protect and shape a network bottleneck, make sure that all traffic passing
through that bottleneck passes through the defined queues.
If there is traffic going through the Internet connection that the queues do not know about,
queuing cannot know when the Internet connection becomes full.
The problems resulting from leaks are exactly the same as in the cases described above. Traffic
"leaking" through without being measured by pipes will have the same effect as bandwidth
consumed by parties outside of administrator control but sharing the same connection.

taken from other vendor documentation and adapted to routeros terminology

this recommendations have worked well for me

Traffic Shaping Objectives

Traffic shaping operates by measuring and queuing IP packets with respect to a number of
configurable parameters. The objectives are:
• Applying bandwidth limits and queuing packets that exceed configured limits, then sending
them later when bandwidth demands are lower.
• Dropping packets if packet buffers are full. The packets to be dropped should be chosen from
those that are responsible for the congestion.
• Prioritizing traffic according to administrator decisions. If traffic with a high priority increases
while a communication line is full, traffic with a low priority can be temporarily limited to
make room for the higher priority traffic.
• Providing bandwidth guarantees. This is typically accomplished by treating a certain amount
of traffic (the guaranteed amount) as high priority. The traffic that is in excess of the
guarantee then has the same priority as other traffic, competing with all the other
non-prioritized traffic.
Traffic shaping does not typically work by queuing up immense amounts of data and then
sorting out the prioritized traffic to send before sending non-prioritized traffic. Instead, the
amount of prioritized traffic is measured and the non-prioritized traffic is limited dynamically so
that it will not interfere with the throughput of prioritized traffic.


Limits should not be more than the Available Bandwidth
If queue limits are set higher than the available bandwidth, the queue will not know when the
physical connection has reached its capacity. If the connection is 500 Kbps but the total queue
limit is set to 600 Kbps, the queue will believe that it is not full and it will not throttle lower
priorities.

Limits should be less than Available Bandwidth
queue limits should be below the network bandwidth. A recommended value is to make
the queue limit 80-90% of the physical limit. The need for this difference becomes less with increasing
bandwidth since represents an increasingly larger piece of the total.
The reason for the lower pipe limit is For outbound
connections where packets leave the router, there is always the possibility that
might slightly overload the connection because of the software delays involved in
deciding to send packets and the packets actually being dispatched from buffers.
For inbound connections, there is less control over what is arriving and what has to be processed
by the traffic shaping system and it is therefore more important to set pipe limits slightly
below the real connection limit to account for the time needed for queuing to adapt to
changing conditions.

Watching for Leaks
When setting out to protect and shape a network bottleneck, make sure that all traffic passing
through that bottleneck passes through the defined queues.
If there is traffic going through the Internet connection that the queues do not know about,
queuing cannot know when the Internet connection becomes full.
The problems resulting from leaks are exactly the same as in the cases described above. Traffic
"leaking" through without being measured by pipes will have the same effect as bandwidth
consumed by parties outside of administrator control but sharing the same connection.

I was running into the same problem and researched all over trying to figure out why my queues weren't being applied. Finally figured out that I needed to disable the fastTrack connection forward rule in the firewall settings. This is enabled during initial setup, so it might be overlooked.