See my signature for information about how I use these ideas in practice. I don’t have full understanding, but I can hopefully get you closer to meeting your needs.
- MikroTik’s limit-at is a Linux Committed Information Rate (CIR) concept.
- MikroTik’s max-limit is a Linux Maximal Information Rate (MIR) concept.
These concepts have value when there is a Contention Ratio occurring on your network. If you are wanting to set limit-at, you should be doing so with the understanding that you’re wanting to ensure at least this much traffic will have priority rules applied when things get congested.
You can’t ensure 1MB for 500 users when you only have 100MB total to offer. So, this is not magic, it is math. We are talking about priority (dropping of packets or rate limiting) how and when. What happens, when it happens. Well, at limit-at. At first, limit-at values are attempted, each user is given 1MB, if 100 users are requesting network bandwidth.
What if only 50 users are on? Then they get more, limit-at is not under pressure. If one user requests 50MB, and another user requests 50MB, the algorithm can still supply them both because only two users are on your network. When a third comes online, well, you’re out of bandwidth now, so priority rules (limit-at) kicks in and traffic shaping begins to occur to give everyone at least X amount.
In the real world, you would probably have a group of users who get 1MB each, and another business group would get a different limit-at. When the pressure rises, you take care of the SLA business accounts first, ensure they get 5MB, and others get 1MB or whatever, and you don’t oversell your services.
So, as you go down this idea of queuing, you need to think about groups. Groups of data, groups of users, grouping is the way to understand what you’re trying to do.
Read more here.