Glossary

Definitions of terms used in MCS test results and reports.

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:

ScoreRatingDescription
5ExcellentClear as if in a real face-to-face conversation
4FairSmall interference but sound still clear (typical cell phone quality)
3Not fairEnough interference to start to annoy
2PoorVery annoying and almost unusable
1BadNot 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
MetricDescription
Receive overrunsPackets arriving faster than the interface can process
Bad checksum framesFrames received with a failed checksum validation
XL FramesFrames received which were too large
NA FramesFrames received which were not octet-aligned
Short FramesFrames received which were too short
Cut FramesFrames 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.