We have made documentation for the new Token Bucket option, it is new exciting and powerful feature for queues and bandwidth limitation. Detailed information and configuration example are here,
http://wiki.mikrotik.com/wiki/Manual:HTB-Token_Bucket_Algorithm
Short diagram explaining Tocken Bucket algoritm,
Very interesting.
Thanks Mikrotik.
After reading this i played around my test setup and realized that there setup “large parent queue bucket size, small child queue bucket size” are beneficial in situations when you have many child queue - now child queue that just started to use traffic in already saturated environment have much easier time to get initial traffic.
In short - queues got more responsive to usage changes, cause parent queue have an extra tokens for “unexpected expenses”
Also, i’m starting to thing old burst is starting to become redundant, this implementation with just one option is easier that old 3 option solution anyways.
Large Queue Bucket
Lets try to apply the same logic to a situation when bucket-size is at its maximal value:
/queue tree
add name=download parent=Local packet-mark=PC1-traffic max-limit=10M bucket-size=10
add name=upload parent=Public packet-mark=PC1-traffic max-limit=10M bucket-size=10
In this case bucket-size=10, so bucket-capacity= 10 x 10M = 100M
If the bucket is full (that is, client was not using full capacity of the queue for some time), the next 100Mb of traffic can pass through the queue at an unrestricted speed.
So you can have:
20Mbps transfer speed for 10s
60Mbps transfer burst for 2s
1Gbps transfer burst for approximately 100ms
i cant understand how seconds are calculated in the above example. why is 10s for 20mbps?
if 100mb traffic can pass through at an unrestricted speed, why is 20mbps for 10s?
is there an excel formula so we calculate easy how many mb or sec will be the burst result?
Because in 10 seconds, you will have earned another 100M of tokens.
It only takes 5sec @ 20M/s to spend 100M of tokens…
BUT during that 5 sec, you also earned 50M more tokens…
That 50M takes 2.5 sec to spend, while earning another 25M of tokens…
etc…
If you want a formula, it’s basically this:
Time to empty/full = absval(Bucket Size * Token Rate / (Data Rate - Token Rate))
Time means “fill from empty” if the data rate is below the token rate, and it means “empty from full” if data rate is greater than token rate.
If they’re the same, it’s divide by zero, so avoid that. 
Obviously this formula assumes a silly thing - a constant data rate.
Ultimately, though, it’s not right to think in those terms - data rates are almost never constant, and it’s impossible to predict whether a stream will “save up” its tokens or use them constantly, etc.
We are using Simple Queues for each customer, some Mikrotiks have 400-500 of them. We enter the customer name, IP address, then select a PCQ on the advanced tab to select the Download/Upload rate, the PCQ’s have a burst timer where they can for example go to 7Mb for 40 minutes, then drops to around 1/2 the burst rate, around 3-4Mb/s.
After upgrading firmware’s we’re noticing now the ‘bucket size’, which all are defaulted to 0.100, do we need to change anything to keep everything running 100% the same, or is 0.100 default not have any change on our existing setup?
bucket size (0..10, Default:0.1) - queue option was added in RouterOS v6.35, before that it was hard-coded to a value of “0.1”.
As shown in the documentation, prior to v6.35, it was hard-coded to 0.1.
So after upgrade it shouldn’t behave differently since it keeps the default value: 0.1.
Can u plz give me an example on how to use it on an 20/1 adsl connection and setting max limit to 10 in 1 of 8 queues in simple queue? What numbers offers me what?
ty in advance
anyone not yet? good job.
I suspect that this feature is not working and u just shame to admit it. it is not bad if is not working. just someone write something, for us to stop waste our time.
So given the above, if we want to have a setup with almost no burstiness (we have a downstream network that polices the traffic at 10ms intervals!), really I need the bucket size to be only big enough for one packet (1500 bytes). So at 100Mb would be a bucket size of 0.00012 (0.00012*10000000/8 = 1500). Pity you can’t specify the size directly (in bytes).
Is that right?
I have just realised what this parameter actually is. It is really “bucket-time” - the amount of time it will take to fill the bucket up from empty when there is no packet flow. The number of seconds of token flow (which is set by the max-limit/limit-at etc) that can be stored in there (after which the tokens overflow). It also appears to have a lower limit of 0.001 - i.e. 1ms, which is good enough for what we want.
Is there any benefit playing with Queue bucket-size to overcome DOS/DDOS and queuing 100% cpu usage ? If yes how ?
Time means “fill from empty” if the data rate is below the token rate, and it means “empty from full” if data rate is greater than token rate.
does bucket size work to unlimited queues? Or i have to set limits? if not, it will very good feature to work under unlimited queues… i think.
set burst time only, unlimited the other values and borrow buckets from parent for ex.
does this work?
Does not the diagram say it has a burst limit and a burst limit at max, meaning they are giving out a range. And not something unlimited?
Hi all!
I’m a newbie here, so I’ll try to explain my problem in ROS therminology as close as I can. My problem is “a ghost” property of queue tree/simple queues. I actually spent 12+ hours yesterday reading WIKI, manual, example scripts etc. but I couldn’t find a way to do a realy simple thing: how to set the “limit-at” value be higher then “max-limit” 
Can anybody here enlight me so I can say : hey, i’m stupid, because otherwise my so far good opinion of ROS programmers will be very degraded. This post here is mainly reason to join forum, and here is what I don’t like: this pic below. In this algorthm, will never be engaged , or I’m blind. You tell me…
[admin@GoranmarGW] > /queue tree add name=test_queue max-limit=10M limit-at=20M parent=global
failure: -max-limit less than -limit
[admin@GoranmarGW] >
And Mikrotik says:
Indeed, looks like ‘Limit-at larger than max-limit?’ is always ‘no’ 
Why do you want to set limit-at higher than max-limit?
Max limit - Max bandwidth client can use;
Limit at - Is the minimum bandwidth which should be available for client if there are multiple connections from different clients at the same time.
But why is this case on the diagram then?
I dont ! My point is HUGE error in logic of the algorithm. But the irony is even better, since queues are behaving almost as digram shows. In my 10+ years experience with ROS, limit-at value never had definitive and predictable effect on queue beheviour. It seems that what ever I wanted to acomplish with queues, the best way was trial/error method, since documentation like this above is not of help. Sadly…