Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are currently looking at doing some international video conferencing, and before we go ahead and buy a system we need to measure Site to Site Latency & bandwidth objectively.

I can't see any obvious products that will do this - can anybody make a recommendation here as tracert just won't cut it.

share|improve this question

QCheck is a free tool specifically geared to the kind of testing you need to do. You install the endpoint on one end of the connection and run the test tool from the other end.

share|improve this answer

If you are using Cisco gear in your LAN/WAN you should definitely take a look at IP Service Level Agreements (IP SLAs). Using IP SLAs you can measure delay, packet loss and jitter among other parameters from the switch port of one of your endpoints to the switch port on the other end. These values then can be consulted either from the command line or if you need it, polled via SNMP from your NMS.

share|improve this answer

Try using iperf

Iperf was developed by NLANR/DAST as a modern alternative for measuring maximum TCP and UDP bandwidth performance. Iperf allows the tuning of various parameters and UDP characteristics. Iperf reports bandwidth, delay jitter, datagram loss.

Here's a quick run-down of possible uses. And here's a few more tutorials.

The only catch: you need a server and a client. So you need someone on the other end ...

share|improve this answer
we have people at each end so no problem there, although everyone is on windows. Thanks for response Joseph this looks great! – The Waves Mar 31 '11 at 10:47

Additionaly to what's being said already, the bing utility will give a rough estimate of the available bandwidth even without a client-server setup.

I would agree that even ping can give some interesting data - especially packet loss, round-trip-times and mean deviation for RTTs are directly streaming-relevant data. Of course, you would need to run ping with appropriate packet sizes (i.e. the sizes your streaming protocol is going to use) and the necessary frequency (i.e. as often as your streaming protocol is going to send). For a quick glance at a customer's site we are using this kind of script run every minute and evaluate the results:

# Time ping is run (in seconds)
# size of the ping data (in bytes, without header data)
# destination IP

I=`ping -q -s $PSIZE -i 0.09 -w $TIME $DEST | egrep '(packet loss|rtt)'`

echo `date` $I >>/var/log/latency_voip.log
share|improve this answer


Honestly, run a long ping, drop the results into a csv, pull it into the spreadsheet of your choice and run with it. By long, perhaps a day or two to cover the different times of day.

I use little script to pull speed stats (you can get it here).

share|improve this answer
OP said "tracert just won't cut it". – Joseph Kern Mar 31 '11 at 4:36
A single tracert - however 24/48 hours of pings should give a statistically relevant sample. Quite honestly, all anything is doing is getting the transit times from packets at the end of the day. :-) – tsykoduk Mar 31 '11 at 6:51

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.