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.

To clarify.
Priority have no effect on packet order, but Queue types (of queues and interfaces) can cause packet reordering

P.S. do you see this information from the source code?

Macgaiver, do you think this can be summarized as a "manual" page or paragraph?

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.

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.

I just notice that original topic was a little bit different ). Sorry, void!!!

As far as i can see it - it is not possible. There are no way of knowing for sure that available throughput has changed. And rearrangement of packets in Real-time environment - when packets are coming and leaving all the time, even if implemented - will take a loots of CPU and memory.

Well do we need to know what the throughput is in the first place ? If we know that certain packets have max priority why not send them directly and queue the others (this is already the case in HTB if I get it correct) ?

You are right macgaiver, thanks a lot ! I learned a lot through this thread.

[don't forget to give karma

I think some analogy is in the place:

Imagine a factory with conveyor belts. At the end of each conveyor belt there is a packing assembly, that pack each product unit into boxes and send out to export department. Each packing assembly have defined parameters:
1) buffer size - how many units of product it can hold unpacked in the assembly itself
2) packing speed - units per minute
3) packing method

Now imagine that these conveyor belts are unstoppable and all the product units that can't get into the packing assembly (cause buffer is already full) will be just dropped on the floor. As packing assembly is still working buffer periodically will have an empty spot that will be taken by most current product unit (cause all previous units are on the floor already)

These conveyor belts have different operators, that can simply forget about dropped units (UDP), or will slow down the conveyor belts speed and place dropped units back on the belt (TCP)

Also some of the packing assemblies have "turbo" button, that allow to increase packing speed for short amount of time, after that packing assembly needs to cool down

If your packing assemblies create more boxes than export department can handle, it has exactly the same type of system for putting product boxes into trucks/lorry.

factory - HTB
conveyor belt - traffic streams
packing assembly - queues
export department - Interface queue
buffer size - queue size
packing speed - limits
packing method - queue type
operators - protocols
"turbo" button - Burst

So OK, let's take this example and try to solve it:

We have the simplest routing architecture and we want to prioritise only VoIP Outgoing, but it can take upto 99% or 100% of the entire bandwidth. And we want to let it do that.

Let's say we already have marked the packets - VoIP and all Else.

So we are building an HTB Queue Tree. WHat will that Quueue Tree look like?

+Queue Tree max-limit=100%
-->VoIP limit-at=100% max-limit=100% queue-type=fifo-10-packets
-->Else limit-at=0 max-limit=100% queue-type=fifo-10-packets

So let's say enough VoIP packets hit this queue/tree so that they take up 100%. And at the same time 500% Else traffic hits that HTB /queue tree. This is possible becase one Interface is 100Mbit or 1 Gigabit so it recieves a lot more than the Queue Tree can send out.

So let's drill down really deep as much as we can go with a surgical instrument. So what will happen ON A PER-PACKET LEVEL? How will this HTB / queue tree treat the traffic?

Parent, max-limit=4Mbit/s parent's parent is the interface queue
  |
  --> Unmarked traffic, prio 7, max limit set to 100% (or 0 i RouterOS), pfifo
  |
  --> VoIP traffic, prio 6 (aka one better than unmarked), no max limit, as before, pfifo

• Before traffic starts, there are no packets in any of the queues.
• When the unmarked queue is full, and VoIP traffic exists, that queue will lend traffic to the VoIP queue, since it has better priority.
• When the VoIP queue is full, new flows will be dropped

1)So about my example three posts above - anyone can tell me exactly what happens to my packets?
2)What happens to my VoIP prioritiesd packets? I don't want to have loss with those
3)And what will happen to the others, non-prioritised ones?
4)The packet is put in which queue first? or in what type of buffer?
5) where it is evaluated how? based on what merit exactly?
6)What does "HTB" do to it? Can it decide to discard it?
7)I still have not found the "TC" .c source file or the part of the Linux Kernel with that stuff in it. Anyone can help and point us in the right C source file?

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

I would like to have the ability to have a strict priority queue no matter what the available bandwith is.

so can the limits be set to artificial values (1gbs) and priorities will be enforced in the interface queue?

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.

actually, priority works when limit-at is reached

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 =)

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.

When the unmarked queue is full, and VoIP traffic exists, that queue will lend traffic to the VoIP queue, since it has better priority.

The VoIP queue will also borrow...... When a queue cannot borrow any more bandwidth, it will drop packets

It may be desirable to set up a limit-at parameter to ensure that a queue will not end up at 0 rate if no more bandwidth is available.

7) I think you will only be able to get original HTB from http://luxik.cdi.cz/~devik/qos/htb/

Priority

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

Queue with higher priority will reach its max-limit before the queue with lower priority. 8 is the lowest priority, 1 is the highest.

Make a note that priority only works:

* for leaf queues - priority in inner queue have no meaning.
* if max-limit is specified (not 0)

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.

Inspired by cFosSpeed, I see a clear way to implement something in RouterOS. This feature would kick ass, I hope MT see how it will make a lot of cash for them, feelin' rich MT? . It can also be done with a tool that is run on a separate host that communicates with a server and checks for loss between the two. By ICMP and by TCP RTT and the way TCP Vegas does it and the way the new uTP protocol does it - this communcation will need to have high priority in RouterOS. If only ICMP is used - this can be scripted in bash and in RouterOS. If loss occurs - the max-limit is lowered. This feature can be put in a new binary and in a new npk called "prioritiser" or "WAN optimiser". This new binary can be made outside MT, so that the MT guys would be free to make all the other stuff they have their hands full with already. This feature will be useful for example in cases when the available bandwidth changes slowly. So it will adjust the max-limit to a lower value than what is actually avaliable. So we will still have wasted bandwidth but at least we will have better chace for our priority packets. So its either joy and happines by this method or its back to the dark ages and sure death by setting youtself on fire while drowning.