Make a HTTP speed test tool

Wrong forum.
Suggest download speedtest app.
or check out new capability in 6.44!!

Correct forum.

Both useless suggestions.

You requested a feature, try the forum which states........
"RouterOS v6 RC and v7 BETA
BETA Testing and Feature Suggestions for the next RouterOS release (ROS v7)"
Can't miss it - as its top of the Forum list!
....
What's new in 6.44 (2019-Feb-25 14:11):
MAJOR CHANGES IN v6.44:
----------------------
!) cloud - added command "/system backup cloud" for backup storing on cloud (CLI only);
!) ipsec - added new "identity" menu with common peer distinguishers;
!) ipsec - removed "main-l2tp" exchange-mode, it is the same as "main" exchange-mode;
!) ipsec - removed "users" menu, XAuth user configuration is now handled by "identity" menu;
!) radius - initial implementation of RadSec (RADIUS communication over TLS);
!) speedtest - added "/tool speed-test" for ping latency, jitter, loss and TCP and UDP download, upload speed measurements (CLI only);

Also there is this.....
https://www.speedtest.net/apps

What are you requesting that cannot be accomplished by the new feature or the apps??

Only tests from weird custom server that is not available for linux

Well, HTTP speed tests are all by an specific protocol - Speedtest.net for example, is very different from Btest, which is very different from any open source Python server and client.
There does not exist any HTTP Speed Test as you want, it does not work magically in computer science and protocols, and never will, because the standards are there and only mainstream follow.

After 3 years now MikroTik has supported Containers so that it is possible for us to do a speedtest (viewtopic.php?t=193053) similar to speedtest.net

You like copy & paste?

Is there another way to change internet access routes automatically when the bandwidth on one of the routes is dropping?

Surely if everyone reasoned badly like you, everything would be blocked due to continuous tests that consume bandwidth for nothing.

Surely if everyone reasoned badly like you, everything would be blocked due to continuous tests that consume bandwidth for nothing.

I don't know if that is still true, but it appears that at one time most bandwidth on Starlink was used by people doing speedtests all the time...

I don't know if that is still true, but it appears that at one time most bandwidth on Starlink was used by people doing speedtests all the time...

The problem is widespread, as it is for me: in the evening when they return,
almost all customers start speedtesting "to see if it's okay" even if there isn't the slightest problem...
even if they simply have to send a message on whatsup ... And I have to pay for the bullshit instead of paying for the actual use of a service ...
Imagine if there were idiots who run speedtests scheduled all the time...
and of course they would be so ridiculous to obviously schedule it all at the same "full hour"....
Everything would be swallowed up, 100M per customer, for 4000 customers...

You like copy & paste?

Is there another way to change internet access routes automatically when the bandwidth on one of the routes is dropping?

Surely if everyone reasoned badly like you, everything would be blocked due to continuous tests that consume bandwidth for nothing.

So, how to change internet access routes automatically when the bandwidth on one of the routes is dropping?

I have tried many ways:
1. Recursive route failover? I have tried that but it won't work if the ping is still running even though the bandwidth drops.
2. Loadbalance? What if the connection quality differs between internet access routes? My network users are complaining about poor network quality. One with 30ms ping time while the other 1000ms.
3. Btest? No one is providing free btest servers in my country.

Sorry but I don't think my question has been answered.

Surely if everyone reasoned badly like you, everything would be blocked due to continuous tests that consume bandwidth for nothing.

So, how to change internet access routes automatically when the bandwidth on one of the routes is dropping?
[/quote]

Routing is not the problem, upstream link capacity is. Some ISPs are even silly enough to prioritize speedtest traffic to make clients believe that their service is excellent ... meaning that if excessive number of clients run speedtests, the normal internet service for everybody else will suck. And no, upstream capacity is not free for ISPs and if enough clients are silly enough to repeatedly run speedtests (and even complain if they don't get max service all the time), ISP has to invest (lots of money) into upstream connection ... and that cost will either be forwarded to clients or ISP will go broke.

Sample case:

I subscribe to 2 internet providers, let's call them A and B. A is the main internet access route.

Under normal conditions, the bandwidth of A is 10Mbps while B is 5Mbps.

When the bandwidth that I subscribe to from A drops to 1Mbps, how can I make the internet access route switch to B automatically other than using the speedtest results as a parameter?

I understand that running a speedtest continuously can put my network in trouble and I already have a solution for that.

But I would really appreciate if you have another solution that is better than speedtest to solve this kind of problem.

You will have to ask your provider A how you can query the state of that bandwidth limitation.
E.g. they provide you with a web URL that you can fetch and that returns a simple status, not some large HTML page.
Now of course, you depend on if your provider makes that available in a usable form.

When the bandwidth that I subscribe to from A drops to 1Mbps, how can I make the internet access route switch to B automatically other than using the speedtest results as a parameter?

While uplink to provider A is in use, running speed test a) interferes with normal traffic and b) is inconclusive because normal traffic interferes with speedtest.

