|
Application speed (as opposed to
Capacity Speed) is the actual real end-to-end
speed that a TCP application will achieve for the
connection being tested. This will encompass all the
inherent TCP flow control delays as well as quality
invoked delays, such as packet loss. In other words it
is an accurate measure created by a test process that
ensures the data flow matches the requirement of the
application such as a Video. See
Capacity Speed.
Analyze your results for possible problems.
Capacity Speed (as opposed to
Application Speed) is NOT usually a measure of
how a connection will perform when used to view a
video or listen to music, but is a measure of the
data rate a connection can sustain, i.e. a Capacity
of the connection. As a result Capacity Speed is
unlikely to provide result that reflects the user’s
real experience.
As an example, if you wanted to measure the speed of
a road to your local airport in passengers per hour,
you would likely fill a large number of cars (or
even busses) to fill every lane on the road with no
gaps, then, over an hour, count the number of people
arriving at the airport. It will be a high number,
something like ten thousand passengers per hour, and
assuming you had no gaps in the traffic it will
reflect the maximum passenger per hour speed.
However, and this is important, when you yourself,
want to drive 20 people to the airport using your
car which only takes 5 passengers; your speed in
passengers per hour will be limited by how far you
are from the airport (in time). If you are an hour
away, your speed will be 5 passengers every 2 hours
(one hour out and one hour back) or 2.5 passengers
per hour. This analogy gives a clear indication how
Capacity Speed will differ from Application Speed
and provide misleading results.
Analyze your results for possible problems.
When the trip time of a connection exceeds the time
for processing the data at the slowest point (usually
the end user connection), the throughput will naturally
slow as the connection is forced to idle waiting for
the data to be confirmed. A capacity test uses this
idle time to start another transfer thus driving the
connection to its capacity. The sockets used indicates
the extent that the test duplicated the data
transmission to measure the capacity speed. The greater
the difference in speed of the connection to capacity
of the connection the more sockets (limit 8) will be
allocated. A single socket indicates the test is
running as an application test which does reflect the
true user speed for the connection.
Analyze your results
for possible problems.
How smoothly data flows across the connection,
determines the Quality of Data result. If a connection
has quality problems caused by congestion
(oversubscribed) or regulation (ISP policy
management) then the data flow will be erratic, fast
one minute and then slow the next. Although the speed
measure may meet your requirements understanding how
the quality of the data flow affects application
perform, is important. Real-time applications such as
Video, Voice and Music, demand a consistent quality
data flow.
Analyze your
results
for problems.
Max delay is the maximum amount of time spent idle
waiting for data to arrive from the other end of the
connection being tested. A high (greater than 100ms)
Max Delay is a good indication of a connection quality
problem. Using the traffic highway as an example, Max
Delay for a car journey would be analogous to being
stuck in traffic jams, or at many red lights that
delays your arrival at the destination, causing those
waiting for you to wait idle. It is inevitable that
some connection will have inherent idle time because
the length of the journey is very long. The same is
true of an Internet connection which is affected by
the length of the connection being tested.
Analyze your results
for problems.
RTT (Round Trip Time) is a very important
baseline measurement because it provides the
foundation measure of the connection length as a
measure of time in milliseconds. The higher the trip
time the slower most applications will perform on
this connection. If you read the example provided in
Capacity Speed, the RTT is a measure of how long
it will take you to drive to the airport and back.
Because you have to return to collect more passengers
the throughput speed will be wholly dependent on the
RTT time.
Analyze your results
for problems.
The Window Delay is a calculated metric to derive
the inherent delay for the connection being tested. It
is a useful metric to match against the Max Delay
because it indicates if the Max Delay being report
exceeds the expected delay for the connection. In
other words, as a simple example, if your drive home
from the airport takes 60 minutes, then those waiting
for you to arrive should expect a 60 minute wait
(delay) before you arrive. If your time to home turns
out to be 90 minutes then this is a fair indication
that the journey encountered ‘interference’ delays.
Analyze your results
for problems.
Forced idle is brought about by the requirement
for TCP to make sure that all the data has arrived
safely at the remote end before sending more data.
As a real life ‘simple’ example; if you have twenty
passengers to send to the airport, and only one car
that can take 5 passengers at a time. With the
airport being 30 minutes away, then you will have to
wait 60 minutes for the car to return (30 minutes
each way) before you can send the next set of
passengers. This is effectively your Forced Idle
time as you have nothing that you can do with the
remaining passengers until the car returns.
Now TCP, in reality, has more than one car and may
millions of bytes. The rule to understand as it
applies to the application using the connection, is
that when the data load exceeds the max capacity of
the transport available (which it nearly always does),
and the journey time for all the data to arrive is
shorter than the time for the round trip then you will
always have TCP forced idle. In other words the last
car load of data will have been processed before the
first car has returned for reloading. This is a simple
example but hopefully provides the understanding of
the process of why longer routes have slower speeds.
Analyze your results
for problems.
The ‘of about’ number is an important metric as
it provides a good indication of a connection’s
maximum speed, when running an
Application Speed test. This ‘of about’ number
should match the speed of the service being provided
by your ISP. Keep in mind the slowest part of
a connection is nearly always the testing user’s
connection, if this is not the case then the results
may differ, an early sign of congestion/regulation
problems. Assuming the network is running without
major problems, identifying the flow rate at the
testing location allows the test process to derive
the capacity of the connection. As an example, if
the data packets of 1400 bytes has an arrival
distribution flow of 2.4 milliseconds then the
capacity of the connection will show as about
4.6Mbps.
Analyze your results for problems.
Cars are affected by traffic lights because of
the need to regulate traffic flow, especially
prevalent during peak loads such as the rush hour.
Similarly Internet connections also use flow
policies to manage load. Data flow control (packet
shaping) is common across the internet and one of
the most common ‘tricks’ used is ‘ramp-up’ and
‘ramp-down’.
Ramp-up is the process by which data gets faster
over time if a lot of data is detected. A bit like
traffic sensitive lights, which turn green and quickly
back to red when there are a few cars waiting but stay
green longer, to improve throughput, when a lot of
cars are detected. This is common for high latency
connections such as satellite and certain wireless
connections.
Ramp-down is the opposite to ramp-up. To provide a
good user experience, ramp-down give you a lot of
speed up front but after a while the data flow starts
to degrade when it detects that there is a lot of data
present. Cable providers often use this type of packet
shaping policy, although it is sometimes based on time
used rather than data volume.
Analyze your results
for problems
The clock resolution should never be more than 1
millisecond for accurate speed test results. Most
speed testers take the simplistic approach of
measuring data to the nearest second to compute a
speed. The problem with this approach is that, besides
not being accurate, it does not provide sufficient
information to resolve problems when the connection is
not healthy. A 'second' is a huge amount of time in
the life of a high speed network connection, several
million bits of data will pass in one second.
Any speed measuring application demands an accurate
timer but this is not straightforward on a PC platform
as the processor is contended for by all applications.
To combat this MyConnection PC validates the clock
resolution prior to starting the testing process and
reports the result in units of 1 millisecond (one
thousandth of a second) as part of the test.
MyConnection PC then carefully manages the timing
process during the test to ensure that the resolution
of the clock is not affected by the test process. By
maintaining a 1 millisecond timer MyConnection PC is
able to accurately measure many critical elements that
affect a connections throughput, namely, packet flow,
data consistency, data quality, delay frequency,
Jitter as well as speed. This allows MyConnection PC
to detect problems such as packet loss and the impact
of data recovery or packet shaping policies.
As a real life example of timer resolution importance
to a result, imagine timing the 100 meter sprint at
the Olympics, using a one second granular stopwatch,
where first and second place can be separated by a
hundredth of a second or less. Who would get the gold!
Timer accuracy is material to the end result.
Analyze your
results
for problems.
If asked how long it takes to get from New Jersey
to downtown Manhattan you would most probably reply
‘it depends’. It depends on which route is used as
some routes deliver faster throughput than others and
it depends on what time of day. The same dependencies
also apply to the Internet.
Any and all Internet connections traverse what is
called an Internet route between the testing location
and the testing server. Understanding the route is
crucial to understanding throughput issues. Tracing
the route is a process that identifies all the network
segments that connect the start device (users PC
usually) to the testing server. Each network segment
is referred to as a hop and tracing the route
end-to-end identifies the ownership, location,
response time and quality of each network hop. The
network hops that join two networks owned by different
providers are called ‘peering points’ because it is
the point at which two peering networks join. As a
results of the joint responsibility, Peering Points,
by their nature are prone to having problems.
As a more everyday example, when you travel from
you home to the airport. If you are far away from the
airport, it is likely that you will traverse several
different roads to get to the destination. Some maybe
fast roads with light traffic, and some may be slow
with congested traffic and traffic lights. In
comparison, if you live near the airport you may be
lucky enough to have just one or two roads to navigate
to the airport. A short route (6 hops or less) will
nearly always perform better than a long route
assuming the same distance is covered.
In all cases the route test measures the response
time and quality of each network segment independently
(i.e. each road used) and reports the quality and
performance of the entire journey end-to-end as well
as segment-to-segment. By doing this it is easy to
identify if the route is a poor route (length) or if
certain segments are not performing well. The trip
time (max, min and average) are reported along with
the packet loss. Packet loss is simply when
congestion and other quality issues stop packets from
ever reaching the destination. Remember the faster the
route latency end-to-end the faster the connection
speed that can be attained.
Analyze your results
for problems.
The inability for the connection to transport the
packets in the same amount of time is called Jitter.
Voice over IP uses UDP not TCP as the protocol because
the packets are heavily time-dependent and therefore
the sending end does not want to worry if all of the
packets have arrived at the destination. What matters
the most to real-time protocols such as VoIP or Video
is that most of the packets arrive at the same rate.
Imagine, for example, having a conversation with a
colleague where the amount of time between each word
varied between one second and thirty seconds. Such a
conversation would be hard to understand because you
would give up waiting for the next word to be spoken.
A sentence like ‘hello, how are you today’ could take
over a minute may be two. In an ideal network, the
transport will send the packets between the two
locations in the same number of milliseconds for every
packet. In reality that never happens and the packets
vary to some extent. The amount of that variance is
jitter which is measured in milliseconds. Jitter
should be consistently lower than 3ms-5ms.
Analyze your results
for problems.
Packet Loss is simply a measure of those packets that
never made it to the destination. It is not a major
problem so long as the packet loss is low and evenly
distributed.
VoIP and other real-time protocols use UDP for time
dependent data. This is because the network cares more
about timeliness of the packets than recovery of the
packets if a packet is lost. Obviously a lost packet in
a bank application could turn a $1000 into $100 which
would not be good. However in a Video or a Voice call
the loss of a packet may lose part of a word but it
unlikely to make a material impact on the meaning of
what is being spoken or viewed. That said, if packet
loss is badly distributed (i.e. all the loss is in one
second) or the percentage of loss is high (greater than
1%-2%) then the quality of the Voice or the Video will
degrade.
Analyze your results
for problems
Certain packet protocols are critically time
dependent, for example UDP for a VoIP telephone call. In
time critical environments it is possible that packets
are delayed so they arrive outside the time windows for
being used. In this situation the packets are discarded
as they no longer have purpose. This is a bit like
arriving late for your flight or train, effectively you
are not included.
Analyze your results
for problems
The MOS, or Mean Opinion Score, is a
numeric measure used for VoIP, indicating the sound
quality at the receiving end of a communication circuit.
Although the score is subjective it provides a
widely-used method to rate the quality of voice
communication in a simple way that meaningful to end
users. The score is normally between 1 and 5 with 5
being the best.
MyConnection VoIP tests the line quality and measures
the highest MOS that a connection can achieve - this is
independent of the Codec selected for the VoIP test. The
MOS value is reported in the MyConnection VoIP summary
tab once a connection test complete. A VoIP simulation
that drops below 3.5 is considered poor quality; a
measure of 4.2-4.5 is considered good quality.
|
MOS |
Quality |
Impairment |
5 |
Excellent |
Imperceptible |
4 |
Good |
Perceptible but not annoying |
3 |
Fair |
Slightly annoying |
2 |
Poor |
Annoying |
1 |
Bad |
Very Annoying |
Analyze your results
for problems
|
