Every hotspot operator meets this problem. The link is fine most of the day, then in the evening it collapses — and it is nearly always a small number of people doing something heavy while everyone else waits.
The usual first fix is a simple queue per user. It works, but it wastes a great deal of what you are paying for.
Why fixed caps waste your link
Say you have 50 Mbps and cap every user at 2 Mbps. At three in the afternoon with four people online, your customers get 2 Mbps each and 42 Mbps sits idle. You are paying for it. Nobody is allowed to use it.
In the evening with forty people online, the cap that was too restrictive at lunchtime is now too generous: forty times two is eighty, which is more than you have. The link saturates anyway and everybody suffers.
A fixed cap is the wrong tool because your load is not fixed.
What PCQ does instead
PCQ — Per Connection Queue — divides the available bandwidth by the number of active users, continuously.
Four users on a 50 Mbps link get about 12 Mbps each. Forty users get about 1.25 Mbps each. Nobody is throttled while capacity is spare, and when it is scarce it is shared evenly rather than taken by whoever is most aggressive.
Crucially, the heavy user does not get more just because they are asking for more. That is the behaviour you actually want.
The setting people get backwards
PCQ needs to know how to group traffic into “users”, and this is where most broken configurations come from.
- For download, classify by
dst-address. Traffic is heading to your customer, so the destination identifies them. - For upload, classify by
src-address. Traffic is coming from your customer.
Get these the wrong way round and PCQ groups everything into a single bucket — which means the whole hotspot is treated as one user and the queue does nothing useful.
You need two queue types, one for each direction. One will not do.
Fitting it together
A working PCQ setup has three parts, and all three must agree:
- Two queue types, download and upload, classified as above.
- A queue tree on the correct interface, with a
max-limitset to your real link speed, using those queue types. - Mangle rules that mark the traffic, with marks matching exactly what the queue tree expects.
The third is where silent failures live. A queue tree acts on marked packets; if the mangle rule does not run, or marks something the tree is not looking for, the tree simply never matches anything. There is no error — it just quietly does nothing, and everything looks configured.
Set the limit slightly below your real speed
If you have 50 Mbps, set the tree to about 45. Queueing only works while the queue is on your side of the bottleneck. Set it to exactly your link speed and congestion happens upstream at your provider, where your queue has no influence over what gets dropped.
Giving up ten percent to keep control of the remaining ninety is a good trade.
Combining with per-package speeds
Most operators want both: nobody exceeds their package, and spare capacity is shared. That is a per-user simple queue for the package ceiling, with PCQ underneath sharing what is left.
Order matters, and so does making sure the two do not fight. This is exactly the sort of configuration that is easy to describe and tedious to get right by hand.
Doing it without writing queue trees
MikrotikAdmin’s QoS area has this as a guided task. Give it your real link speed and it creates both queue types with the classifiers the right way round, the queue tree on the correct interface, and the matching mangle rules — then shows you all of it before applying anything.
If you later want to adjust it by hand, everything it created is ordinary RouterOS configuration, named clearly, and Winbox will show it exactly as if you had typed it yourself.