I am using a rb850gx2 with ROS 3.34.4.
I am trying to use simple queues and PCQ to divide bandwidth evenly among devices and also limit the max upload and download. I used this config:
According to speed tests it worked fine. However, I have found that if we are uploading at 3M and I try to download or run a speed test I can’t get much more than 10-15Mbps. As soon as I stop the upload speeds resume and I do not have this issue with the queue disabled. I have tested this with different devices, one running the upload and another running the download.
I also tested this using queue tree and I ran into the same issue. If I switch from pcq to queue type default then the max speed is still limited and I don’t have this issue. This is a problem because even if upload is maxed I should still be able to use up to 50M download.
Has anyone else run into this or is this by design?
The problem is that there never is just “upload” or “download”.
A “download” is receiving traffic and sending acknowledgements that tell the other side that data has
been received and that it can go ahead sending more data.
When you limit “upload” you also limit the sending of those acknowledgements, so the other side slows
down sending data because it does not get all the acknowledgments.
You could avoid that by treating acknowledgements specially and give them priority over other upload
traffic, so they are always sent first and then the other data is used to fill the allotted max speed.
How exactly to classify data as data or acknowledgement is another topic, this depends a lot on what
kind of traffic it actually is.
I understand what you are saying and its a good point. I thought PCQ is supposed to try to divide bandwidth equally among devices. Do you know why this only happens with PCQ and not default? If I have one device uploading a large file and using the max upload then why doesn’t the queue reduce the upload speed to this device and give more to another device that is trying to download? Are the acknowledgments too small or not recognized as upload?
I also set the max upload and limit to less than the actual speeds since I have read it should be 80-90% the actual limit.
i have the same problem with pcq upload. when i fully upload, download is very bad. when fully download no problem.
my adsl line max limit is upload/download 768k/10M
four different sollutions i came to are…
set pcq-rate=512k to pcq-upload-dafault (something less than 768k max upload limit)
use queue type “synchronous-default or default or hotspot-default” for upload and “pcq-download-default” for download.
make child queues for every ip of your subnet (with parent=your main queue) and place limit-at 512k/9M at every child.
i think this one works well because ros try to satisfy all childs. that means downloads dont suffer.
use queue type synchronous-default/synchronous-default
please try all of them.i am curious to see if this works for others.
i was very angry when my iphone was backing up to icloud at full speed and my pc could not surf or download something with full speed!
anyone has a better sollutiion for adsl asynchonous links please tell us. i love pcq’s because with just one simple queue you control bandwidth of entire subnet!
What you guys can try: use a queue with two different priorities, and mark the traffic in post-routing mangle
to select the correct priority. One possible try is to match on packet size, e.g. packets larger than 512 bytes
get assigned the lower priority queue and smaller packets go in the higher priority queue.
Then set the total max speed to slightly less than the actual upload speed, and define the Limit At speed for
each of those two queues at about 1/2 the speed and the Max Limit the same as the total limit.
This means that the acknowledgments always get enough bandwidth and the remainder of the bandwidth
(for the uploads) is borrowed by the low priority queue from the high priority queue as far as available.
I use such a mechanism in a slightly different environment, where I want priority for voice traffic over bulk
traffic. It works very well. I use a Queue Tree for this, with 8 queues per interface which are selected by
a packet mark which is assigned in the postrouting mange table based on the DSCP field.
(first set the priority based on DSCP high 3 bits, then 8 rules to set the packet mark based on the priority)
In your case you can set the packet mark directly based on packet size, as a first attempt to make things
not more complicated than necessary. When that sort of works, you can try more sophisticated matching
of ack traffic.
I will do some tinkering as suggested. I hope that I can use a separate queue for ack or something similar. At this point I just hope it works but it seems that simple queues with pcq have some limitations. Overall they work great but I wonder how often this has been an issue and I didn’t realize it.
I can’t test anything until after hours but I appreciate the input and welcome any other advice. I will keep updates on here to let you know what I find.
Hi TechGuy I must noted that if both limits (pcq-rate and max-limit) are unspecified, queue behavior can be imprecise. So it is strongly suggested to have at least one of these options set.
this is from pcq manual.
You need to limit upload speed to ~80% of your real upload speed. If you want to have full control, bottleneck always should be created in your router. If not, your ISP will get decision what traffic is priority and what not. This is not mikrotik specific things, QoS works in this way.
I am experimenting now with pcq burst. Its a nice way to have full bandwidth at begining (pcq burst rate) and after some seconds lower bandwidth (pcq-rate)
sash7, I am aware of the recommendations on the wiki and I do see better results using that. However, when I test on a very stable internet connection using PCQ I run into the issue I described while I don’t on default and other queue types. The other queue types still limit the upload and PCQ still works on the download but I don’t run into the issue that lowers my download speed unless I am using PCQ for the upload queue also. This may very well be due to the way PCQ works compared to the other queue types. Based off the wiki, PCQ is making a bunch of FIFO sub-streams based off the identifier, which is a nice and very useful feature. However, I just don’t want to lose up to 20% of my bandwidth due to a limitation in PCQ. The compromise seems to be to just lower the upload or use a different technique.