I have 50M upload/download, but never can reach maximum for both of that speeds simultaneously. Maybe the reason is half-duplex, maybe something at ISP side. Anyway, I set up Queue Tree with something like this:
The purpose and the goal is when I start to download with my browser the torrent downloads automatically slow down. It works but when torrent upload is at maximum (50M) I can’t reach 50M download with the browser because I think that script works only for one side.
So my question is: how can I force my RB-941 dynamically limit total upload speed by 20M right when when total download speed reaches 40M?
I’m sorry, but I still can’t figure out how I should set it up that download will affect upload. I can slow down torrent download by starting browser download with my settings, but can’t slow down torrent upload when I start browser download. So I want download priorities affect upload speed.
I would say your only chance is to use global as a parent like you do, create a child queue of global with both limit and max-limit set to the sum of upload and download speed provided by your ISP, and two child queues inside that one, one for upload and one for download, where the download one has a higher priority (lower number) than the upload one, so something like
Only the innermost child queues can be prioritized over each other, so the available 8 priority levels have to be shared by upload and download classes with individual treatment. You may need a higer limit for the upload queue (throttling of ACKs to download packets would affect download speed, so you definitely want to prioritize upload ACK-only packets over other upload).
create a > child > queue of global with > both > limit and max-limit
Thank you very much! Looks like it’s working with such tuning, even the script from the first message (after I added “Limit At” to the parent and important_traffic). At least starting “important” download fully affects “not important” upload at this point.
Only the > innermost > child queues can be prioritized over each other
Does it mean if I create two parents (both with “global” parent) named “Download” and “Upload”, and then the children to them like important__download_ and non_important__download_ / important_upload and non_important_upload that I can’t prioritize important__download_ over non_important_upload?
If I’m not clear on that here’s what I meant in the script format
Well, first of all if you create Download and Upload as directly parented by global, without the common parent queue with a limit standing between them and global, you will lose the ability to throttle upload by download because they will not share the common limit of that parent queue.
My original illustrative setup would actually work somehow even without specifying the priority, because the sum of limit values of upload and download is equal to the limit of their common parent queue, and there are just two child queues sharing that bandwidth, so the priority is absolute - when one of the queues (upload) has already reached its limit rate, a packet from the other queue will be preferred if its rate is still under its own limit when both have a packet waiting for getting sent.
But it was a (too) simplified example; if there are more than two children of the same parent, the rate of several of them can be under their respective limit values, so then the priority must decide. And among upload packets, you do need to prefer those which acknowledge reception of download ones, as otherwise you would slow down the download and, worse than that, cause retransmissions of the download packets. So you need more than two priorities, and priorities only work for queues which are not parent ones, i.e. have no children.
On the other hand, in this unusual setup, you can assign to the the ACK-only upload packets which acknowledge reception of download packets the same packet-mark like to the real download ones, so that they would use the download quota of the common parent queue. In such case, you don’t need priority to decide between “download and related” traffic and “upload and related” traffic, so you can create child queues in both.
The manual says that priority decides among children queues; it is true that it is not written explictitly “of the same parent” there. So you’ve got space for your own research
@sindy shouldn’t the max limit of the Parent be the sum of the Child’s max limit? If the Upload is 50Mbit and the Download 50Mbit as well then the Max limit of the Parent must be the sum of it…
Also something i have difficulty understanding, if we do not use Global as parent, then for the Upload should the Parent be the Lan or Wan Interface? What about the Download ? How do we make the choice ?
Not sure if in this case forward or prerouting makes any difference though. First I separate traffic I want from any other by ports. Then I separate download traffic from upload (packets direction in / not in any ppp). I create parent queue with both limit-at and max-limit as suggested so as set that limits for every child queue beside the one with the lowest priority. Finally I have 4 child queues: for important download and upload (selected ports, priority 1 and 2), and so on for any other traffic (all not marked packets with priority 4 for DL and 8 for UL). This isn’t highly required for home use since you can set limits in torrent-client anyway. Also not sure about numbers for full-duplex.
How this works from my observation: torrent uploads for 50M (at max of my half-duplex bandwidth), then I start torrent download (without queues the upload somehow prevail over download, now download is at nearly the max bandwidth, upload goes down significantly). Then I start download with my browser which goes at the max bandwidth, torrent activity throttles.
No. The names are a bit confusing. limit is actually the “guaranteed rate” which is granted to the queue even if there is some competing traffic, max-limit is the absolute maximum the queue can get even if there is no competing traffic and some free bandwidth is still available. So in another words, first the guaranteed rates of all child queues have to be satisfied, and if some bandwidth is still left, it can be divided between them, but even then none of them will get more than its max-limit.
The parent queue’s limit and max-limit are the set to the same value because max-limit is a mandatory parameter; there is no other way that setting the max-limit to tell the kernel what the bandwidth actually available on the uplink is. But any of the child queues is free to use that bandwidth completely if there is no traffic in the other child queues, hence they all get the same max-limit like the parent queue. If the max-limit of the parent queue was a sum of max-limit values of the child ones, the child ones would be unable to use the free one above their max-limit values when available.
The basic thing here is that the link is a half-duplex one. WiFi based wireless links can either transmit or receive but not both at a time (unless you use two pairs of radios and reserve one pair to use one frequency channel for one direction, and the other pair to use a non-interfering frequency channel for the other direction). If the physical bandwidth of the link is much higher than the bandwidth controlled by some traffic shaping mechanism, this doesn’t matter; if the use of the physical bandwidth is not restricted in any way, the half-duplex behaviour of the link becomes noticeable.
So here we have to use the global as a parent exactly for this reason - if we used any interface as a parent, the rate limits imposed by queues’ parameters would apply only to the traffic which would leave through that interface, and it would not be possible that the queues for the upload and download directions had a common parent one.
It doesn’t - rules in chain prerouting handle both the traffic from an external host to router’s own addresses and the traffic to be forwarded by the router from one external host to another, chains input and forward deal specifically with the former an the latter, respectively.
But any of the child queues is free to use that bandwidth completely if there is no traffic in the other child queues,
This is what i mean, if the Download child uses the whole 50Mbits, what will then happen with the Upload? Since the Parent is limited to 50Mbit..
The Upload child will get the guaranteed limit wich is 1 Mbit but nothing more since the parent is on its limit…
But that would not happen if the parent had a Max limit of 100Mbit, since our line is 50/50 symmetric…
Also i did not really understand how we choose an interface for upload or download as parent…
That’s the whole point - the line is not 50/50 symmetric. As the OP states, on this particular line, 50 Mbit/s is the sum of upload and download, because the line is a half-duplex one. And the goal is that torrent upload would be treated as low priority traffic, giving way to normal “human-initiated” browsing whenever needed, hence the download traffic has to be preferred.
And as I’ve stressed out several times above, it is important to distinguish between packets in upload direction which acknowledge reception of download packets carrying some payload (human-triggered browsing) and packets in upload direction which carry some payload (torrent upload).
We did not choose an interface but global - that’s not an interface, that’s just a virtual object not linked to any interface. So you can make as many child queues of it as you want, and set the limit and max-limit parameters of each of these queues as you like.
It doesn’t change anything about the fact that you can only throttle the download traffic by slowing down its delivery to LAN side, so if the sending application doesn’t get any feedback, the throttling actually does not work. But if the share of this type of traffic is reasonably low, it doesn’t affect much the overall result.
Well, “download” and “upload” are not roles of interfaces but directions of traffic flow through the uplink as seen from the perspective of the LAN clients. So if you have several uplinks and several local LANs, you have several interfaces whose egress traffic is considered “upload” (the WAN ones) and several interfaces whose egress traffic is considered “download” (the LAN ones).
The queues in RouterOS only limit egress traffic, hence limiting the “download” direction consists in slowing down the delivery of packets received via WAN while sending them to clients via the LAN interface(s), so it only actually works if the senders get a feedback from the recipients. If the senders maintain their sending rate no matter what, dropping the already received packets from them rather than delivering them to the LAN clients makes no difference on the bandwidth these flows occupy in the download direction.
Whilst it is often useful to use an interface as a queue’s parent, because the “root parent” interface is one of the keys to choose the queue (the other one being the packet-mark), if you need to throttle the download direction as a whole and you have multiple LAN interfaces, you have to use the global parent and assign distinct packet-mark values to the packets in upload and download direction.
Better… it always depends on the particular setup required. Using the same packet-mark for both directions and letting the proper queue be chosen among those matching that packet-mark by root parent interface is simpler to set up if you have a single LAN and a single WAN, plus it is apparently possible to use simple shaping configurations together with fasttracking if you use interfaces as root parents (as the fasttracking manual explicitly states that only queues with root parent global are bypassed by fasttracked packets).
