I have a question in regards to PCQ. Say I have a PCQ queue with a 2Mbps rate and max-limit of 10Mbps. If I have 20 queues, does bandwidth get managed such that each user could download at a maximum of 500k (10Mbps / 20 queues), which would make hitting the 2Mbps rate only truly possible when there are 5 or less streams? I.E. does PCQ take into account the amount of bandwidth actually being used by each queue, or does it always limit bandwidth by max-limit / # of queues.
correct - it will calculate max-limit/queue count if that is more than rate-limit, then rate-limit will be taken as limiting value.
Thank you. So, just to be absolutely clear, it doesn’t matter if max-limit has actually been reached or not, queues will always get limited to max-limit / queues? So, the solution to let users get closer to the actual specified PCQ rate (at times when max-limit / queues would be less than rate, but max-limit has not been reached) is to make sure max-limit is not set?
No. If max-limit of the queue itself hasn’t been reached user can pass traffic at the rate of the PCQ queue type. If the queue that the PCQ type is assigned to is congested the rate falls to max-limit/queues.
Just look at the PCQ rate examples in the manual: http://wiki.mikrotik.com/wiki/Manual:Queues_-_PCQ
The pictures show the concept very clearly.
Thanks, I did see that and I do understand the basic concept, but the examples do not directly relate actual throughput to max-limit (its not specified whether the queue rates shown are potential or actual), so I was unsure what should happen when actual throughput < max-limit. I need to know the precise behavior of this queuing discipline as we are looking at the possibility of deploying this on a very large scale. I need to know that the behavior I see in testing matches what should be happening.
If you have a queue with a max-limit of 512k running PCQ with a rate limit of 128k and you have two users passing as much traffic as they can, they will get 128k each because the parent queue has enough left to satisfy both PCQ queues to their 128k limits. That works for up to four users, as 128 times 4 equals 512. Once you, say, eight users trying to pass as much traffic as possible they will each get 512/8 = 64k as each PCQ queue cannot scale up to 128k because the parent queue is exhausted. If 7 of those users are each just doing VoIP at 10k then the parent queue has 512-(710)=442k left and the 8th user can get his 128k. If 4 users are idling at 10k and 4 more try to go as fast as possible they can get (512-(410))/4=472/4=119k each.
Each PCQ queue is going to try to satisfy its own rate limit until the parent has nothing left for it. When that happens bandwidth will be split evenly among the PCQ sub-queues as they demand it.
Edit: I think. Is that what you’re seeing? Suddenly I’m all unsure.
Yes that is what I am seeing on my test machine at the site, but my test end user seems to be reporting differently. He may be having other issues. I need more data from other end users but its a little hard to get. Once I figure this out for sure, I’ll post what I find.
I can confirm it is working as fewi explained. This is good stuff, it transformed that segment of the network. I’m excited to try this on a large scale.