So again, speedtest is really not the tool for routine assessment of network state.

Better would be to run monitor command on WAN interface and combine it with ping results ... if ping round trip time increases above acceptable threshold (e.g. twice the normal one) and interface monitoring shows speeds far below subscribed/acceptable, then it's time to switch (note that RTT can increase due to congestion in any of directions). Ping latency is a "poor man's" way of determining if actual throughput is limited by some bottleneck (when data is buffered on any of sides, RTT will increase ... by how much depends on buffer sizes but since many vendors go the buffer bloat to get maximum throughput as high as possible, this also makes maximum latency quite a bit higher) or the throughput is low due to low demand. The observed throughput (in those moments with increased RTT) will show you how narrow the bottleneck is.
And all of the above without affecting normal traffic by executing silly tests.

You will have to ask your provider A how you can query the state of that bandwidth limitation.
E.g. they provide you with a web URL that you can fetch and that returns a simple status, not some large HTML page.
Now of course, you depend on if your provider makes that available in a usable form.

That's the problem, in my country there are very rarely internet providers that provide this, not even being honest if bandwidth drops do occur. In such conditions speedtest becomes a faster and more honest solution.

When the bandwidth that I subscribe to from A drops to 1Mbps, how can I make the internet access route switch to B automatically other than using the speedtest results as a parameter?

While uplink to provider A is in use, running speed test a) interferes with normal traffic and b) is inconclusive because normal traffic interferes with speedtest.

So again, speedtest is really not the tool for routine assessment of network state.

Better would be to run monitor command on WAN interface and combine it with ping results ... if ping round trip time increases above acceptable threshold (e.g. twice the normal one) and interface monitoring shows speeds far below subscribed/acceptable, then it's time to switch (note that RTT can increase due to congestion in any of directions). Ping latency is a "poor man's" way of determining if actual throughput is limited by some bottleneck (when data is buffered on any of sides, RTT will increase ... by how much depends on buffer sizes but since many vendors go the buffer bloat to get maximum throughput as high as possible, this also makes maximum latency quite a bit higher) or the throughput is low due to low demand. The observed throughput (in those moments with increased RTT) will show you how narrow the bottleneck is.
And all of the above without affecting normal traffic by executing silly tests.

I have done it before. Unfortunately, there are many drawbacks of this method. WAN interface monitoring cannot show actual results whether bandwidth is dropping or not. Likewise with ping, whether the bandwidth conditions are good or drop, the ping results are both good.

How do I know if my bandwidth is dropping or not if WAN utilization is low and ping is good?

In this case the monitoring of the WAN interface combined with the ping results failed to identify the status of the internet bandwidth. Especially when the utilization of the WAN interface is low, bandwidth conditions are declared to be dropping even though the actual results of the speedtest show good results.

Simply put, "Monitoring the WAN interface shows the utilization of the WAN interface, not the actual maximum bandwidth I can use".

It's like driving a car at full speed inside a city, just for check if it can still reach the max speed...

Well, it is a similar problem as "I want to use a queue on my internet uplink to do QoS, but I do not know exactly how fast my uplink is because it is VDSL and the speed depends on line quality etc".
You would want to have some way to poll the current uplink speed from the modem (using a telnet chat, an SNMP query, or whatever) and then take 95% of that and put it in the max rate of the queue.
Preferably you would want the max rat of the queue children to be configured as a percentage of the actual rate of the parent, rather than a fixed rate.

But it remains a dream... too many hurdles to overcome. Fortunately my current VDSL modem can do QoS based on 802.11p so no need to worry anymore, except that this of course exposes RouterOS bugs in DSCP handling.

It's like driving a car at full speed inside a city, just for check if it can still reach the max speed...

