Searched the forums with no luck.

I have 200 internet users. I want to prioritize different types of traffic separatelly for every user. Is it possible on mikrotik?
I have 50% loaded internet connection, in which priorities doesn't work, they're working only when I load internet connection to the max-limit.
Janis Megis presentation doesn't mentioned per-user traffic prioritization, those rules in his presentation are for overall traffic prioritization in global-in and after that - bandwidth control in global-out.
With per-user traffic prioritization it is possible to run torrents to its full speed and ping internet hosts with lowest latency, like there is no torrents running. (I'm not telling about LLQ, it's a bit different)

it is most common misconception - queues only do one thing - when link is full what packets are going to be dropped the most. So, if your link is not full, then no packets will be dropped.

However you can add dedicated link portion for ICMP packets and set some rate limitation, so customers are not able to abuse it. As result, you will get normal ICMP RTT.

janisk,
Yeah, I tried to search more on this forum, reading the threads carefully, and I think I found an answer in this thread: viewtopic.php?f=2&t=27555 on page 3 by normis. Per-user traffic prioritization is completelly impossible.

Is dedicated link portion means, that I should make 9M of 10M connection for heavy traffic in one global-in queue, and another 1M for icmp, voip, dns and online games in another global-in queue?

Am I miss something or priorities does not work in ANY case?

I have carefully create mangle rules, queues - no luck!

I have put light traffic to a queue with high priority and with limit-at equal to a full speed of my internet (on screenshots below there is limit-at decreased to 1/4), and put heavy traffic to a queue with lowest priority and with limit-at equal to 0.

It means that every user MUST have light traffic prioritized. Limit-at and priority guaranteing that. Light traffic uses only 1/10 of overall internet speed, so it must be prioritized.

Ping, Skype calls, ICQ, Jabber, DNS, HTTP browsing, Online games - all of those processed with lags, dropouts and packet drops, of course with high latency, when there is heavy traffic, it's just not prioritized.

Even if I do it in reverse for testing - set limit-at for heavy traffic equals to full internet speed with highest priority, and light traffic to limit-at=0 with lowest priority. Results is MUCH THE SAME!!!, it's again isn't prioritized at all.

So priority doesn't work?

PS: Have written to support@mikrotik.com with attached supout 2 months ago and didn't recieved any reply.

Here is my mangles and queues screenshots.

Try a light queue with a high priority and limit-at set to 10% of your bandwidth, and a heavy queue with a low priority and limit-at set to 90% of your bandwidth.

Priority determines which queue gets to get to its limit-at parameter first. If you set one limit to 0 that is indeterminable.

fewi,
I tried what you said - same problem.

limit-at and priority have no meaning. They're not working absolutelly.

Let's see how can I ensure, that they're not working:
1. I have 4096kbit internet bandwidth, which is in+out.
2. I made light queue for high priority traffic and heavy queue for low priority traffic.
3. (I do it just for the testing purposes!!!) I put limit-at=4096k for heavy traffic and put there priority=1, for light traffic I put limit-at=0 and priority=8
4. I run torrent and HTTP load & FTP load on the user client computer, heavily loads all the user bandwidth (512kbit/s).
5. Pings, Online games, Skype and other light traffic, passes but with high latencies (same latencies as p.3 in correct way), so limit-at and priority I put on heavy traffic have NO meaning! limit-at is a CIR, think about it.

So, is priority and limit-at a fake? Please prove me that this is not..

2 hel

totally agree with you, priorities not work. Set up the queue as well as you, and tested - no result, priorities are not working as they should work in our understanding. I stopped only on the equal bandwith sharing with pcq and queue tree - this is better than nothing.

