Performance Monitoring
Note The terms "Unidirectional Path Switched Ring" and "UPSR" may appear in Cisco literature. These terms do not refer to using Cisco ONS 15xxx products in a unidirectional path switched ring configuration. Rather, these terms, as well as "Path Protected Mesh Network" and "PPMN," refer generally to Cisco's path protection feature, which may be used in any topological network configuration. Cisco does not recommend using its path protection feature in any particular topological network configuration.
This chapter defines PM parameters and concepts for Cisco ONS 15600 SDH optical cards. You can use performance monitoring (PM) parameters to gather, store, threshold, and report performance data for early detection of problems.
Note For additional information regarding PM parameters, refer to ITU-T G.826, G.827, G.828, G.829, M2101, and M2102, or Telcordia documents GR-1230-CORE, GR-820-CORE, GR-499-CORE, and GR-253-CORE and the ANSI T1.231 document entitled Digital Hierarchy - Layer 1 In-Service Digital Transmission Performance Monitoring.
For information about enabling and viewing PM values, refer to the Cisco ONS 15600 SDH Procedure Guide.
Chapter topics include:
•Threshold Performance Monitoring
•Intermediate-Path Performance Monitoring
•Pointer Justification Count
•Performance-Monitoring Parameter Definitions
•Optical Card Performance Monitoring
•ASAP Card Performance Monitoring
12.1 Threshold Performance Monitoring
Thresholds are used to set error levels for each PM. You can program PM threshold ranges from the Provisioning > SDH Thresholds tabs on the Cisco Transport Controller (CTC) card view. To provision card thresholds, such as line, path, and SDH thresholds, refer to the Cisco ONS 15600 SDH Procedure Guide.
During the accumulation cycle, if the current value of a performance monitoring parameter reaches or exceeds its corresponding threshold value, a threshold crossing alert (TCA) is generated by the node and sent to CTC. TCAs provide early detection of performance degradation. When a threshold is crossed, the node continues to count the errors during a given accumulation period. If 0 is entered as the threshold value, the performance monitoring parameter is disabled.
Change the threshold if the default value does not satisfy your error monitoring needs. For example, customers with a critical VC3 installed for on-demand emergency calls must guarantee the best quality of service on the line; therefore, they lower all thresholds so that the slightest error raises a TCA.
12.2 Intermediate-Path Performance Monitoring
Intermediate-path performance monitoring (IPPM) allows a nonterminating node to transparently monitor a constituent channel of an incoming transmission signal. ONS 15600 SDH networks only use line terminating equipment (LTE), not path terminating equipment (PTE). The following cards are LTE equipment in the ONS 15600 SDH system:
•OC48/STM16 SR/SH 16 Port 1310
•OC48/STM16 LR/LH 16 Port 1550
•OC192/STM64 SR/SH 4 Port 1310
•OC192/STM64 LR/LH 4 Port 1550
•OC192LR/STM64 4 Port ITU C-Band
IPPM enables LTE cards to monitor near-end path PM data on individual virtual containers (VC) payloads. After enabling IPPM on provisioned VC3 or VC4 ports, service providers can monitor large amounts of VC traffic through intermediate nodes, thus making troubleshooting and maintenance activities more efficient.
IPPM occurs only on VC4 paths that have IPPM enabled, and TCAs are raised only for PM parameters on the selected IPPM paths. The monitored IPPMs are VC4 HP-EB, VC4 HP-ES, VC4 HP-SES, VC4 HP-UAS, and VC4 HP-BBE. The following ratio parameters are provided: VC4 HP-BBER, VC4 HP-ESR, and VC4 HP-SESR. To enable IPPM, refer to the Cisco ONS 15600 SDH Procedure Guide.
The ONS 15600 SDH performs IPPM by examining the overhead in the monitored path and reading all of the near-end path performance monitoring parameters in the incoming transmission direction. The IPPM process allows the path overhead to pass bidirectionally through the node completely unaltered.
For detailed information about specific performance monitoring parameters, see the "Performance-Monitoring Parameter Definitions" section.
12.3 Pointer Justification Count
Pointers are used to compensate for frequency and phase variations. Pointer justification counts indicate timing differences on SDH networks. When a network is not synchronized, frequency and phase variations occur on the transported signal. Excessive frequency and phase variations can cause terminating equipment to slip. These variations also cause slips at the SDH and plesiosynchronous digital hierarchy (PDH) boundaries.
Slips cause different effects in service. Voice service has intermittent audible clicks. Compressed voice technology has short transmission errors or dropped calls. Fax machines lose scanned lines or experience dropped calls. Digital video transmission has distorted pictures or frozen frames. Encryption service loses the encryption key, which causes data to be transmitted again.
Pointers align the phase variations in VC4 and TU payloads. The VC4 payload pointer is located in the H1 and H2 bytes of the line overhead. Clocking differences are measured by the offset in bytes from the pointer to the first byte of the VC4 virtual container (VC) called the J1 byte. A small number of pointer justification counts per day is not cause for concern. If the pointer justification count continues to rise or becomes large, action must be taken to correct the problem.
You can enable positive pointer justification count (PPJC) and negative pointer justification count (NPJC) performance monitoring parameters for LTE cards.
PPJC is a count of path-detected (PPJC-Pdet) or path-generated (PPJC-Pgen) positive pointer justifications depending on the specific PM name. NPJC is a count of path-detected (NPJC-Pdet) or path-generated (NPJC-Pgen) negative pointer justifications depending on the specific PM name.
A consistent pointer justification count indicates clock synchronization problems between nodes. A difference between the counts means the node transmitting the original pointer justification has timing variations with the node detecting and transmitting this count. Positive pointer adjustments occur when the frame rate of the VC is too slow in relation to the rate of the VC4.
For pointer justification count definitions, see the "Performance-Monitoring Parameter Definitions" section. In CTC, the PM count fields for PPJC and NPJC appear white and blank unless IPPM is enabled.
12.4 Performance-Monitoring Parameter Definitions
Table 12-1 gives definitions for each type of performance-monitoring parameter found in this chapter.
Table 12-1 Performance Monitoring Parameters
|
|
MS-EB |
Multiplex Section Errored Block (MS-EB) indicates that one or more bits are in error within a block. |
MS-ES |
Multiplex Section Errored Second (MS-ES) is a one-second period with one or more errored blocks or at least one defect. |
MS-SES |
Multiplex Section Severely Errored Second (MS-SES) is a one-second period which contains 30 percent or more errored blocks or at least one defect. SES is a subset of ES. For more information, see ITU-T G.829 Section 5.1.3. |
MS-BBE |
Multiplex Section Background Block Error (MS-BBE) is an errored block not occurring as part of an SES. |
MS-UAS |
Multiplex Section Unavailable Seconds (MS-UAS) is a count of the seconds when the section was unavailable. A section becomes unavailable when ten consecutive seconds occur that qualify as MS-SESs, and it continues to be unavailable until ten consecutive seconds occur that do not qualify as MS-SESs. When the condition is entered, MS-SESs decrement and then count toward MS-UAS. |
MS-FC |
Count of the number of occurrences of near-end failure events, and is incremented by one each time a near-end failure event begins. Failure counts are incremented during unavailable time. |
MS-ESR |
Multiplex Section Errored Second Ratio (MS-ESR) is the ratio of errored seconds to total seconds in available time during a fixed measurement interval. |
MS-SESR |
Multiplex Section Severely Errored Second ratio (MS-SESR) is the ratio of SES to total seconds in available time during a fixed measurement interval. |
MS-BBER |
Multiplex Section Background Block Error Ratio (MS-BBER) is the ratio of BBE to total blocks in available time during a fixed measurement interval. The count of total blocks excludes all blocks during SESs. |
MS-PSC-W |
For a working line in a 2-fiber MS-SPRing, Multiplex Section Protection Switching Count-Working (MS-PSC-W) is a count of the number of times traffic switches away from the working capacity in the failed line and back to the working capacity after the failure is cleared. MS-PSC-W increments on the failed working line and MS-PSC increments on the active protect line. For a working line in a 4-fiber MS-SPRing, MS-PSC-W is a count of the number of times service switches from a working line to a protection line plus the number of times it switches back to the working line. MS-PSC-W increments on the failed line and MS-PSC-R or MS-PSC-S increments on the active protect line. |
MS-PSD-W |
For a working line in a two-fiber MS-SPRing, Multiplex Section Protection Switching Duration-Working (MS-PSD-W) is a count of the number of seconds that service was carried on the protection line. MS-PSD-W increments on the failed working line and MS-PSD increments on the active protect line. |
HP-EB |
High-Order Path Errored Block (HP-EB) indicates that one or more bits are in error within a block. |
HP-ES |
High-Order Path Errored Second (HP-ES) is a one-second period with one or more errored blocks or at least one defect. |
HP-SES |
High-Order Path Severely Errored Seconds (HP-SES) is a one-second period containing 30 percent or more errored blocks or at least one defect. SES is a subset of ES. |
HP-BBE |
High-Order Path Background Block Error (HP-BBE) is an errored block not occurring as part of an SES. |
HP-UAS |
High-Order Path Unavailable Seconds (HP-UAS) is a count of the seconds when the VC path was unavailable. A high-order path becomes unavailable when ten consecutive seconds occur that qualify as HP-SESs, and it continues to be unavailable until ten consecutive seconds occur that do not qualify as HP-SESs. |
HP-FC |
Count of the number of occurrences of near-end failure events, and is incremented by one each time a near-end failure event begins. Failure counts are incremented during unavailable time. |
RS-EB |
Regenerator Section Errored Block (RS-EB) indicates that one or more bits are in error within a block. |
RS-ES |
Regenerator Section Errored Second (RS-ES) is a one-second period with one or more errored blocks or at least one defect. |
RS-SES |
Regenerator Section Severely Errored Second (RS-SES) is a one-second period which contains 30 percent or more errored blocks or at least one defect. SES is a subset of ES. |
RS-BBE |
Regenerator Section Background Block Error (RS-BBE) is an errored block not occurring as part of an SES. |
RS-ESR |
Regenerator Section Errored Second Ratio (RS-ESR) is the ratio of errored seconds to total seconds in available time during a fixed measurement interval. |
RS-SESR |
Regenerator Section Severely Errored Second Ratio (RS-SES) is the ratio of SES to total seconds in available time during a fixed measurement interval. |
RS-BBER |
Regenerator Section Background Block Error Ratio (RS-BBE) is the ratio of BBE to total blocks in available time during a fixed measurement interval. The count of total blocks excludes all blocks during SESs. |
RS-UAS |
Regenerator Section Unavailable Second (RS-UAS) is a count of the seconds when the regenerator section was unavailable. A section becomes unavailable when ten consecutive seconds occur that qualify as RS-UASs, and it continues to be unavailable until ten consecutive seconds occur that do not qualify as RS-UASs. |
12.5 Optical Card Performance Monitoring
The following sections define performance monitoring parameters for the OC-48/STM16, and OC-192/STM64 optical cards.
12.5.1 OC-48/STM16, and OC-192/STM64 Card Performance Monitoring Parameters
Figure 12-1 shows where overhead bytes detected on the Application-Specific Integrated Circuits (ASICs) produce performance monitoring parameters for the OC-48/STM16, and OC-192/STM64 optical cards.
Figure 12-1 PM Read Points on the OC-48/STM16, and OC-192/STM64 Cards
Note For PM locations relating to protection switch counts, see the Telcordia GR-1230-CORE document.
Table 12-2 lists the near-end and far-end section layer PMs.
Table 12-2 OC48/STM16, and OC-192/STM64 Card PMs
|
|
|
|
VC4 and VC4-Xc HP Path (NE
)
|
RS-EB RS-ES RS-SES RS-OFS RS-BBE |
MS-EB MS-ES MS-SES MS-UAS MS-FC MS-BBE |
MS-PSC MS-PSD MS-PSC-W MS-PSD-W |
HP-PPJC-Pdet HP-NPJC-Pdet HP-PPJC-Pgen HP-NPJC-Pgen HP-PJCDiff HP-PJCS-Pdet HP-PJCS-Pgen |
HP-BBE HP-BBER HP-EB HP-ES HP-ESR HP-SES HP-SESR HP-UAS |
12.5.2 Physical Layer Parameters
The ONS 15600 SDH retrieves the OPR, OPT, and LBC from the line card and stores these values with the PM counts for the 15-minute and 1-day periods. You can retrieve current OPR, OPT, and LBC values for each port by displaying the card view in CTC and clicking the Maintenance > Transceiver tabs.
The physical layer performance parameters consist of normalized and non-normalized values of LBC, OPT, and OPR. Table 12-3 defines the non-normalized values.
Table 12-3 Non-Normalized Transceiver Physical Optics for the OC-48/STM16, and OC-192/STM64 Cards
|
|
Non-normalized LBC (mA)1 |
The actual operating value of laser bias current (mA) for the specified card port. |
Non-normalized OPR (dbm)2 |
The actual operating value of optical power received (dBm) for the specified card port. |
Non-normalized OPT (dbm)1 |
The actual operating value of optical power transmitted (dBm) for the specified card port. |
12.6 ASAP Card Performance Monitoring
The following sections define performance monitoring parameters for the Any Service Any Port (ASAP) card.
12.6.1 ASAP Card Optical Performance Monitoring Parameters
Table 12-4 lists the near-end and far-end section layer PMs.
Table 12-4 ASAP Card PMs
|
|
|
|
VC4 and VC4-Xc HP Path (NE)
3
|
RS-EB RS-ES RS-SES RS-OFS RS-BBE |
MS-EB MS-ES MS-SES MS-OFS MS-BBE |
MS-PSC MS-PSD MS-PSC-W MS-PSD-W |
HP-PPJC-Pdet HP-NPJC-Pdet HP-PPJC-Pgen HP-NPJC-Pgen HP-PJCDiff HP-PJCS-Pdet HP-PJCS-Pgen |
HP-BBE HP-BBER HP-EB HP-ES HP-ESR HP-SES HP-SESR HP-UAS |
12.6.2 ASAP Card Ethernet Performance Monitoring Parameters
CTC provides Ethernet performance information, including line-level parameters, port bandwidth consumption, and historical Ethernet statistics. The ASAP card Ethernet performance information is divided into Ether Ports and POS Ports windows within the card view Performance tab window.
12.6.2.1 ASAP Card Ether Port Statistics Window
The Ethernet Ether Ports statistics window lists Ethernet parameters at the line level. The Statistics window provides buttons to change the statistical values. The Baseline button resets the displayed statistics values to zero. The Refresh button manually refreshes statistics. Auto-Refresh sets a time interval at which automatic refresh occurs. The ASAP Statistics window also has a Clear button. The Clear button sets the values on the card to zero, but does not reset the ASAP card.
During each automatic cycle, whether auto-refreshed or manually refreshed (using the Refresh button), statistics are added cumulatively and are not immediately adjusted to equal total received packets until testing ends. To see the final PM count totals, allow a few moments for the PM window statistics to finish testing and update fully. PM counts are also listed in the ASAP card Performance > History window.
Table 12-5 defines the ASAP card statistics parameters.
Table 12-5 ASAP Ethernet Statistics Parameters
|
|
Time Last Cleared |
A time stamp indicating the last time statistics were reset. |
Link Status |
Indicates whether the Ethernet link is receiving a valid Ethernet signal (carrier) from the attached Ethernet device; up means present, and down means not present. |
ifInOctets |
Number of bytes received since the last counter reset. |
ifInUcastPkts |
Number of unicast packets received since the last counter reset. |
ifInMulticastPkts |
Number of multicast packets received since the last counter reset. |
ifInBroadcastPkts |
Number of broadcast packets received since the last counter reset. |
etherStatsOversizePkts |
The total number of packets received that were longer than 1518 octets (excluding framing bits, but including FCS octets) and were otherwise well formed. Note that for tagged interfaces, this number becomes 1522 bytes. |
dot3StatsFCSErrors |
A count of frames received on a particular interface that are an integral number of octets in length but do not pass the FCS check. |
etherStatsUndersizePkts |
The total number of packets received that were less than 64 octets long (excluding framing bits, but including FCS octets) and were otherwise well formed. |
etherStatsJabbers |
The total number of packets received that were longer than 1518 octets (excluding framing bits, but including FCS octets), and had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error). |
dot3StatsAlignmentErrors |
A count of frames received on a particular interface that are not an integral number of octets in length and do not pass the FCS check. |
ifOutOctets |
Number of bytes transmitted since the last counter reset. |
ifOutUcastPkts |
Number of unicast packets transmitted. |
ifOutMulticastPkts |
Number of multicast packets transmitted. |
ifOutBroadcastPkts |
Number of broadcast packets transmitted. |
etherStatsDropEvents |
Number of received frames dropped at the port level. |
rxPauseFrames |
Number of received Ethernet IEEE 802.3z pause frames. |
txPauseFrames |
Number of transmitted IEEE 802.3z pause frames. |
etherStatsOctets |
The total number of bytes of data (including those in bad packets) received on the network (excluding framing bits but including FCS bytes. |
etherStatsBroadcastPkts |
The total number of good packets received that were directed to the broadcast address. Note that this does not include multicast packets. |
etherStatsMulticastPkts |
The total number of good packets received that were directed to a multicast address. Note that this number does not include packets directed to the broadcast address. |
etherStatsFragments |
The total number of packets received that were less than 64 bytes in length (excluding framing bits but including FCS bytes) and had either a bad FCS with an integral number of bytes (FCS error) or a bad FCS with a nonintegral number of bytes (alignment error). Note It is entirely normal for etherStatsFragments to increment. This is because it counts both runts (which are normal occurrences due to collisions) and noise hits. |
etherStatsPkts64Octets |
The total number of packets (including bad packets) received that were 64 bytes in length (excluding framing bits but including FCS bytes). |
etherStatsPkts65to127Octets |
The total number of packets (including bad packets) received that were between 65 and 127 bytes in length inclusive (excluding framing bits but including FCS bytes). |
etherStatsPkts128to255Octets |
The total number of packets (including bad packets) received that were between 128 and 255 bytes in length inclusive (excluding framing bits but including FCS bytes). |
etherStatsPkts256to511Octets |
The total number of packets (including bad packets) received that were between 256 and 511 bytes in length inclusive (excluding framing bits but including FCS bytes). |
etherStatsPkts512to1023Octets |
The total number of packets (including bad packets) received that were between 512 and 1023 bytes in length inclusive (excluding framing bits but including FCS bytes). |
etherStatsPkts1024to1518Octets |
The total number of packets (including bad packets) received that were between 1024 and 1518 bytes in length inclusive (excluding framing bits but including FCS bytes). |
ifInDiscards |
The number of inbound packets which were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space. |
ifOutDiscards |
The number of outbound packets which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space. |
ifInErrors |
The number of inbound packets (or transmission units) that contained errors preventing them from being deliverable to a higher-layer protocol. |
dot3StatsFrameTooLongs |
A count of frames received on a particular interface that exceed the maximum permitted frame size. |
etherStatsPkts |
The total number of packets (including bad packets, broadcast packets, and multicast packets) received. |
ifOutErrors |
The number of outbound packets (or transmission units) that could not be transmitted because of errors. |
dot3StatsInternalMacTxErrors |
A count of frames for which reception on a particular interface fails due to an internal MAC sublayer receive error. A frame is only counted by an instance of this object if it is not counted by the corresponding instance of either the dot3StatsFrameTooLongs object, the dot3StatsAlignmentErrors object, or the dot3StatsFCSErrors object. The precise meaning of the count represented by an instance of this object is implementation-specific. In particular, an instance of this object may represent a count of receive errors on a particular interface that are not otherwise counted. |
dot3StatsInternalMacRxErrors |
A count of frames for which reception on a particular interface fails due to an internal MAC sublayer receive error. A frame is only counted by an instance of this object if it is not counted by the corresponding instance of either the dot3StatsFrameTooLongs object, the dot3StatsAlignmentErrors object, or the dot3StatsFCSErrors object. The precise meaning of the count represented by an instance of this object is implementation-specific. In particular, an instance of this object may represent a count of receive errors on a particular interface that are not otherwise counted. |
dot3StatsSymbolErrors |
A count of frames for which transmission on a particular interface fails due to an internal MAC sublayer transmit error. A frame is only counted by an instance of this object if it is not counted by the corresponding instance of either the dot3StatsLateCollisions object, the dot3StatsExcessiveCollisions object, or the dot3StatsCarrierSenseErrors object. The precise meaning of the count represented by an instance of this object is implementation-specific. In particular, an instance of this object might represent a count of transmission errors on a particular interface that are not otherwise counted. |
12.6.2.2 ASAP Card Ether Ports Utilization Window
The Ether Ports Utilization window shows the percentage of Tx and Rx line bandwidth used by the Ethernet ports during consecutive time segments. The Utilization window provides an Interval menu that enables you to set time intervals of 1 minute, 15 minutes, 1 hour, and 1 day. Line utilization is calculated with the following formulas:
Rx = (inOctets + inPkts * 20) * 8 / 100% interval * maxBaseRate
Tx = (outOctets + outPkts * 20) * 8 / 100% interval * maxBaseRate
The interval is defined in seconds. The maxBaseRate is defined by raw bits per second in one direction for the Ethernet port (that is,1 Gbps). Table 12-6 provides the maxBaseRate for ASAP cards.
Table 12-6 maxBaseRate for VC Circuits
|
|
VC3 |
51840000 |
VC4 |
155000000 |
VC4-2c |
311000000 |
VC4-4c |
622000000 |
Note Line utilization numbers express the average of ingress and egress traffic as a percentage of capacity.
12.6.2.3 ASAP Card Ether Ports History Window
The Ethernet Ether Ports History window lists past Ethernet statistics for the previous time intervals. The History window displays the statistics for each port for the number of previous time intervals as shown in Table 12-7. The listed parameters are defined in Table 12-5.
Table 12-7 Ethernet History Statistics per Time Interval
|
Number of Intervals Displayed
|
1 minute |
60 previous time intervals |
15 minutes |
32 previous time intervals |
1 hour |
24 previous time intervals |
1 day (24 hours) |
7 previous time intervals |
12.6.2.4 ASAP Card POS Ports Statistics Parameters
The Ethernet POS Ports statistics window lists Ethernet POS parameters at the line level.
Table 12-8 defines the ASAP card Ethernet POS Ports parameters.
Table 12-8 ASAP Card POS Ports Parameters
|
|
Time Last Cleared |
A time stamp indicating the last time statistics were reset. |
Link Status |
Indicates whether the Ethernet link is receiving a valid Ethernet signal (carrier) from the attached Ethernet device; up means present, and down means not present. |
gfpStatsRxFrame |
Number of received GFP frames. |
gfpStatsTxFrame |
Number of transmitted GFP frames. |
gfpStatsRxOctets |
Number of GFP bytes received. |
gfpStatsTxOctets |
Number of GFP bytes transmitted. |
gfpStatsRxCRCErrors |
Number of packets received with a payload FCS error. |
gfpStatsRxMBitErrors |
Sum of all the multiple bit errors. In the GFP CORE HDR at the GFP-T receiver these are uncorrectable. |
gfpStatsRxSBitErrors |
Sum of all the single bit errors. In the GFP CORE HDR at the GFP-T receiver these are correctable. |
gfpStatsRxTypeInvalid |
Number of receive packets dropped due to Client Data Frame UPI error. |
hdlcInOctets |
Number of bytes received (from the SONET/SDH path) prior to the bytes undergoing HLDC decapsulation by the policy engine. |
hdlcOutOctets |
Number of bytes transmitted (to the SONET/SDH path) after the bytes undergoing HLDC encapsulation by the policy engine. |
rxTotalPkts |
Number of received packets. |
txTotalPkts |
Number of transmitted packets |
hdlcRxAborts |
Number of received packets aborted on input. |
mediaIndStatsRxFramesBadCRC |
Number of received frames with CRC error. |
rxPktsDroppedInternalCongestion |
Number of received packets dropped due to overflow in frame buffer. |
mediaIndStatsRxShortPkts |
Number of received packets that are too small. |
mediaIndStatsRxFramesTruncated |
Number of received frames with length of 36 bytes or less. |
mediaIndStatsRxFramesTooLong |
Number of received frames that are too long. The maximum is the programmed max frame size (for VSAN support); if the max frame size is set to default, then the max is 2112 byte payload plus 36 byte header, which is 2148. |
12.6.2.5 ASAP Card POS Ports Utilization Window
The POS Ports Utilization window shows the percentage of Tx and Rx line bandwidth used by the POS ports during consecutive time segments. The Utilization window provides an Interval menu that enables you to set time intervals of 1 minute, 15 minutes, 1 hour, and 1 day. Line utilization is calculated with the following formulas:
Rx = (inOctets * 8) / interval * maxBaseRate
Tx = (outOctets * 8) / interval * maxBaseRate
The interval is defined in seconds. The maxBaseRate is defined by raw bits per second in one direction for the Ethernet port (that is,1 Gbps). The maxBaseRate for ASAP cards is shown in Table 12-6.
Note Line utilization numbers express the average of ingress and egress traffic as a percentage of capacity.
12.6.2.6 ASAP Card POS Ports History Window
The Ethernet POS Ports History window lists past Ethernet POS Ports statistics for the previous time intervals. The History window displays the statistics for each port for the number of previous time intervals as shown in Table 12-7. The listed parameters are defined in Table 12-8.