LOL, so true. ...but you see how long your waiting at traffic lights. But overall this seems like a queue management problem – you can add some "express lanes through the city" that help, but not everyone can use them.

The thing you can do is watch latency as a proxy for bandwidth, not perfect however. For HTTP, and TCP generally, speed is pretty well correlated with latency.

The new "http" and "icmp" tests in /tool/netwatch might help here. Still ain't going to tell you top speed.
There is also the older /tool/ping-speed — its guess at speed is plain wrong – but the difference between multiple runs is meaningful, since it uses latency as a proxy.

In either case, if you run some "real speedtests"... when latency is high and low (as measured by /tool/netwatch "icmp" check, or the "fake speeds" of /tool/ping-speed) – you can see how they correlated yourself. high ping time == lower speedtests

But it remains a dream... too many hurdles to overcome.

Well also true. I still like to be able to easily fail a route if latency is high, since icmp is can safely measured (unlike a "speedtest" which is just a bad idea if already congested). The simple "check-gateway=ping" is rather limited, and part of the issue at hand.

If you have multiple routes, and one of them is >500ms, that's just not going to very usable in most cases. See: viewtopic.php?t=192844 – no panacea but that be progress.

How do I know if my bandwidth is dropping or not if WAN utilization is low and ping is good?

You can't be sure but if buffers are not filling and thus ping is not increasing, it's pretty safe to assume that bandwidth is higher than required throughput at that particular moment. Meaning that there is no problem (even if bandwidth dropped below subscribed).

But the illustration by @rextended is pretty good: when you drive at car's full speed through a city (where there are lots of slower cars on the street), other traffic affects your assesment (due to lots of traffic, you only manage 70km/h ... so did your car loose all the speed?). At the same time your lunatic driving upsets other drivers and they complain to traffic police (if you're lucky and they're not, then traffic police is you ... but they'll be mad at you anyway).
So when trying to test if your car still has the umph, you make sure you're on German autobahn and tgat it's a quiet stretch without much of traffic. Ditto for the speedtest, you do it when traffic is low and you don't upset many other people.

It's like driving a car at full speed inside a city, just for check if it can still reach the max speed...

LOL, so true. ...but you see how long your waiting at traffic lights. But overall this seems like a queue management problem – you can add some "express lanes through the city" that help, but not everyone can use them.

The thing you can do is watch latency as a proxy for bandwidth, not perfect however. For HTTP, and TCP generally, speed is pretty well correlated with latency.

The new "http" and "icmp" tests in /tool/netwatch might help here. Still ain't going to tell you top speed.
There is also the older /tool/ping-speed — its guess at speed is plain wrong – but the difference between multiple runs is meaningful, since it uses latency as a proxy.

In either case, if you run some "real speedtests"... when latency is high and low (as measured by /tool/netwatch "icmp" check, or the "fake speeds" of /tool/ping-speed) – you can see how they correlated yourself. high ping time == lower speedtests

But it remains a dream... too many hurdles to overcome.

Well also true. I still like to be able to easily fail a route if latency is high, since icmp is can safely measured (unlike a "speedtest" which is just a bad idea if already congested). The simple "check-gateway=ping" is rather limited, and part of the issue at hand.

If you have multiple routes, and one of them is >500ms, that's just not going to very usable in most cases. See: viewtopic.php?t=192844 – no panacea but that be progress.

That's the problem, internet bandwidth is dropping while the ping results don't always show an increase in latency. The less frequently the buffer fills, the more difficult it is to see an increase in latency.

High ping time == lower speed test, hmmm that's not entirely true because on a network with high bandwidth usage the ping time will also increase. (assume no QoS on ping)

So in all the tests that I have done, ping cannot be used as a parameter to reroute internet access to a backup provider because ping fails to translate whether bandwidth is dropping or not.

Of course this will be difficult if we use the assumption that High ping time == lower speed test, looks like we want to measure the width of the road using a thermometer. How are we going to convert the temperature indicator inside the thermometer to measure the width of the road? It's still too far to convert it to units of length.

That's why speedtest is used as a reference to measure the actual bandwidth that we can use. At least the measurement results show clear indicators without wild assumptions.

Back to the question, "how do you change internet access routes automatically if bandwidth is dropping? (without using speedtest as a parameter).

