Hi All

Relatively new to MikroTik / routerboard so be gentle with me !

I have a customer who has a satellite internet link that at certain times of the day performs terribly, barely usable. I have implemented an hAP ac lite with DNS caching and basic webproxy (all traffic forced via the proxy) but I am wondering if there is any kind of script i could implemented that would monitor thing like latency to say googles DNS, run a basic speed test and the like so that we can demonstrate back to the provider just how bad it is a certain times of the day ?

Any help would be appreciated, thanks.

Of course monitoring/testing the link makes it even worse.
I don't think you have to explain the provider that the link is bad, they know that very well.

Of course monitoring/testing the link makes it even worse.
I don't think you have to explain the provider that the link is bad, they know that very well.

That may well be the case, but its very easy for them to point the finger of blame elsewhere ... and they are.

Any stats at all to prove the issues are at there end beyond doubt can only help in resolving the issues.

Any stats at all to prove the issues are at there end beyond doubt can only help in resolving the issues.

You can use any tool you like, not really related to MikroTik. Use something on a PC.
But I can assure you that those satellite links are 1000-fold or more overbooked and the providers know very well
that the link is always saturated.
Some 10 years ago I did some monitoring of such links, see what was going over them and at what rate, and I
was really amazed what the users had to put up with. A telephone modem would be faster. However, it is difficult
to do it much better given the rent of a satellite transponder, the achievable bandwidth, and what a typical user
would be prepared to pay for the service.
Satellite internet is just not viable. It should only be used as a last resort, when nothing else is available.

Satellite internet is just not viable. It should only be used as a last resort, when nothing else is available.

Which sadly is where we find ourselves

Has a satellite tech checked the gear? A misaligned dish. Bad coax connections. Sun outages due to sun in same position as satellite occurs twice a year.
Too many users as mentioned. User being FAPped as they near bandwidth limits.

Has a satellite tech checked the gear? A misaligned dish. Bad coax connections. Sun outages due to sun in same position as satellite occurs twice a year.
Too many users as mentioned. User being FAPped as they near bandwidth limits.

Looks like its just massively oversubscribed !

Currently looking at LTE as an alternative.

To monitor the uplink you can use Smokeping. http://oss.oetiker.ch/smokeping/
It monitors the latency and packet loss of whatever IPs you configure to.
You can also monitor other stuff, such as HTTP, DNS, etc reply times.

Here's an example graph It doesn't work on Mikrotik, you will need a PC (running preferable linux, but I believe it also works in windows - it's written on perl).
A Raspberry pi will work as well.

Sure, but as I already wrote: you KNOW that your satellite link is heavily overcommitted, and when you add
extra traffic to monitor that situation, you only make it worse. It can be used as a document against the ISP,
but trust me, they already know all about it.
In general, such tools are nice. But not to monitor something that is already bad.

Sure, but as I already wrote: you KNOW that your satellite link is heavily overcommitted, and when you add
extra traffic to monitor that situation, you only make it worse. It can be used as a document against the ISP,
but trust me, they already know all about it.
In general, such tools are nice. But not to monitor something that is already bad.

You are right, because an extra 56bytes * 20 times (*2 for return packets) per iteration(5min) (= 2240 BYTES) will destroy the link completely.

Not to mention the fact that you will 'burn up' a whole 645Kbytes/per day just to monitor your uplink to be able to provide PROOF to your provider (and not a personal experience a decade ago). I mean that's just terrible! Provide proof? Who in their right mind do such a despicable thing

It's one thing, as a provider, to know that you have saturated uplinks and deny it, and it's another to not being able to dispute that when confronted with irrefutable technical evidence (and not decade old opinions). Especially when there are SLAs involved.

Just pinging is not going to do much good, what you would need to do to get some useful stats is to
monitor the download rate e.g. by downloading a file regularly and see how fast that is. This, however,
will additionally load your connection.

It's one thing, as a provider, to know that you have saturated uplinks and deny it, and it's another to not being able to dispute that when confronted with irrefutable technical evidence (and not decade old opinions). Especially when there are SLAs involved.

Exactly and the provider is totally denying there is any kind of problem, so as per my original post, we are looking for any stats to demonstrate how bad it actually is.

Exactly and the provider is totally denying there is any kind of problem, so as per my original post, we are looking for any stats to demonstrate how bad it actually is.

Ok but pinging alone will not prove that. Of course the ping is bad, it cannot be good because of the long trip via the satellite at lightspeed.
What matters is the variance in the ping times, and especially for larger packets. And because you do not know how ICMP and TCP/UDP are
prioritized, it only makes sense to measure using the protocol that gives you bad performance (TCP or UDP).

Hopefully your new LTE connection is performing well. At least LTE has the channel capacity that is required for internet access.