What exactly mean "priority doesn't work without limitation":

1) priority doesn't work without limitation in parent queue;
2) priority doesn't work without limitation in each child queue;
3) both?

Tx

Nobody knows?

read this topic: http://forum.mikrotik.com/viewtopic.php?f=2&t=27555
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.

read this topic: http://forum.mikrotik.com/viewtopic.php?f=2&t=27555
and watch this video: http://www.tiktube.com/?video=214

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.

A queue in green state means that it has not yet reached the "limit-at" level.

color have nothing to do with 'limit-at' value:

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!!

And that NO PRIORITISATION happens until Max-limit has been reached.

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".

prioritization works between 'limit-at' and 'max-limit'.

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:

'max-limit' is not specified - so there's nothing to reach for leaf queues =)

Yes, according to "...to child queues so that they are able to reach max-limit".
But "Priority is responsible for distribution of remaining parent queues traffic..." tells me something different. So, if we don't have limit in parent queue, we have no remaining traffic in it too.

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:

Yes it will work with only max-limit on the parent queue, and just priority for the child queue. Priority does work with no max-limit on on the child queues.

Things are not perfect though, it can take a bit to 'catch up'. With SIP this can cause a little jitter (audio fluctuation) when starting a large download. So I set the max-limit on the child queues to leave a little headroom for VoIP.

Limit-at is 'guaranteed' bandwidth. The sum of all child limit-at must be lower than parent max-limit.

http://wiki.mikrotik.com/wiki/Manual:Qu ... Properties

So, if we don't have limit in parent queue, we have no remaining traffic in it too.

no, in that case remaining traffic is unlimited

Yes it will work with only max-limit on the parent queue, and just priority for the child queue. Priority does work with no max-limit on on the child queues.

any confirming screenshots?..

No screenshot here but I can confirm that priority works when max-limit is set for parent q only. In addition if limit-at is set for parent queue child queues are free to go up to limit-at (cumulatively) w/o borrowing from the parent.

EDIT: root queue must have the max-limit for priority to work but limits for child queue's are optional. Borrowing/lending happens in chunks and if slow when tree is more than one level deep so, as it was mentioned, it helps to set max-limit on parent/child queues.

Et voila! That's why I asked this question - the half of Mikrotik community thinks that priority works with "max-limit" on each child queue only, the other half - with "max-limit" on parent queue, and the third half - with "limit-at" only.
But in examples in the manual, we see that "limit-at" is acting before priority to start his work, and also that "max-limit" of child queue does not matter if the parent has nothing to distribute.

So I think rpress is right, and my example will work, but is good more people to confirm.

Our QoS expert wrote this about your discussion:

OK, lets now imagine the situation, that you are loading trailers with boxes (blocks of data sent out by HTB)

Requirements are:
1) you need to load trailer as fast as possible (first and main objective - make latency as low as possible)
2) one kind of boxes have higher priority than another
3) you do not know how much boxes will come in (amount of traffic in next millisecond is unpredictable)
4) you do not know maximum amount of specific type boxes you are allowed to put in (no max-limit)

So how will you fill up trailer so that fulfill 1) and 2) at the same time? Will you load 2nd priority boxes as they come and hope that there will space for all remaining 1st priority boxes? or will you delay 2nd priority boxes until you will be sure that all 1st priority get in??? Ether way you can't get 1) and 2) requirement 100% at the same time.

With "max-limit" you give a specification of how much packets of specific type can be in same trailer.
With "limit-at" you give the amount of specific type boxes you can load without even thinking.


So it is never the question "does the priority work?" it is question - "have you given out all the required values to get it working as you desired?".

And line in manual "Make a note that priority only works if max-limit is specified (not 0)" is correct as most clients are expecting QoS to work the way it can work only with limits specified

What happens on bandwidth fluctuations?
Let's say we have two properly configured upload queues, both limit-at=400K, max-limit=500K, parent queue (WAN) max-limit=1M.
Suddenly the actual bandwidth on WAN drops from 1M to 500K - technical problems on ISP side. Router still expects it to be 1M - how will it behave?