Then if you are sure that the ping can represent the speedtest, what will you do if it turns out that the bandwidth is dropping but the ping time is low?

Back to the question, "how do you change internet access routes automatically if bandwidth is dropping? (without using speedtest as a parameter).

When your links are always saturated (i.e. you are one of those "WISP" companies that re-sell 20 Mbps of bandwidth to 100 customers), you can watch the actual rate of the link and see if it drops below some normal value.
When this is not the situation, i.e. the link rate is often below what you would call "dropped bandwidth", the answer probably is that it isn't possible.

Back to the question, "how do you change internet access routes automatically if bandwidth is dropping? (without using speedtest as a parameter).

When your links are always saturated (i.e. you are one of those "WISP" companies that re-sell 20 Mbps of bandwidth to 100 customers), you can watch the actual rate of the link and see if it drops below some normal value.
When this is not the situation, i.e. the link rate is often below what you would call "dropped bandwidth", the answer probably is that it isn't possible.

That's right, that's why right now what I'm doing is monitoring the WAN interface, if the utilization seems low then run a speedtest, not a ping test.

If the speedtest results are good then there is no need to change routes, but if the speedtest results are bad then change routes immediately because that clearly indicates bandwidth drops. Everything is done automatically on the router.

Then for those who are convinced that the ping test is an effective solution, please explain how you would solve this.

5 minutes ago I did a speedtest and got results like this.


Now I did a retest and got a result like this


Look at the ping, are you sure the ping test is an effective parameter for switching routes?

That's right, that's why right now what I'm doing is monitoring the WAN interface, if the utilization seems low then run a speedtest

But when your ISP drops your bandwidth when they think you use too much data ("fair use policy" or "data cap"), would you not cause a feed-forward loop where you cause the problem in the first place by pumping useless data (speedtest) over the line?
It seems better to monitor the effective speed of individual TCP sessions that you know to be uploads/downloads to/from fast servers. E.g. users sending e-mail or cloud files.

please explain how you would solve this.

Is easy: do not do speed tests. The problem appear only when you do that.
If the problem is another service that do not work, I check that service instead do useless speedtesting for kids.

Some ISP put on the max precedence speedtesting, other drop useless repetitive testing.
Probably your line is ok, is the speedtest service that is blocked, before your play with it too often.

That's right, that's why right now what I'm doing is monitoring the WAN interface, if the utilization seems low then run a speedtest

But when your ISP drops your bandwidth when they think you use too much data ("fair use policy" or "data cap"), would you not cause a feed-forward loop where you cause the problem in the first place by pumping useless data (speedtest) over the line?

Let's assume the internet provider doesn't apply a fair usage policy, and I also don't speedtest too often.

It seems better to monitor the effective speed of individual TCP sessions that you know to be uploads/downloads to/from fast servers. E.g. users sending e-mail or cloud files.

It looks the same as speedtest, but done manually by humans

please explain how you would solve this.

Is easy: do not do speed tests. The problem appear only when you do that.
If the problem is another service that do not work, I check that service instead do useless speedtesting for kids.

Some ISP put on the max precedence speedtesting, other drop useless repetitive testing.
Probably your line is ok, is the speedtest service that is blocked, before your play with it too often.

Is it not clear enough that I am mentioning "automatically" in my question?

If it's just manual, you don't need a network engineer, turn off the modem whose bandwidth drops, then the problem is solved.

If it's just manual, you don't need a network engineer, turn off the modem whose bandwidth drops, then the problem is solved.

It's hard to translate, I'm not English, but let's put it this way:
If for some reason independent of the ISP, netflix doesn't work, do a speedtest?
Or maybe the most logical thing is to open something else like Disney+???
(names and brands, examples only)

How can you tell when there is no bandwidth in a connection, if you don't test it continuously, incessantly, 24 hours a day, 7 days a week?

Doing it "automatically" occasionally does nothing but create interruptions when maybe the bandwidth is needed, also in your own connection,
and if I were the provider, who sees that from what you wrote, the lines are a pittance, I'd be the first to block the speedtests so as not to break the f–k to the others who pay.

It's hard to translate, I'm not English, but let's put it this way:
If for some reason independent of the ISP, netflix doesn't work, do a speedtest?
Or maybe the most logical thing is to open something else like Disney+???
(names and brands, examples only)

Why is the question going to Netflix? Disney+ ? If the problem is only specific to a particular application then the solution is not speedtest or ping.

How can you tell when there is no bandwidth in a connection, if you don't test it continuously, incessantly, 24 hours a day, 7 days a week?

This happens to the internet bandwidth, not the specific application. Take a look at the screenshots of my speedtest results.
What if I test the speedtest with a file size of 2MB, does it not look like normal web browsing?

If using speedtest looks weird, using ping which results are even weirder. In my case, the difference in ping results is very slight when the bandwidth drops. The latency is even better when the bandwidth drops. So the use of ping is very very unreliable.

Is there really no automatic solution to switch internet access routes when the bandwidth on the main route is dropped?

Doing it "automatically" occasionally does nothing but create interruptions when maybe the bandwidth is needed, also in your own connection,
and if I were the provider, who sees that from what you wrote, the lines are a pittance, I'd be the first to block the speedtests so as not to break the f–k to the others who pay.

If the solution is just turn off the modem. It's easy like you said but we will keep doing boring things again and again in our life.

Is there really no automatic solution to switch internet access routes when the bandwidth on the main route is dropped?

Do you have access the ISP routers that are your next-hops? If not, then answer is NO.

You can focus on what gets prioritize, so those go out first. Traffic can go into the "right" queues "automatically" on your end, for your needs. But the measurement for that is does the application/website/etc work at an acceptable level. Not a HTTP speedtest.

Is there really no automatic solution to switch internet access routes when the bandwidth on the main route is dropped?

Do you have access the ISP routers that are your next-hops? If not, then answer is NO.

You can focus on what gets prioritize, so those go out first. Traffic can go into the "right" queues "automatically" on your end, for your needs. But the measurement for that is does the application/website/etc work at an acceptable level. Not a HTTP speedtest.

Yes, from this discussion I have summarized 3 possible ways that can be done to change routes when bandwidth drops.

1. Check manually while waiting for complaints from the user, then move.
2. Using observation of the WAN interface and ping time although not always accurate (see the example of my speedtest results, I guarantee that if the parameters are ping time/latency, anything related to ping then failover will never succeed).
3. Using speedtest parameters which are still experimental.

All are possible to do depending on your needs.

2. Using observation of the WAN interface and ping time although not always accurate (see the example of my speedtest results, I guarantee that if the parameters are ping time/latency, anything related to ping then failover will never succeed).

You decided to misinterpret what I wrote ... and the problem with screenshots you posted is that speedtest does latency test before performing (uni-directional) speed tests. If upstream link is not congested during latency test, then latency times for sure won't show link degradation. So yes, I agree, simple ping times can't detect link bandwidth degradation if it's (current) capacity is not used entirely. But it seems you like to bother about bottlenecks which don't really degrade performance.
I'll repeat: observe ping times and if they get higher than usual, observe actual throughput via WAN interface. If throughput via WAN interface is lower than expected/subscribed (and that's during higher ping times!), then WAN link bandwidth got reduced.

2. Using observation of the WAN interface and ping time although not always accurate (see the example of my speedtest results, I guarantee that if the parameters are ping time/latency, anything related to ping then failover will never succeed).

So yes, I agree, simple ping times can't detect link bandwidth degradation if it's (current) capacity is not used entirely.

I'll repeat: observe ping times and if they get higher than usual, observe actual throughput via WAN interface. If throughput via WAN interface is lower than expected/subscribed (and that's during higher ping times!), then WAN link bandwidth got reduced.

Let's say there is a higher ping time, but the utilization of the WAN link is low, how do you conclude that the WAN link got reduced or not?

Be aware that screenshots of the speedtest results also occur during peak hours. If you use the ping time and bandwidth utilization parameters, then it is certain that the router will fail to execute the internet access route change command.

See that during peak hours it turns out that my ping results are only slightly different from normal conditions, even the latency is better when the bandwidth drops.

All methods have advantages and disadvantages, from manual methods, using ping time and WAN link parameters, including speedtest.

Because this topic is a http speed test topic so suggest a speedtest application, and that's okay. If the topic author requires an http speed test, why not?

Why not? because http speed tests are for end users, for humans. They want to have a site where they can confirm that their nice new 1Gbps internet connection indeed transfers data that fast.
They are not for use in scripts. When you want to measure the speed of your line in some script, you don't use a http speed test. You use the bandwidth test tool, you use iperf3, whatever. Not a http speed test.

