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.