In NetQoS's resource room, we've got a free Web-based app called the NetQoS Network Estimation Tools (or "latency calculator" for short) that allows you to calculate the theoretical latency of network connections under a number of different scenarios.

The NetQoS Network Estimation Tools, a.k.a. latency calculator

Allow me to clarify: A number of different plausible scenarios. Like, for example, if you knew that there was a 5ms router latency, a 20ms server latency, and a link distance of 100 miles, you would be able to get the overall theoretical latency of that connection, whether it's point-to-point or frame relay. However, it will not give you the latency involved in IP over Avian Carrier connection. Plausible scenarios only.

In addition to the main latency calculator, there are several sub-tools, such as an Ethernet packets per second calculator, a link speed calculator (with packets per second and packet size as inputs), a multicast calculator that will give you the Multicast Low Order and a MAC address, a HEX to decimal converter, and other tools useful for the network engineers at their desks and in the field.

The calculator was invented as a teaching tool by Bill Alderson, who has been diagnosing problems in large-scale networks for 25 years. We asked him what some of the uses for the calculator were out in the field.

Bill Alderson: You can use it to calculate how long it would take to do an FTP transfer from a 400 MB file to… whatever. So it's pretty easy and simple, it does take a little bit of instruction, but the latency calculator counts the number of round trips that are required and you can make the size whatever you'd like. Instead of having a packet size with a 1500 or an 8000 byte MTU maximum, you can simply crank in a 450GB file, and it'll tell you how long it'll take to serialize that file across the links you have selected.

You can put in all of the various entry points which are drop-downs of Ethernet, drop-downs of T1s, sub-T1 speeds, and you can just pick those in there, and then you can change all the sizes and determine, theoretically, how long a transaction should take.

Let's say that you were in Dallas, and you wanted to do a transaction with a server in San Francisco (or Japan or what have you). All you have to from your desktop is to go and ping your destination and find out what your latency is. Then you can make sure that the latency you put in is the same the calculator has. We don't express that latency necessarily in exacting numbers, but we have some general rules the industry has used. I like to teach people from a standpoint of being able to do the math in their head eventually after they've used the calculator 10 or 12 times, they can do this math in their times.

So rather than doing this an exact 186,000 m/s speed of light transaction, I broke it down into very simple things like 100 miles is about 1ms of latency. That way, not only can you use the calculator, which will also calculate serialization, but most of the latency calculations are things that are changing all the time - not exact numbers. The 1ms per 100 miles or 1.5 seconds for 100 miles of frame relay - it works out. It's very very close, especially for the type of things that people want to do.

You try and break down very complex things into very simple things so that the average man or even the non-average man who doesn't calculate those things very often can have an anchor to information that helps them begin to do it in their heads so it's second nature when you do a ping from your desk. If you do go in and do everything exactly, down to the nanosecond, the largest part of the audience's eyes glaze over, and they're completely lost.

When you see when something's 2000 miles away and comes back in 40ms, you see that you're very close to the theoretical. But if it comes back at 92ms, you're going to scratch your head and say, "That's too far away from theory. I'd better do an investigation and analysis to find out why it's so far away from the theoretical." We're trying to give the average man the ability to calculate quickly and see the many outcomes of many different examples, so he can commit these things to memory eventually.

If you have a lot of complex things, you can crank it into the calculator, and people love it. We built it for a learning tool, but absolutely, I've used it in reports and helped people understand. That's what we're looking for: Take theoretical numbers that are very close, and help people simplify those so they can get to the answers and then learn those things so that they eventually don't have to go to the calculator.

Let us know what you think of the latency calculator in our comments section below.