Why not? because http speed tests are for end users, for humans. They want to have a site where they can confirm that their nice new 1Gbps internet connection indeed transfers data that fast.
They are not for use in scripts. When you want to measure the speed of your line in some script, you don't use a http speed test. You use the bandwidth test tool, you use iperf3, whatever. Not a http speed test.

Is it true? In numerous tests in my case it turned out that monitoring ping time and WAN links showed very low accuracy, while using speedtest on my network to automate internet access route switching based on bandwidth showed much more accurate results.

Maybe some people prefer to do the boring manual way all their lives, waiting for the customer to get angry and then act. But for me and some other people doing a speedtest automatically isn't a problem.

Regardless of other people's opinions like it or not, in my case using speedtest is much more powerful than just ping.

If you think it's better to use the manual method then do it, if you feel the use of ping time parameters and WAN link monitoring is more suitable for use in your network then use it. Because both solutions are troublesome and inaccurate for me, I offer another solution that has been tested to have high accuracy on my network.

...using speedtest on my network...
...automate internet access route switching based on bandwidth...
...some people prefer to do the boring manual way all their lives...
...waiting for the >>>customer<<< to get angry and then act
...for me and some other people...
...other people's opinions...
...my case using speedtest...
...for use in your network...
...I offer another solution... ...my network...

You make senseless mixed talk.
1) Is it just your home or your office?

2) Do you have several clients to whom you supply the connection which you in turn take from two other connections, one 10M and one 5M and that's it?

3) Are you an ISP? If not, don't speak as a supposed "customer connoisseur"™
Some of the speeches you make are nonsense that only beginners can write or do.
There's nothing worse than starting automatic tests (perhaps with an aggregated timetable) which will certainly piss off the customers,
because they just happen to be using the line at that very moment.

4) It makes no sense to say that you start the test when there is a slowdown, because otherwise it means that you already know when it slows down.

5) To make reliable pings you don't have to look at the ping result on the speedtest servers.
They are NOT Certificate Authorities and often do badly because of all the idiots who stay all day just speedtesting.
They don't have infinite bandwidth with machines with infinite power...
And often those who are doing speedtests all the time are the ones who piss off other people, subtracting their bandwidth,
Because, whether you like it or not, unless you have a guaranteed minimum bandwidth contract, all connections are on shared bandwidth,
that's why we talk about fair use...

In Italy they say "There is none worse deaf than those who don't want to hear"... at least be clear when you write.

1) Is it just your home or your office?

My home and my office

2) Do you have several clients to whom you supply the connection which you in turn take from two other connections, one 10M and one 5M and that's it?

Yes

3) Are you an ISP? If not, don't speak as a supposed "customer connoisseur"™

No, I have never said or behaved like that. That's what you think, I don't think so.

4) It makes no sense to say that you start the test when there is a slowdown, because otherwise it means that you already know when it slows down.

I never said that, I said "when the WAN link utilization is low". Those are two different things.

If someone feels that speedtesting via router will result in blocking the service, that's their problem, not mine. They couldn't generalize that all networks would behave the same as theirs. I've been using speedtest all day long for the last 8 months and until now my internet provider has never had a complaint or service cut off.

See that in fact the ping time and WAN link monitoring solution doesn't work on my network. If someone asks me to return to the manual method or monitoring ping time and WAN links. Of course I'm not going to do such a ridiculous thing . If you've found the right solution why go back to something that is sure to cause problems, right?

This is a forum, your opinion is accepted or not, it's normal, no need to get angry.

Angry? Why?

It wasn't clear early on that you are NOT an ISP.
If you were a real ISP, you didn't even write some things.
Since from the speeches (translated from Indonesian?) one never had a clear idea of what you were doing until I asked you.

Now I understand, you buy from someone (perhaps real ISP?) two 10M and 5M lines (as you say), and sell them to others.
I don't know what social/cultural problems are present in your region for which you have "cuts" that elsewhere seem poor,
so I refrain from any judgment, I simply think about how small the "cuts" you sell are...

Unless you want resell "your" 10M to other users... always as 10M each...
The most logical thing is to divide the 2 connections more or less equally among the various X customers, proportionally,
so that they don't step on each other's toes, and maybe the slowness of one is the overbooking of the others...

Emro Batmok ot Meok.