Take a look at last example on
http://wiki.mikrotik.com/wiki/Manual:HT ... e_limit-at

Idea is very simple queues are taking place in HTBs - they have absolutely no idea about real throughput on your link, so on exit HTB will have its 1Mbps, then this 1Mbps will get to your physical link and link will use its queue type (/queue interface menu) to send it out via physical interface. in most case it is simple FIFO, so with similar type of traffic you will get same ratio of queue traffic.

That example describes a different situation - child queues explicitly exceed totals on parent queues, router is aware of that and can make educated decision how to recalculate limits to keep them in proportion.
In the case I mentioned teh router doesn't know about the problem as totals on child queues match parent queue, it's just physical interface that bottlenecks here. My understanding is that QoS will simply break, as the router, assuming it has 1M up, will let both parties to fill interface queue buffer, whoever comes first, thus unable to provide neither guaranteed rate, nor to preserve the proportion.

Setting max-limit to the lowest possible rate would restore QoS but is very inefficient. I would expect router to gradually auto-adjust the queue parameters when the queue buffer is overloaded for some period of time (user could provide the threshold) - that would resolve the problem.

So the question then - what is the best strategy for unstable links?

That example describes a different situation - child queues explicitly exceed totals on parent queues, router is aware of that and can make educated decision how to recalculate limits to keep them in proportion.
In the case I mentioned teh router doesn't know about the problem as totals on child queues match parent queue, it's just physical interface that bottlenecks here. My understanding is that QoS will simply break, as the router, assuming it has 1M up, will let both parties to fill interface queue buffer, whoever comes first, thus unable to provide neither guaranteed rate, nor to preserve the proportion.

Setting max-limit to the lowest possible rate would restore QoS but is very inefficient. I would expect router to gradually auto-adjust the queue parameters when the queue buffer is overloaded for some period of time (user could provide the threshold) - that would resolve the problem.

So the question then - what is the best strategy for unstable links?

Well said edmidor; You hit the nail on the head were it only gave me a feeling that example is not what macgaiver had in mind to explain.
Anyway, I can only confirm that when the physical capacity drops the QoS collapses.

I have a loadbalancer with several adsl lines. Behind it my main gateway with the QoS (rb1000). I learned the hard way that when one or two of these adsl lines go down (Yes, that CAN happen, even 3!) and I don't adjust the max limit for the parents (and also the childs since I set these too) customers complaints starting to stream in.. downloads are still possible but real live traffic and even browsing becomes very erratic.
I set the limit for the new situation and normal functionality comes back.

One bypass to create some automated adaption to increasing/degreasing physical line capacity would be that I set the important child queues to lower (but still sufficient) max. limits and only the low priority childs (P2P and all leftover) for the full max. limit.
If now total capacity of max. physical limit degreases, only this traffic of low priority queues are suffering. The others still have a max. limt within physical boundaries (Until I loose even more lines)

Not an ideal situation......

I can remember I once saw a script fm someone that had a solution for this. Can't find it that fast..

I would say this feature is worth adding into RouterOS core, IMHO.

Router knows the actual bandwidth going through WAN interface, and it also knows the max-limit on the queues chaining from/to this interface. There should be not a big deal to make it to auto-adjust the limit-at and max-limit accordingly on all downstream queues where 'auto-adjust' enabled.

I would say this feature is worth adding into RouterOS core, IMHO.

I agree!

Router knows the actual bandwidth going through WAN interface,

Well, is that true? How does the router know? I don't even know!
I have a contract that says I have "X" bandwidth
Then I have some modems that show me the connected speeds of the lines.
But real throughput is always much lower then these. But how much? It fluctuates. It has to do with how saturated the rest of the adsl ISP's network is I guess.

How to test the physical throughput of the ADSL lines? Running bandwidth tests? Well, to do that all the time, or regularly, just to see how the capacity is? During these tests the available capacity for users is undermined heavily...

So, how to tell the ROS what the real throughput is? Rough guess...

