3

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.

5 Answers 5

1

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.

0

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.

0

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 ...

1
  • 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, 2011 at 10:47
0

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:

#!/bin/sh
# Time ping is run (in seconds)
TIME=50
# size of the ping data (in bytes, without header data)
PSIZE=10
# destination IP
DEST=192.168.1.1

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

echo `date` $I >>/var/log/latency_voip.log
-3

ping?

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).

2
  • OP said "tracert just won't cut it". Mar 31, 2011 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, 2011 at 6:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .