Jump to: Speed / Quality · VoIP · Route · TCP Quality Metrics
Speed / Quality
Speed (Throughput)
Imagine water flowing through a pipe — throughput is how much water (data) actually makes it through over time. While often measured in units like Mbps, it's not just about one factor. Throughput depends on real-world conditions such as network congestion, data loss, and the way TCP manages the flow of information. In more technical terms, it's influenced by bandwidth, latency, packet loss, and the size of TCP buffers.
Effective (Line) Speed
Think of effective speed like the pace you settle into once you've been running for a while. It's the stable, real-world data transfer rate you actually experience after the connection has "warmed up." Instead of just looking at a single snapshot, effective speed considers multiple chunks of data (TCP windows), how the connection ramps up, and how the network adjusts for delays, acknowledgments, or lost packets. From a technical perspective, it reflects long-term, steady-state throughput rather than a theoretical maximum.
Bandwidth & Percentile
In MCS, the bandwidth metric is tied to a chosen percentile, creating a clear picture of the true end-to-end user experience. When configuring the test, you can specify an expected bandwidth (1 Mbps to 10 Gbps), and the system will report the percentile of packets that achieve at least that rate. Alternatively, you can enter a percentile (1–100%), and MCS will report the bandwidth attained by that portion of the data. Together, these parameters define the effective bandwidth in the context of latency, providing a more meaningful view of your connection's real-world performance.
SLA Bandwidth
SLA stands for Service Level Agreement and refers to the ISP service offered — for example, 300 Mbps down and 50 Mbps up. SLA bandwidth reports a high and low number, which reflects the average bandwidth attained on the high end and on the low end of the test.
Max Route Speed
The maximum TCP application throughput speed attainable between the client and the server because of the route used. The efficiency and length of the route ultimately dictates the round-trip time for data to travel end-to-end and back. Because TCP needs to know that any packets sent have arrived, the trip time is material to the data throughput speed. See Round Trip Time.
Max Delay
A measure of the maximum delay the client was waiting for data to arrive. Max delay should normally not exceed the TCP forced idle time created by the natural latency of the connection. If this is not the case, it indicates problems with the Data Flow QoS of the connection causing excessive delays, likely caused by packet loss or packet regulation.
Data Flow QoS
A measure of how smoothly data packets are moving. If a connection is congestion-free or unregulated, every packet should flow at a rate that matches the maximum capacity of the slowest part of the connection's route. If regulation or congestion causes this pattern to change, the Data Flow QoS will drop. Note: if problems affect packets but the impact is evenly spread (e.g., all or nearly all packets are affected), the QoS may still appear high. See Max Delay.
Capacity QoS
A similar measure to Data Flow QoS but represents data flow for the capacity test. Because the capacity test is designed to fill the connection to the maximum capacity of the slowest part of the route, it is natural that data flow problems will occur at the point capacity is reached. Packets may drop or regulation events may occur to slow the data flow down (i.e., govern the capacity limit).
Round Trip Time (RTT)
The time it takes for a packet to be sent end-to-end between the client and the server and back. The length and consistency of the trip time ultimately defines the TCP throughput speed (see Max Route Speed). A long trip time will dramatically slow connection throughput speed. An erratic trip time is an early indication of regulation or congestion problems.
VoIP
Jitter
A measure of the difference in time that each packet takes to reach the destination. In an ideal world, each packet would take exactly the same time to travel between the client and the server (0% jitter), but in reality packets vary in latency, which on a bad connection can be very large. Jitter is an expression of this variance.
Packet Loss
A measure of how many packets did not reach the destination, expressed as a percentage of the total number of packets. Any packet loss affects the quality of applications.
Packet Loss Distribution
A measure of how packet loss is distributed across the timeline. If a test of 1,000 packets lost 1% (10 packets) evenly — one packet in every 100 — the distribution would be 1%. However, if all 10 packets were lost in a single window of 100 packets, the loss remains 1% but the distribution would be 10%. A high distribution percentage means the lost packets are concentrated in a small time window, causing a bigger quality problem for the application.
Packet Order
A percentage measure of how many packets arrived in order. Packets do not necessarily take the same route or the same time to reach the destination, resulting in out-of-order arrivals that cause delays or, in very bad cases, discards. Delayed or discarded packets cause quality problems for the application.
Packet Discards
A measure of packets that arrive too late to be used by the application. Packets are very time-dependent for media-based applications. There is a time window during which packets can be used — after that, the packet must be intentionally discarded when it arrives. Think of it like missing a connecting flight because the first flight was delayed and arrived after the second flight had taken off.
MOS (Mean Opinion Score)
A measure from 1 (worst) to 5 (best). MOS originated from telephone companies using human input from related quality tests. Software applications have adopted the MOS score and scale:
| Score | Rating | Description |
|---|---|---|
| 5 | Excellent | Clear as if in a real face-to-face conversation |
| 4 | Fair | Small interference but sound still clear (typical cell phone quality) |
| 3 | Not fair | Enough interference to start to annoy |
| 2 | Poor | Very annoying and almost unusable |
| 1 | Bad | Not fit for purpose |
Route
IP Address
Internet Protocol Address — defines a particular device connected to the Internet. An IP address is like a telephone number: without the address of a destination, you can't reach it. An IP address is comprised of four separate numbers (called octets) ranging from 0 to 255, for example 192.168.0.100. To make the Internet more user-friendly, IP addresses can be replaced with unique domain names. See DNS Name.
DNS Name
Domain Name Service. Since people cannot usually remember IP address numbers, DNS allows an IP address to be attached to a name. For example, www.microsoft.com is a domain name. When a user enters a domain name, the browser performs a directory lookup to find the IP address of the destination. A major advantage of DNS names over IP addresses is that companies can change their IP addresses without impacting customers — only the DNS directory needs updating.
DNS Time
A measure of how long it takes to look up a DNS name and retrieve the allocated IP address. DNS problems can cause significant performance issues, including making a business application totally unusable.
Hop
An Internet route is similar in concept to a road route. In order to navigate between a source and destination, the journey passes through a series of points where direction changes are required. At each point on the Internet where there are choices of direction, a router device (termed a "hop") sends data in the right direction for the next hop. Just like road traffic, if a router hop is on a popular route, it can become congested causing delays or lost packets. When two different companies send traffic to each other, the hops where their routes join are called Peering Points — these are the most likely hops where problems can occur.
Latency
A measure of the time taken for a route testing packet to reach a particular hop and return. By measuring each hop along the route to the destination, it is possible to see where high latency is causing degradation in throughput speed or dropping packets. Latency should only be higher if there is distance involved. For example, a route from London to New York crossing 3,000 miles of Atlantic Ocean will obviously have higher latency for that hop. When you see high latency, validating the geography is an important step to making sense of potential routing issues.
Access Series TCP Quality Metrics
TCP Receive Statistics
Packets out of order
Reports the number of packets that have arrived out of order. This occurs when packets are delayed or lost. Out-of-order packets slow throughput because TCP cannot process data out of order. Review packets/bytes lost as well as packets/bytes re-transmitted — if these values are non-zero, the connection has quality problems that can cause significant performance issues.
Bytes out of order
Reports the number of bytes that have arrived out of order. The same causes and implications apply as with packets out of order.
Packets after receive window
Reports the number of packets that arrive outside the current TCP valid data window and are therefore discarded. TCP maintains a sliding window to manage data flow. Packets arriving outside the current window indicate a serious problem with duplicate packets. This should never happen.
Bytes after receive window
Reports the number of bytes that arrive outside the current TCP valid data window and are therefore discarded. The same causes and implications apply as with packets after receive window.
Bytes Lost
Reports the number of bytes that were sent but failed to arrive. Lost bytes indicate a very serious congestion problem or regulatory policy problem. A stable connection should not drop bytes. The throughput penalty can be severe even if just one packet drops. If acknowledgement packets are dropped, the lost bytes can cause re-transmit timeouts.
Duplicate Packets
Reports the number of packets received at the destination more than once. Duplicates are usually caused by very erratic latency end-to-end. TCP can trigger a timeout and resend a packet that has not been lost but only delayed, causing duplicates.
Bytes received in duplicate packets
Reports the number of bytes received more than once. Same causes as duplicate packets.
Partially duplicate packets
Reports the number of packets received more than once that contain one or more duplicate bytes. Same causes as duplicate packets.
Bytes received in partially duplicate packets
Reports the number of bytes received in partially duplicate packets. Same causes as duplicate packets.
Packets with bad data offset
The data offset index points to the start of the packet's data block. If this is invalid (corrupt), the packet is dropped.
Packets with bad checksum
The checksum is a validation process undertaken by the receiving TCP to ensure data integrity matches the sending TCP's calculation. If the checksum fails, the packet is dropped.
Packets too short
If an arriving packet is smaller than the minimum allowed size, it is assumed to be corrupt and dropped.
Window probes received
Window probes are initiated by the TCP stack to validate if there is memory for storing data waiting to be sent. This indicates memory problems in the receiving computer, usually caused by a busy processor slowing the receiving application from getting data.
Zero window updates sent
Zero window updates indicate that one end of the connection has stopped data flow for lack of memory space. This is a very bad event.
TCP Send Statistics
Maximum Transmission Unit (MTU)
Reports the maximum byte size negotiated between client and server. If the MTU is too small, throughput will suffer. If too large, fragmentation will occur, also causing severe throughput problems. The MTU should be around 1,460–1,500 bytes.
Packets re-transmitted
Reports the number of packets that have been re-transmitted due to delay or loss. Check whether you are getting fast re-transmit events or re-transmit timeout events. Both are bad quality events, but timeouts can cause extreme problems.
Bytes re-transmitted
Reports the number of bytes re-transmitted. Same causes and implications as packets re-transmitted.
Re-transmit timer timeouts
A timeout occurs when the maximum time allocated to a sent packet expires because it has not been acknowledged. Timeouts are very costly to performance and should never occur on a well-run network.
Fast re-transmits
A fast re-transmit occurs when the sending end receives three duplicate acknowledgements for a packet. The sender re-sends the packet to avoid a costly timeout event. Fast re-transmits can cause duplicates if the original packet was only delayed, not lost.
Duplicate acks received
TCP operates a positive acknowledgement system — when data is missing or out of order, TCP acknowledges the expected packet, not the received packets. This causes duplicate acknowledgements when data is lost or out of order. See fast re-transmits and re-transmit timeouts.
Persist timer timeouts
Occurs due to inactivity on the connection.
Acks received for unsent data
Implies that data for another data stream (an old stream) is arriving on the connection. This should never happen and indicates a severe problem.
Pure window update packets
When available buffer memory allocated for packets changes, the receiver must notify the sender. Usually this is done in a normal acknowledgement, but there can be circumstances (e.g., memory reclaimed by the OS) when there is no acknowledgement due.
Window probes sent
If the receive end causes the window to close, suspending all data flow, the sending end sends probes to discover if the window has been reopened. This prevents the connection from being suspended indefinitely if the window-open message is lost.
Send window closed events
Indicates one end of the connection has stopped data flow for lack of memory space. This is a very bad event.
Ethernet (Local Network Interface) Statistics
| Metric | Description |
|---|---|
| Receive overruns | Packets arriving faster than the interface can process |
| Bad checksum frames | Frames received with a failed checksum validation |
| XL Frames | Frames received which were too large |
| NA Frames | Frames received which were not octet-aligned |
| Short Frames | Frames received which were too short |
| Cut Frames | Frames received which were truncated |
Network Statistics (24-Hour Accumulation)
Network down time (s)
The Access Series continually tests connectivity to the MCS server and reports network unavailable time as downtime in seconds every hour as well as with every test result. Totals are cleared every 24 hours.
Network up time (s)
Reports network available time as uptime in seconds every hour and with every test result. Totals are cleared every 24 hours.
Percentage network downtime
Expresses the downtime as a percentage of the total available time in the current 24-hour window. Useful for setting alert triggers when downtime changes.
HTTP 3xx / 4xx / 5xx / Unknown errors
Reports the seconds of connection unavailability due to HTTP error responses when making requests to MyConnection Server.
Current firmware version
Reports the current firmware version of the Access Series internal software. MCS can be set to automatically upgrade firmware when a new version is released.
Milliseconds since last restart
Internal timer reporting uptime since the last device restart.
Free packet queue
Internal memory health monitor. This diagnostic value should never reach zero.

