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 (http://forum.mikrotik.com/t/ookla-speedtest-container/163953/1) similar to speedtest.net
You like copy & paste?
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...
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…
So, how to change internet access routes automatically when the bandwidth on one of the routes is dropping?
I have tried many ways:
- Recursive route failover? I have tried that but it won't work if the ping is still running even though the bandwidth drops.
- 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.
- Btest? No one is providing free btest servers in my country.
Sorry but I don't think my question has been answered.
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.
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.
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.
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.
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
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: http://forum.mikrotik.com/t/feature-request-link-check-gateway-in-routes-to-a-netwatch-item-s/163771/1 – no panacea but that be progress.