Time Metrics
Time metrics are related to latency, that is, the passing of time between the sending of a packet and its reception.
Packet Delay
Depending on which type of session is producing the result record (RR), a delay metric can hold one-way or round-trip data. E.g. if the session type is 1xOneWay, the metric holds one-way delay data and if the session type is eth-lb, the metric holds round-trip delay data. The max value is 16.77 seconds expressed as microseconds.
Name | Unit | Description |
---|---|---|
dmin | µs | Minimum delay during the RR interval |
dp25 | µs | Percentile 25 delay during the RR interval |
dp50 | µs | Percentile 50 (median) delay during the RR interval |
dp75 | µs | Percentile 75 delay during the RR interval |
dp95 | µs | Percentile 95 delay during the RR interval |
dplo (dp96) | µs | User-configured (default p96) delay during the RR interval |
dpmi (dp98) | µs | User-configured (default p98) delay during the RR interval |
dphi (dp99) | µs | User-configured (default p99) delay during the RR interval |
dmax | µs | Highest delay during the RR interval |
davg | µs | Average delay during the RR interval |
dStdDev | µs | Standard deviation of the delays during the RR interval |
rttMin | µs | Minimum round-trip packet train delay during the RR interval |
rttMax | µs | Maximum round-trip packet train delay during the RR interval |
rttAvg | µs | Average round-trip packet train delay during the RR interval |
Inter Packet Delay Variation (IPDV)
The IPDV metrics are of type Inter Packet Delay Variation (IPDV). IPDV is defined as the absolute value of the difference in delay between two consecutive received packets.
Depending on which type of session is producing the result record (RR), a delay variation metric can hold one-way or round-trip data. E.g. if the session type is 1xOneWay, the metric holds one-way delay variation data and if the session type is eth-lb, the metric holds roundtrip delay variation data. The max value is 16.77 seconds expressed as microseconds.
Name | Unit | Description |
---|---|---|
jmin | µs | Minimum delay variation during the RR interval |
jp25 | µs | Percentile 25 delay variation during the RR interval |
jp50 | µs | Percentile 50 (median) delay variation during the RR interval |
jp75 | µs | Percentile 75 delay variation during the RR interval |
jp95 | µs | Percentile 95 delay variation during the RR interval |
jplo (jp96) | µs | User-configured (default p96) delay variation during the RR interval |
jpmi (jp98) | µs | User-configured (default p98) delay variation during the RR interval |
jphi (jp99) | µs | User-configured (default p99) delay variation during the RR interval |
jmax | µs | Highest delay variation during the RR interval |
javg | µs | Average delay variation during the RR interval |
jStdDev | µs | Standard deviation of the delay variations during the RR interval |
Packet Delay Variation (PDV)
The Packet Delay Variation (PDV) metrics compare a delay percentile with the minimum delay value. Thus, it gives a view of the span between minimum delay value and the percentile. This is sometimes referred to as Real Jitter.
Depending of which type of session is producing the result record (RR), a delay variation metric can hold one-way or round-trip data. E.g. if the session type is 1xOneWay, the metric holds one-way delay variation data and if the session type is eth-lb, the metric holds round-trip delay variation data. The max value is 16.77 seconds expressed as microseconds.
Name | Unit | Description |
---|---|---|
dvp25 | µs | Percentile 25 delay difference from minimum delay |
dvp50 | µs | Percentile 50 (median) delay difference from minimum delay |
dvp75 | µs | Percentile 75 delay difference from minimum delay |
dvp95 | µs | Percentile 95 delay difference from minimum delay |
dvpmi (dvp96) | µs | User-configured (default percentile 96) delay difference from minimum delay |
dvphi (dvp98) | µs | User-configured (default percentile 98) delay difference from minimum delay |
dvphi (dvp99) | µs | User-configured (default percentile 99) delay difference from minimum delay |
dvmax | µs | Maximum delay difference from minimum delay |
dvavg | µs | Average delay difference from minimum delay |
Count Metrics
Count metrics hold information about number packets received and metrics derived from packet sequence numbering such as lost, reorder and duplicate.
Number of Packets and Bytes
Name | Unit | Description |
---|---|---|
rxpkts | int | Number of packets that was received (including duplicate packets) during the RR interval |
rxbytes | int | Number of bytes that was received (including duplicate packets) during the RR interval |
Packet Loss
The packet loss metrics counts the number of lost packets, number of periods of lost packets and the minimum and maximum length (lost burst) of the lost periods during a result record (RR) interval.
Lost packets are counted for the following reasons:
- A packet does not arrive in RR interval N.
- A packet arrives with a larger sequence number than expected and the sequence discontinuity is not caused by reordering.
- A packet, expected to arrive in RR interval N, arrives late and reordered in RR interval N+1. Such packet is counted as lost in RR N and as tooLate and reordered in RR N+1.
- A packet expected to arrive in RR interval N, arrives late in order in RR interval N+1. Such packet is counted as lost in RR N and as tooLate in RR N+1.
- A packet arrives but is corrupted.
Examples, consider a stream of 10 packets sent as (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) during an RR interval and arriving as:
- (1, 2, 3, 4, 5, 6, 7, 8, 9, 10): No packets are lost. All packet loss metrics are 0.
- (1, 3, 4, 5, 6, 10): Packet 2,7,8,9 are lost. Number of lost packets is 4. Number of lost periods is 2. The minimum and maximum lengths of the periods are 1 and 3 respectively.
Name | Unit | Description |
---|---|---|
lostpkts | int | Number of lost packets during the RR interval |
lostperc | % | Number of lost packets during the RR interval in percent. lostperc = (lostpkts / (rxpkts + lostpkts - duplicatepkts)) * 100.0 |
lostperiods | int | Number of lost periods during the RR interval |
lostburstmin | int | Shortest loss period length during the RR interval |
lostburstmax | int | Longest loss period length during the RR interval |
Packet Reorder
The packet reorder metric counts the number of packets received with a sequence number not earlier received and smaller than expected during a result record (RR) interval.
If a packet arrives with a larger sequence number than expected, this indicates sequence discontinuity caused by either packet loss or reordering.
Name | Unit | Description |
---|---|---|
misorderpkts | int | Number of packets that was received reordered (excluding duplicates) during the RR interval |
misorderperc | % | Number of packets that was received reordered (excluding duplicates) during the RR interval in percent. misorderperc = (misorderpkts / (rxpkts - duplicatepkts)) * 100.0 |
Examples, consider a stream of 4 packets, sent as (1, 2, 3, 4) and arriving as:
- (1, 2, 3, 4): No packets are reordered in the stream.
- (1, 2, 4, 3): The packet with sequence number 3 is reordered.
- (1, 2, 4, 3, 3): The first packet with sequence number 3 is reordered and the second one is duplicated.
Packet Duplication
The packet duplication metric counts the number of additional identical and uncorrupted copies received. Packets are considered identical if they belong to the same session (contain identical information fields) and have the same sequence number. For IP packets, e.g. L field may vary if a duplicated packet has been routed differently. A duplicated packet is both counted as received and duplicated.
Name | Unit | Description |
---|---|---|
duplicatepkts | int | Number of packets that was received duplicated during the RR interval |
duplicateperc | % | Number of packets that was received duplicated during the RR interval in percent. duplicateperc = (duplicatepkts / (rxpkts - duplicatepkts)) * 100.0 |
Examples, consider a stream of 4 packets, sent as (1, 2, 3, 4) and arriving as:
(1, 2, 3, 4): No packets are duplicated.
(1, 1, 2, 2, 3, 3, 4, 4): Every packet is duplicated once.
(1, 2, 3, 4, 3): The packet with sequence number 3 is duplicated.
Packet tooLate
A packet tooLate is a packet received in result record (RR) interval N+1 but is already incorrectly counted as lost in previous RR interval N.
Name | Unit | Description |
---|---|---|
toolatepkts | int | Number of packets received late, already counted as lost in the previous RR interval |
As examples, consider a stream of 10 packets sent as (1,2,3,4,5,6,7,8,9,10) and arriving in RR interval N as (1,2,3,4,6) and in interval N+1 as (7,5,8,9,10). The packet with sequence number 5 is received reordered in interval N+1. Since the packet is already counted as lost in interval N, the tooLate (and the reorder) counter is increased in interval N+1. Here, the tooLate counter indicates the false count of lost packet in previous interval N.
Packet Field Metrics
Packet field metrics are derived from IP or Ethernet packet header fields.
Name | Unit | Description |
---|---|---|
tosmin | int | Minimum received TOS value during the RR interval. Max value 255 |
tosmax | int | Maximum received TOS value during the RR interval. Max value 255 |
ttlmin | int | Minimum received TTL value during the RR interval. Max value 255 |
ttlmax | int | Maximum received TTL value during the RR interval. Max value 255 |
vpriomin | int | Minimum received VLAN priority during the RR interval. Max value 7 |
vpriomax | int | Maximum received VLAN priority during the RR interval. Max value 7 |
melmin | int | Minimum received MEG (Maintenance Entity Group) level during the RR interval. Max value 7 |
melmax | int | Maximum received MEG (Maintenance Entity Group) level during the RR interval. Max value 7 |
Quality Metrics
A quality metric is a higher-level metric derived from one or many metrics to form a customer experience
measure.
Name | Unit | Description |
---|---|---|
R-value | float | Rating value (or factor) is a measure of voice call quality and is derived from metrics such as codec type, latency, jitter and packet loss. The R-value is expressed as a decimal value in the range from 1.0 to 100.0, where 100.0 is the highest rated quality. |
MOS | float | Mean Opinion Score is a measure of voice call quality. MOS is expressed as a decimal value in the range from 1.0 to 5.0, where 5.0 is the highest rated quality. MOS is derived from the R-value. |
Meta Metrics
The meta metrics holds information about the result record (RR) such as identification, status, timing, error codes and numbering information.
Name | Unit | Description |
---|---|---|
peerid | int | Unique (global scope) 32 bit session endpoint identifier |
direction | int | Indicates which link the result concerns. Direction uplink (Assurance Sensor Control->Reflector) = 0 and downlink (Reflector->Assurance Sensor Control) = 1 |
statStatus | int | Statistic result status (two 16bit field) +-+-+-+-+-+-+-+-+-+-+-+-+ | statLevel | errorCode | | lo 16 bit | hi 16 bit | +-+-+-+-+-+-+-+-+-+-+-+-+ statlevel: valid statistic levels in result. If statLevel = LOSS|JITTER|DELAY, the result record contain information about loss, jitter and delay. LOSS = 0x0100 (256) EST_LOSS = 0x04000 (16384) JITTER = 0x0200 (512) DELAY = 0x0400 (1024) TUNNEL_LOSS = 0x00040 (64) LOSS|JITTER|DELAY = 0x0700 (1792) EST_LOSS: Estimation is done when we have not received any packet to calculate possible gap in sequence number at the time to process the ResultRecord. TUNNEL_LOSS: Contain possible packet loss in NFV tunnel (false loss) errorCode: if code = 0 the result record is OK. If code > 0 see Error Codes (33xx) for description (Administrative Operations). |
syncStatus | int | Synchronization state and quality factor. Concerns all sessions where one-way delay metrics are measured. The syncStatus metric is divided into two parts, state (low 16 bits) and quality (high 16 bits). The sync quality factor is measured in percent (0-100%). It is not an exact value but instead a guidance on how well synchronization can be performed over the network. The state holds the current state of used synchronization session. States: CONNECT (13) test connectivity to destination COLD (16) synchronization started (not yet ready to use) WARM (17) synchronization data ready to use FATAL (23) fatal error occurred |
statTime | ms | End time of one RR interval and the time when the collected data were condensed into RR metrics. UTC time milliseconds since epoch 1/1/1970 |
intervalms | ms | The RR data collecting interval. This is the time between creating two consecutive RRs. Max value 600 seconds |
statRound | seqnum | RR numbering per session. Starting from one (1) and increasing in step of one for every newly created RR |
firstpktOffset | Receive time of the first received packet during the RR interval as offset in milliseconds before statTime. Max value 600 seconds | |
firstpktSeq | Sequence number of the first received packet during the RR interval | |
lastpktOffset | Receive time of the last received packet during the RR interval as offset in milliseconds before statTime. Max value 600 seconds | |
lastpktSeq | Sequence number of the last received packet during the RR interval |
© 2025 Cisco and/or its affiliates. All rights reserved.
For more information about trademarks, please visit: Cisco trademarks
For more information about legal terms, please visit: Cisco legal terms
For legal information about Accedian Skylight products, please visit: Accedian legal terms and tradmarks