maybe this is help to you (doesn't helped me ):
http://mum.mikrotik.com/presentations/I ... valens.pdf
http://mum.mikrotik.com/presentations/U ... 009USA.pdf

maybe this is help to you (doesn't helped me ):
http://mum.mikrotik.com/presentations/I ... valens.pdf
http://mum.mikrotik.com/presentations/U ... 009USA.pdf

Yeah, I've read that before, Valens one, Janis one - all that works in their examples is a bandwidth control, qos isn't working at all.

I even can randomly set priotities and limit-at to a different leaf, inner qos queues - they aren't change anything.

I even can randomly set priotities and limit-at to a different leaf, inner qos queues - they aren't change anything.

Have you bothered to set max-limits too? This means set it for each leaf, not just the parent.

Limit-at = minimum guaranteed to that queue
Max-limit = maximum that the queue is capable of.

Without Max-Limit the queues won't work.

Also as a side note, your overall max-limit for a queue should be around 90% of what a link is capable of. I've noticed that if it's set too high they don't work properly either.

Have you bothered to set max-limits too? This means set it for each leaf, not just the parent.

Limit-at = minimum guaranteed to that queue
Max-limit = maximum that the queue is capable of.

Without Max-Limit the queues won't work.

Also as a side note, your overall max-limit for a queue should be around 90% of what a link is capable of. I've noticed that if it's set too high they don't work properly either.

Just before using this config shown above, I used separate upload/download for qos, which was limited correctly in inner and all leaf queues, result is the same.

Why 90%, not the 100%? I have stable 4mbit/s link.

I will try to reconfigure it again tomorrow. But I'm not optimistic about it...

Why 90%, not the 100%? I have stable 4mbit/s link.

it's because you're limiting download, which is falling on you from your ISP - you cannot control it directly (anything that is received from ISP is already accounted by ISP's shaper), so the only hope is TCP algorithms which should see your artificial 'bottleneck' and lower the amount of transferred data per second. if your downlink is congested, it's your ISP who decides which packets should be dropped to satisfy your BW limit, that's why you need to have a free space of 5-15% - anyway, your incoming speed will always be higher

also, if you assign limit-at value to the queue - this should be guaranteed that queue can get this amout. it will get that amount of traffic (or try to) no matter what the priority.

so lets divide traffic this way - queueA gets 20% of bandwidth and max limit is 100% with priority 1 and queueB is set to 20% and max limit is 100% with priority 2.

so when both of them want to get 90% of available traffic queueA will get the smallest value of (100%-queueB-limit-at) or 90%. As result queueA will get 80% and queueB will get 20%

also, if you assign limit-at value to the queue - this should be guaranteed that queue can get this amout. it will get that amount of traffic (or try to) no matter what the priority.

Ok, I have one question then.
I have limit-at on light traffic, its speed cost 1/6 of entire total speed of our internet link. So light traffic mustn't drop any of light traffic's packet.
Ping is a light traffic and limit-at guaranteing that this traffic will get enough speed to let all of the packets to get to the global-out queue.
But... For some reason some of the ping packets gets lost when torrents or other downloading active... I think it's because of timeout, not shaper packet drops.

So.. Is limit-at and priority guaranteing only speed and not low latency?

The limit-at is used to define a guaranteed minimum amount of bandwidth assigned to a specific queue, so no it's not necessary. If it's not defined, I believe it treats it as if there is no guarantee for that queue. If you define a limit-at for a sub queue, it should not exceed what a given queue is capable of.

Example:

Parent: 10M line (set max limit to 9M for this example)
High priority traffic: 2M limit-at, 9M max-limit, priority 1
Medium priority traffic: 2M limit-at, 9M max-limit, priority 4
Low priority traffic: 2M limit-at, 9M max-limit, priority 8

With a setup like that it means that each class of traffic will always get 2M worth of bandwidth flowing through that queue no matter what is going on. Any one queue can spike up to 9M worth of bandwidth if there is some free.

Now lets say for arguments sake all 3 kinds of traffic want to use the full 9M the queue is capable of, what will happen is this: High traffic will get 5M, Medium will get 2M, and Low will get 2M, the rest of it will be dropped. Priority defines what queue can reach it's max-limit first, since High has the best priority it means it will get the extra bandwidth that is available after everyone has their limit-at met.

Well, I have 4 mbit line. I've limited qos and bandwidth control to 4096 kbit/sec and I don't get it why I can only use 90% of my line... It's a big waste of resources for me.

Here is what I meant about latencies:
If user downloading a file and trying to play online games, he will see long latencies (400-2000).

I simply want to make ping, online games, dns and skype traffic pass first, at least for the total traffic, not per-user.

Here's screenshots:
What the point of this priority, if we can't prioritize ping, skype, games for comfortable using them?

Is priority even working when my internet link is 20-50-70% free?

Well, I have 4 mbit line. I've limited qos and bandwidth control to 4096 kbit/sec and I don't get it why I can only use 90% of my line...

you should set max-limit to ~90% to make network algorithms do their work for the rest

you can directly control only transmit. everything received from your ISP is already prioritized/shaped on its side, all exceeding packets are already dropped

we had situation a few years ago when we were shaping our downlink by ourselves from ISP side - they just had access to the router to see that we're shaping with corect speed. yep, that situation was ideal in the light of prioritization. now they shape our link on their device again - I had to limit about 10 Mbps less than our link bandwidth...