I take 80% of what I see the modems are connected to in download and 90% of the upload. (It seems upload is better in holding its capacity then download. And I am short of upload so have so squeeze a bit more here...)
It works relatively fine for me. But at time the adsl lines are still crap. Probably nothing I can do about! (Well, I ordered a symmetrical lease line. 4Mb up/down with 99% guarantee.)

The router does not know. If you have an ADSL line brought in via a modem in bridge modem, the connection between router and modem could be gigabit or fast ethernet, but the ISP only gives you 5 meg. If you have a metro e circuit that also could be arbitrarily rate limited at the other end.

If you lose circuits, you'll have to adjust the queues accordingly by hand, or by a script that tracks how many lines are down at any given point in time runs periodically via the scheduler. I doubt there's a generic silver bullet for that, though. Sometimes lines will be physically up but not pass traffic (connection to ADSL modem is up, but modem uplink is down), sometimes even the remote gateway will ping but its next hop is dead.

It doesn't know your available bandwidth, but it knows how much data is being passed through its WAN interface at every moment of time.
If top queue buffer is full for some period of time, and you're dropping packets, it means WAN interface passes as much as it can - and at that moment this is the max physical bandwidth available to you from ISP.

If at the same time the number from the statement above is significantly (user defined threshold) lower then the declared bandwidth (max-limit in top queue), it's enough to conclude that this is the exactly described situation, and router can go and temporarily set the run-time value of max-limit on relevant queues closer to the actual physical limit at the moment. When the bandwidth drop end it can move max-limit back.

It doesn't know your available bandwidth, but it knows how much data is being passed through its WAN interface at every moment of time.
If top queue buffer is full for some period of time, and you're dropping packets, it means WAN interface passes as much as it can - and at that moment this is the max physical bandwidth available to you from ISP.

wrong?.. if your modem is connected to your router via 100 Mbps link, all packets are sent to the modem. and then the modem can drop packets in case of ADSL become congested. router doesn't know about dropped packets

WirelessRudy, why do you use total limiting for all your lines? maybe you should limit per ADSL line? so then if one link is down - this queue is simply not used =)

The point is that the queue will reside on the DSL modem and not on the MikroTik router... You need visibility as to the queued packets inside the modem. The MikroTik will not be the one dropping packets, it could probably figure it out with TCP but UDP will have no indicator.

Even if you have all this, you only get QoS for outgoing/upload.

You can set a script to ping some remote IP and when ping times go up that means packets are being queued somewhere. Then you need to figure out if the packets are being queued on upload or download. In any case this is a complicated proposition.

Something like this perhaps would be interesting:
http://www.scanditek.dk/Admin/Public/DW ... e_DQoS.pdf

WirelessRudy, why do you use total limiting for all your lines? maybe you should limit per ADSL line? so then if one link is down - this queue is simply not used =)

I am not limiting on my lines. The limits are for each child. Each child represents a service type. This is QoS.

I have a third party loadbalancer (peplink) with 7 WAN ports (5 in use with ADSL) and one LAN.
The LAN is connected to my rb1000's WAN (0r "public") port.
From the point of view of the rb1000 I just have one public connection with the aggregated sum of all adsl lines as its capacity.
If now one or some lines of the LB go down off course this total aggregated sum becomes lower.

Since the QoS in rb1000 uses the total aggregated sum for max. limits, I have to adjust these when the total aggr. sum becomes less due failing adsl lines.

The point is that the queue will reside on the DSL modem and not on the MikroTik router...

?? As far as I know adsl modems usually (not by default and only possible in more advanced types) are not queuing. And in case they are just functioning as bridge (what is preferred option for ISP) definitely that option is not there.. at least not in the range of modems I have seen so far, even so called ´professional´adsl routers.

You need visibility as to the queued packets inside the modem. The MikroTik will not be the one dropping packets, it could probably figure it out with TCP but UDP will have no indicator.

Even if you have all this, you only get QoS for outgoing/upload.

Sorry, but this makes not a lot of sense to me.

You can set a script to ping some remote IP and when ping times go up that means packets are being queued somewhere. Then you need to figure out if the packets are being queued on upload or download. In any case this is a complicated proposition.

