What exactly mean “priority doesn’t work without limitation”:
- priority doesn’t work without limitation in parent queue;
- priority doesn’t work without limitation in each child queue;
- both?
Tx
Nobody knows? 
read this topic: http://forum.mikrotik.com/t/is-priority-really-working/24459/1
and watch this video: http://www.tiktube.com/?video=214
On come on Normis.
Sooner or later this forum is going to turn into one of those sites well people are too bloody scared and intimidated to ask anything.
As it happens, I got prioritising to work together with PCQ without any questions to the forum, but by weeks of reading the same documents over and over again, not because I am bloody stupid, but just because the documents were not written well enough.
I think what this guy may want to know is a similar question to my own.
Does the prioritisation work when the queue is “loaded” ie when the “limit at” is approached. Or is it simply the case that priority does not happen unless either Max-limit box has an entry and/or CIR.
Note, there may be some of us who simply want to push some types of traffic through our networks before other types! regardless of whether the highway is congested or not.
Well, I read it. And watched the movie too. This phrase (“priority doesn’t work without limitation”) is present in both places, but that’s all, nothing more.
Thank god that you never asked the question about prioritising inbound traffic as that is even more contraversial.
However, if it helps I can confirm that even if the max-limit of the “child queues” is set to within 10% of the parent (maximum pipe size)something happens, but its hard to guess whether when the queue is in the “green state” whether any form of prioritising has started. I understand the following:
0% - 50% available traffic used - green
51% - 75% available traffic used - yellow
76% - 100% available traffic used - red.
So it maybe that no prioritisation begins until 51% of Max-limit. Until we have further input from Normis, I suppose its anyones guess, but the average reply on this subject is from contributors who have mis-understood the question that we have asked.
color of queue is just a color =) it shows current traffic of the queue and has nothing to do with packet processing. you can have red queue with ‘limit-at’ still not reached, and you can have green queue which drops packets
smaller number of priority for the queue which reached ‘limit-at’ traffic is just higher possibility to borrow the bandwidth from parent queue. otherwise the bandwidth will be borrowed equally
so, ‘priority’ value is used only if you have set ‘limit-at’ value
p.s. I hope, it’s a bit clear - it’s 1:17am %)
Oh my friend, you brought even more confusion, not clearness. In the past, in old versions of the manual, I remember it was written in this way, but look at the new wiki:
"Child queue with higher priority will have chance to reach its limit-at before child with lower priority and after that child queue with higher priority will have chance to reach its max-limit before child with lower priority. "
http://wiki.mikrotik.com/wiki/Manual:Queue
Here again it is not clear whether it is obligatory to set “limit-at” in each child queue, or it will work with max-limit only too. And it is not clear what limitation to put in parent queue.
That’s why I want someone to explain what exactly the quotation above mean.
A queue in green state means that it has not yet reached the “limit-at” level.
As you know “limit-at” is CIR, the bandwidth always guaranteed to the client.
This means that no priority would take place until queue will reach it’s yellow state (above CIR)
because the guarantee you have provided to the client will still have higher priority.
That’s how I see it.
and this one is just perfect example, ‘limit-at’ is still not reached, but the queue is already red =)
and now Chupaka should link his contact and make public his fees for consultancy…
Bottom line: it is possible to make a lot of interesting queue trees to make queue color change - it is all about HTB. so if you wanna understand what is priority and where those colors are coming from read about HTB, try to understand all examples.
http://wiki.mikrotik.com/wiki/HTB
If we talk about the priority - it is NOT a packet re-sequencer, it probability not to get dropped (higher priority less likely packet will be dropped)
So if there are no limits, probability go get trough the queue is 100% anyway, so priority doesn’t have any point, that is why there is written it doesn’t work
Yes, Chupaka and macgaiver are correct on this matter. In pictures the Chupaka posted, check his Queue parent color. The keyword here is “available” traffic.
So Normis
My question has then kinda been answered.
The pretty colours that have been provided for us in relation to the queue system, serve no purposse excepting to show in 3 seperate colours, whether our queue is at
0% - 50% available traffic used - green
51% - 75% available traffic used - yellow
76% - 100% available traffic used - red.
And that NO PRIORITISATION happens until Max-limit has been reached.
What I originally wanted to know, is either:
a: Does priority happen at any status ie Green, yellow or Red.
b: or Did prioiry start at the point when the queues turn yellow.
So it kind off says that if I just want to prioritise traffic type using this method, AT ANY INSTANCE OF QUEUE status, that it cant be done this way.
Some of you may wonder why I might want to say prioritise a DNS request even when the capacity of my network is low at that point, I JUST DO!!
oops =) …until ‘limit-at’ is reached
prioritization works between ‘limit-at’ and ‘max-limit’. and it’s not the priority of packet, it’s just the priority of a leaf queue in distribution of parent’s bandwidth
Chupaka.
Are you then saying that the queues up top are not actually prioritising any traffic at all because I have NO Limit-AT
There is “limit-at” and it is “0”.
so from 0 to 1900
Thanks Macgaiver.
I think I have it now. Tried 0 but didnt accept entry, so stuck them all at 100k. Since the queues are only borrowing from others when required in order to satisy priorities, in theory for just this simple prioritisation I guess it doesnt matter what value is used in Limit-at.
Now finally, having opened one can of worms and stolen someone elses thread.
Is the grand debate over now, relating to prioritising inbound traffic.
It can be done or it can’t be done?
( I have all the relevant info that suggests how it can be done, but I got distracted by too many debates elsewhere on the forum on whether its possible or not)
it’s possible if your downlink is not congested 
OK, but let’s go back to the manual here:
"We already know that limit-at (CIR) to all queues will be given out no matter what.
Priority is responsible for distribution of remaining parent queues traffic to child queues so that they are able to reach max-limit
**Make a note that priority only works:
\
- for leaf queues - priority in inner queue have no meaning.
- if max-limit is specified (not 0)"**
This slightly contradicts what was said above. Apears that “limit-at” has nothing to do with priority.
I still want to ask, in this case, priority will work or not:
