So finally my QOS on my RB’s are working as desired. Using limit-at and max-limit I can give priority to the different types of traffic during congestion periods. Now this only works if we have guaranteed bandwidth from our provider (which is very rare unless you pay a fortune).
Now what in the case of non-guaranteed bandwidth ? Wouldn’t it be possible to implement a queue that has strict priority and has priority on all other traffic no matter what the available bandwith is ? Mainly for voip (sip) traffic this would be a great feature.
I was also thinking about creating a script that uses the bandwidth test tool to check bandwidth between 2 RB’s every x minutes and adept the max-limit of the queues dynamically but this isn’t a solid and good solution.
unfortunately, there are many pitfalls in such situations. for example, if you use ADSL modem, you cannot even know whether the upload link is congested - because 100 Mbps between the router and the modem are always almost free…
That’s the reason why I would like to have the ability to have a strict priority queue no matter what the available bandwith is.
With the current system priority only works if the max-limits are reached. That means that in case you have a 100Mbit non-guaranteed link and this links drops to 99Mbit the priority doesn’t work and things get screwed up.
and in general the situation is how HTB works. yes, it would be interesting to add possibility to force bypassing the HTB for some packets - but it’s huge work, and for now we do not have something called ‘system-test’ or ‘queue-test’ packsge
You run a car rental facility, but don’t inventory cars. You’ve got 10 people in the blue collar line, and 10 people in the white collar line. Do you just send all 20 out of the door to get cars if the white collars are supposed to get them first?
How do you know when to give something priority if you dont know how full the lot is? You have to know the max limit in order to decide if you want to drop something else.
One question however, if you set max-limit at 1gbs and use priorities, does that still reorder packets in the outbound interface queue.
You don’t determine the priority when something is full, you determine it on beforehand. The only thing you need to decide when something is full is what you’re going to drop.
I have a 100Kb stream that I decided that needs to have strict priority and I don’t care about the 99,9… Mbit of the 100Mbit connection, not even when there is only 50Mbit available instead of 100Mbit.
but let’s suppose you have a gate that is passing one white car per minute - that’s our queue. and now we get a blue one. so we want the blue car just go round all white cars and pass the gate without limitations =)
I think you could get reordering. If the different prio packets arrived at the same time? We need to discuss this.
And even then, if you send more packets upstream, the next device that has congestion, will drop whatever it decides, usually, in a … crippled way Hahah. Unless your ISP has good packet queues themselves on the core / border, and you have no congestion up to that router. (Thanks to all upstream admins who do it properly).
Stop making examples with cars. Its not helping. Make examples with packets. And frames.
Just set that parents queue max-limit to a lower value. That’s it. What exact value to use - that can be tested.
And again we come to the same story about priorities.
Just to avoid any confusion - in MikroTik’s QoS there are NO PACKET REORDERING, there are list of packets that will be dropped , but all remaining packets will leave QoS in the same relative order they came in.
Priority is not “Who goes trough first?” indicator it is more like “Who gets dropped last?” - higher priority packet has - less likely it will be dropped.
So let’s say we have a packet queue with two leafs. One leaf is a priority one and for example 200kbps of packets will be processesd by it. This means they will go out first, no matter what, right? Because they have limit-at set at 200kbps. And the other leaf does not have limit-at set at all but it has a bigger queue size, so instead of dropping the packets from the second leaf, when the higher priority ones from the first leaf are sent out, they are queued. Delayed.
We are talking about real-time action here - there are no time to delay some packets (to let others first) , cause on next moment there will be next packets incoming. So what will you do then?
In real-time action you need to act fast - so each packet gets trough or gets dropped strait away. HTB is just a way to make that decision. Higher priority - less likely be discarded.
Could someone summarize these findings? I’m reading through this post, and I’m getting more confused. I read the HTB article on the Wiki, but some posts here seem to contradict it.
No - experimentation over last 3-4 years. - MikroTik MTCTCE training + lots of questions to teacher
Well my guess is: the whole picture (with all possibilities) of QoS is way to complicated to put it all in one topic, to understand the whole you need to understand each part, then you will be able to combine those for your specific example. And most of the setups use only subset of 2-3 QoS feature at the same time, not the whole list, so I do not think summarized topic (at leaset how i imagine that) will help anyone.
Priority is a HTB option, that together with max-limit, limit-at and queue structure helps to determine how much actual traffic can be given to child queues. All traffic that is not allocated to the queues is dropped.
To ensure that communications is not “choppy” a buffer was introduced to every child queue - queue type (with specific queue size)
We need to discuss this.