Also, when things start to go wrong it is so useful to be able to compare ‘now’ to ‘normal’ and quickly zoom into where problems may have come up.
Remember, ‘the network’ will vary for each of us. It typically includes some local networking within the office or home, some access network to get us to a wide-are or cloud network and then there is the wider public internet. Of course, we may also run a private VPN over the top of some of this.
This is a ‘summary’ style of post so let’s just jump straight into the 5 measures:
Latency is also referred to as delay – it is the time it takes for a some data to get from once place to another, in fact, these days it is usually expressed as a round trip measure so it is the time taken for some data to get from one place to another and back.
The obvious impact of long delays is that users experience a pause before the action they requested actually happens. In the case of a website this might be the time taken before a click on a link, button or menu option starts to ‘work’.
Generally, two things impact delay. The first is just physics, how far does the data need to travel and how long does that take. For example a packet going anywhere inside your building is only going to take a few milliseconds (or at most tens of milliseconds) to get there and back. If that same packet has to go from Sydney to New York, or it has to go up to a satellite and back (maybe twice!) or it goes over a mobile network then they basic physics will change those few milliseconds into hundreds of milliseconds or even into full seconds. For a given path the physics don’t change so your base level latency between point x and y over the same network path will usually be pretty similar.
The second big thing that affects latency is congestion. If a network is busy then your data can be queued while it awaits space on a link. This can lead to varying latencies on the same network path between two points.
Now, there are all sorts of subtleties, protocol-specific and application specific details that can come into play but these are the latency basics.
Loss is a measure of how much of the data you send gets irretrievably dropped or discarded in the network. While it sounds dreadful, those applications that need guaranteed delivery will have retransmission protocols built in.
The end result of loss is usually a slow down in performance as lost data needs to be resent, usually along with any data that came after the lost bit. This did the common affect of loss on browser based applications – for some applications, like voice and video, loss has a direct impact on sound or picture quality rather than introducing delays.
It is complicated and very application/protocol specific – we explain it in a more detailed post which we will link here soon.
Network throughput (or speed) is one of the most loosly defined measures we have, yet the one we see thrown about by tech companies, service providers, users and even governments!
For this post we think of throughput as the amount of data that the network can sent between two points in a network over a given period of time.
It can be measured in bits-per-second or bytes per second – to keep the numbers management we then use ‘kilo’, ‘mega’ and ‘giga’ just like we do with disk space it is usually agreed that there are 8 bits in a byte so 1 megabyte-per-second is equivalent to 8 megabits-per-second.
Throughput and speed can be measured at different places in the network, using different protocols and may be ‘attached’ to physical components or particular applications and end points. We explore all of this in more detail in our throughput specific post which will be linked here soon.
Availability or Downtime
“One man’s loss is another man’s downtime” – yes, availability is another one of those poorly defined measures.
‘The network is down’ is a common lament from our users. It may be down, it may be so ‘lossy’ as to be unusable for their application – either way it is important to establish your way of defining and then measuring availability.
Availability definitions will have to consider the local network, the network access, wide-area, VPN and internet and then, it will have to consider the destination and application too. A little thought will help you measure availability of the network rather than of a distant website or application.
We discuss availability in some detail in another post that will be linked here soon.
Jitter comes into play with interactive voice and video services such as IP Telephony or video conferencing.
Jitter is the variation in the spacing between packets. If you imagine sending a packet every second, jitter is the measure of how far from a second they are spaced when they get to the other side.
When sampling and packetising voice and video it is important that the packets arrive at a steady rate and don’t get ‘bunched up’ in the network as this leads to gaps, skipping and other ‘call quality’ issues.
Jitter is rarely important for other application types such as browsing websites.
A Parting Thought
These network measures are all important and need to be considered in the context of how your network is being used.
Over our next few posts we are going to do a little more definition of each of these and explore what hidden impacts lie under the surface of each one. When will link to these new posts as they become available.
Almost without exception, you will also need to include measures for the underlying user platforms (desktop or laptop computers) as well as for the applications running over the top of your network.
We have sister posts coming titled “Top 5 Basic Platform Measures”, “Top 5 Basic Browser Application Measures” and “Top 5 Basic Voice Application Measures” – we will link to them here when they available.