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