Ping times don't necessarily means bad lines. It can be the server or just the internet as a whole performing poor. And it looks to me impossible to find out if ping times are "queued" (= package dropped) somewhere on the way to remote server or on the way back. Ping give the return time. Not the time needed to reach a server and a time needed to come back?

Something like this perhaps would be interesting:
http://www.scanditek.dk/Admin/Public/DW ... e_DQoS.pdf

I red the article. To me it looks they are doing nothing more then a good configured QoS in ROS can do. Their so called "Dynamic QoS" is what you can do by setting proper limit-at and max-limit values with the right priorities for different queues. I am not saying mine is the ultimate but so far I am pretty happy with it.
I would like to see their OS. Wouldn't be surprised if this is MT-ROS!

Chupaka: Can you shine your light over this topic of mine please?
http://forum.mikrotik.com/viewtopic.php ... 47#p200747

It comes close to this discussion and might look a stupid question at first (hence no reaction received yet, so I changed the title) but can be worth for others following this topic too.

rgds.

wrong?.. if your modem is connected to your router via 100 Mbps link, all packets are sent to the modem. and then the modem can drop packets in case of ADSL become congested. router doesn't know about dropped packets

Why would it matter? You still have your real time WAN interface throughput at one hand, and max-limit on that queue in the other hand. Assuming they initially set to match, if you see actual throughput dips for more then X seconds - then router could temporarily lower max-limit to keep everything in proportion...

That example describes a different situation -

I used that example to show what happens to traffic if your HTB pass more traffic than your interface can handle.
In that example HTB handles out 20Mbps, but link is only 10Mbps, so interface queue was used to make 10Mbps from those 20Mbps.

My understanding is that QoS will simply break

Correction - it will not work as you expected, but it still works as you configure it, so I disagree with "breaks" part.

Router knows the actual bandwidth going through WAN interface, and it also knows the max-limit on the queues chaining from/to this interface. There should be not a big deal to make it to auto-adjust the limit-at and max-limit accordingly on all downstream queues where 'auto-adjust' enabled.

Only way this can happen is if you employ this guy: http://en.wikipedia.org/wiki/Nostradamus
All traffic is already gone trough the HTBs when it reaches possible bottleneck (outgoing interface, or next device)

Correction - it will not work as you expected, but it still works as you configure it, so I disagree with "breaks" part.

That implies it's technically possible to configure the router QoS to handle sudden bandwidth dips without manual intervention.
So far I didn't see anyone proposing a solution. And if there's no way for the router to handle it - it means exactly "breaks"

Only way this can happen is if you employ this guy: http://en.wikipedia.org/wiki/Nostradamus
All traffic is already gone trough the HTBs when it reaches possible bottleneck (outgoing interface, or next device)

You don't need to predict future here - all you need is some stats, and look into recent history - and ROS can do it perfectly.
You can build a signal, and its nominal threshold of the amount of traffic passing when the queue is in 'full' state; you can detect when threshold is breached. You can correlate more factors to detect bandwidth fluctuations more precisely - thanks ROS it keeps stats for everything.

That would be highly useful not just for dynamic QoS, but as basic monitoring mechanism...

Does your algorithm covers situations when clients don't use your link 100%? How will you determine is it actual drop in your up-link performance or just drop in requested traffic by clients?

I can see how algorithm will reduce the max-limits, but i fail to see how will you get them up again. What will trigger this increase? Especially if bottleneck is next network device.

Good question! If we lowered max-limit, and the bottleneck on the "next device" has gone, router has no way to know that, as it now limits itself with the new low max-limit.

I see two cases here:

1. Traffic is low as there no demand
The entire idea of dynamic lowering of max-limit is relevant only when clients compete for bandwidth, so router needs a "reality check" to be able to manage QoS in changed conditions. So, if traffic went low because there's no demand, and it keeps going like that, router can simply set max-limit to its initial value

2. Bandwidth is fully consumed
To detect the bottleneck is gone, we need to set max-limit a bit higher then the actual throughput. Difference should be small enough so it won't affect QoS. When bottleneck is gone, throughput goes up to the max-limit, which means conditions improved, and router can "try" to set max-limit back up and see, or alternatively do it gradually in steps.