One of the most difficult ideas for people to grasp is how the bursting works in MikroTik. The main thing to grasp is the relationship between the 4 things that affect bursting. I will attempt to describe that relationship here. You are left with the task of testing this relationship to affect the results you seek. :-)

The 4 parts of a queue that are involved in bursting are: burst-limit, burst-time, burst-threshhold and max-limit. The documentation (last time I looked) refers to limit-at instead of max-limit, but that is somewhat misleading. I will summarize first, then try to put forth an example.

Here is the relationship of the 4 parts. A queue is allowed to burst up to the burst-limit as long as the average speed of the queue is less than burst-threshhold as calculated over the past burst-time seconds. Once the average queue speed is higher than burst-threshhold, the queue speed is dropped back to the max-limit. NOTE: If the queue would otherwise only be allowed the limit-at speed, that is the speed of the queue. In other words, if the bandwidth available to the queue is such that the limit-at value should be imposed, then that is the speed the user will drop back to. HOWEVER, it should be noted that bursting would not have been possible under this circumstance in the first place, since bursting is available only when bandwidth availablility permits it in the first place. Therefore, the fallback speed would (except in extrodinary circumstances) be the max-limit value of the queue.

Let us put some numbers to this understanding. Assume the following:

  • burst-limit 100k
  • burst-threshhold 50k
  • burst-time 10s
  • max-limit 25k


(I know these numbers are silly, but these are easy to work with. ;-))

The queue is idle until a download starts (at least let's suppose this "perfect" scenario for this example). Since the average speed has been 0, the queue is allowed to run 100k. After 1 second, the past 10 seconds speeds are: 100k, 0,0,0,0,0,0,0,0,0. Averageing these all together yields 10k. This value is below 50k, so the queue is allowed to continue bursting. One more second, the numbers look like this: 100k, 100k, 0,0,0 (and so on), yielding an average of 20k. After 4 seconds into the download the average would be 40k. The next second would make the average 50k, which exactly matches the burst-threshhold. The queue would be allowed to continue bursting until the next calculation. 6 seconds into the download, the average goes to 60k, which exceeds the burst-threshhold, and the queue would be limited back to 25k (max-limit). Now, you can carry this calculation out and see a point in the future where during this same download, where the average would fall below the burst-threshhold (since the queue is now limited at a speed LOWER than the burst-threshhold). Once this happens, the queue is allowed to burst again until the past 10 second average is, once again, above the threshhold. This configuration would "sawtooth" until the download finished.

Let us consider, now, these numbers:

  • burst-limit 100k
  • burst-threshhold 50k
  • burst-time 10s
  • max-limit 75k



Following the math above, you can see that this queue would burst for a short time (about 6 seconds) and then be limited to 75k. Since, if the queue is running full speed, the average would not drop below the 50k burst-threshhold, this queue will not "sawtooth" as shown above.

I hope this has been helpful. This concept, once you grasp it, is not that hard. Thanks for reading.