I am trying to reproduce a network-related performance problem from a remote site to a cloud-hosted system I'm responsible for. They get awful performance from their location, I get fine performance from mine. I have a hardware WAN emulator (Apposite Linktropy Mini2 in this case) I can use to try to simulate their network to reproduce the problem. But first, I need to know the performance characteristics of the network between them and the server.
What I need is a concise way that I could have an average user run from their PC or whatever that could sum up bandwidth, latency, packet loss, and whatever else I can get. Ideally they'd just put in a DNS name and generate some numbers they can feed me - I can't have them do all kinds of techie work, make them find a Linux box, etc.
What would a good tool be that would characterize the network between two points?
iperf
is free/open source, runs on Windows and *NIX, supports TCP and UDP to test bandwidth, latency, jitter, packet loss, etc.Do they have other networking issues? e.g. dropped broadband, slow performance in general etc?
You could try several runs of speedtest.net to the nearest location to the cloud hosted system. Pingtest.net several runs.
Then set up ping plotter to ping the the cloud based system which will give you an idea of packet loss etc.
It's entirely possible they have other issues or a router between them and the remote system is faulty or badly set up. It may even be their own router.
It sounds like Qcheck might be the tool for the job.
http://www.ixchariot.com/products/datasheets/qcheck.html
Try mtr , it is great for this kind of thing. nmap can help with scanning the network to understand it better.
You want to analyze the paths being taken in a traceroute , you might find there is a dodgy provider in the middle somewhere dropping lots of packets or a sub-optimal path is being taken.
You could use bing. It has restrictions - it uses ICMP and cannot work end-to-end if the client uses a NAT router, but you should be able to get a bandwidth estimate. If the performance is not constantly bad, you might need to use some kind of logging over an extended period of time.
If you suspect that latency or packet loss is the reason for bad performance, you might just as well inspect the TCP control flow after a packet capture - if you see slow starts or retransmissions from your side, you know for sure.