…for a DSL uplink. I am lost in the whole documentation and MIkrotik support seems to run in mathematical cirles - yes, they are nice, no they dont help.
I seem to be totally lost.
Anyhow, given a 450G, two interfaces (lets keep it simple for now), one internal, one external.
I Want to have multiple classes of traffic, with faster classes ALWAYS taking priority over lower ones. Basically, VOIP before remote desktop, remote desktop before HTTP, http before the rest.
I have added mangle rules and those work - I can set up a tree of queues and see the correct amount of traffic in the correct category.
What I am totally lost at is how to set up the performance thingy. Basically, when doing a file transfer, ping times shoot up to 2 seconds worst case. Now what ?
To make things worse, the real scenario has 2 uplinks and another 1 pptp connection and I need qos to work over the pptp link ;(
This will get you a very basic setup going where you can see how the router marks connections and packets and how they fit into the Queue tree. After you have this working and figured out, branch out from there. Add in more specific classes of traffic, add in more leafs to your queue tree etc.
Just remember to take it one step at a time. QoS is a very complex subject and it is hard to fully grasp or explain.
What I like to do is place the queues on the interfaces themselves. This gives you the control over what each interface is capable of. It also helps me keep track of what each queue does better. With the Global-x interfaces they apply for every interface and I find them confusing to keep straight what one does what, where was with the physical interface your Queue Tree on the LAN will always be download, and your Queue tree on the WAN will always be upload.
Ok, so far that is good. DO you need different routing marks then? As in: if I want time critical traffic to be important on two queues… is one mark (timed) enough, or so I need separate marks per interface?
In addition. how many queue levels do you have? I just got it working with 2 - one directly under each interface, then one for each traffic class under this. Do I need this one above (like ether2-out as queue holding all subqueues for ethernet 2)? I ONLY determine limits there… but I think I need the limits, right?
Besides that, I got it working. stable 40ms external and to my hoting center 50ms via PPTP. The trick is to keep the limit of the pptp tunnel enough below the real line limit. I have a 512k uplink. ether2-out is at 640k. pptp-out is at 464k, never queues up. Works nice.
I think an easy to understand intro page in the wiki may help. Can I just write one?
Yes you can edit or make whatever wiki pages you want. There is a user submitted one, that’s what it is there for.
It depends on your setup and what you are aiming to do for how many marks and levels you want in the queue tree. If you are using connection marks and then marking packets off of the connection marks, you are automatically getting both the upload and download side of the connection, so you can use those packet marks in the upload and download parts of your queue tree. Each packet can have 1 routing mark, 1 connection mark, and 1 packet mark, and only packet marks are used in queues. You can overwrite the marks, but that means that if you want the queue to take an action based on the first packet mark you gave it, it won’t. Hopefully that answers your question.
As for the depth of my queue tree, it’s basically what you have described, but you can obviously go much deeper. Like if you wanted HTTP and HTTPS to share the same absolute limit, but wanted to give HTTP a higher priority than HTTPS as well as a slightly larger chunk of the bandwidth, you would first make a leaf on your main queue that used the HTTP and HTTPS packet mark, and then make two sub leafs for each class of traffic. And yes you do need to define the absolute limits for the queues otherwise they won’t work. By default the MikroTik is already doing a simple first in first out queue for each Ethernet interface, you are just attaching another queue to that one that the packets need to be filtered through as well before they are sent out.
As a general rule of thumb, you should set the absolute limit on your queues to be about 90% of the actual full bandwidth of the link. This way any QoS schemes your ISP may be using won’t fire causing it to mess up your setup, and it gives the line enough free space for stuff to work normally. Once an internet connection reaches %80-%90 of full capacity, things start to break down for traffic.
