[Top] | [Previous] | [Next]

5.1.1 Architecture Limitations

At the higher data rate boundaries, several architecture component limitations must be considered in allocating processing load across platforms. These limitations include LAN throughput, LAN timing, and processor performance.

LAN Throughput. LAN throughput becomes a major limiting factor in selecting suitable contact architecture alternatives, because it limits the feasible processing options on any one platform such that the data output from the processes can be effectively transmitted to the next process in line. LAN throughput between two nodes is limited by the bandwidth of the physical medium and performance of the communications protocol used to exchange data among various platforms connected to the LAN.

Modern switching hubs and ATM switches can provide maximum theoretical bandwidth to each LAN segment: 155 Mbps for ATM, 100 Mbps for Fiber Distributed Data Interface (FDDI) or 100BaseT Ethernet, or 10 Mbps for 10BaseT Ethernet. However, the communications protocol and system input/output overhead used become the limiting factors, especially at higher theoretical bandwidths. To obtain benchmark performance factors, network protocol performance was measured (March 1996) with a point-to-point ATM connection (155 Mbps capacity) between two SPARCStation 20 workstations executing Solaris 2.3, User Datagram Protocol (UDP), and no other applications. The maximum sending rate measured was 131 Mbps, and the maximum receiving rate was 79.8 Mbps. This result compares with UDP performance of 60-75 Mbps over FDDI (60-75% of capacity), and 9+ Mbps over Ethernet (90+% capacity).

When the Transmission Control Protocol (TCP) layer was added to the benchmark test configuration, ATM input/output rates dropped to 50 Mbps (32% of capacity). This compares with current TCP performance over Ethernet at close to 90% of the LAN capacity. Note, that the above measurements were conducted over untuned COTS software and hardware and could be improved if the systems were tuned. For example, the achievable TCP rate over ATM has been increasing 10+% every few (~8) months. It is a reasonable assumption that by changing the hardware and tuning the software we can improve the future TCP-over-ATM rate to nearly 90% of link capacity, or 139 Mbps.

For this architecture study, the trade-offs required are between performance and reliability. For higher performance, a UDP protocol can be assumed, but for higher reliability and security, a TCP protocol should be assumed, because TCP includes packet retransmission upon error detection and identification of the transmission source. Because the SSCS FRD includes data quality and security requirements in a number of areas, the TCP protocol will be assumed for this analysis and the maximum LAN throughput will be 50 Mbps for an ATM LAN segment. If a 50% reserve for peak traffic is retained, then the maximum allowed throughput between any two platforms is 25 Mbps.

LAN Timing. Time delays between platforms connected to a LAN become a performance-limiting factor when time-critical activities must be executed. Sufficient uncertainty exists in the physical layers of the communications protocols such that some processor configuration options are not feasible. While there are no time-critical requirements in telemetry processing that restrict allocation options, the time-critical commanding requirement discussed in Appendix C may result in eliminating some Commanding architecture options discussed in Appendix C.

Processor Performance. For Telemetry, Commanding, and GSS functions, processor performance is measured primarily by the SPEC integer 1992 (SPECint92) rating, since most operations performed in these functions are integer. A more precise performance measure (not in scope of this study) would also include floating point ratings for algorithm processing and EU conversions, I/O ratings for data throughput between processors, and storage ratings for data archiving.

SPECint92 ratings are shown in Table 1 for the three processor types used in the telemetry/commanding architecture analysis. These ratings were extracted from tables published by SPEC. If a 50% performance margin is retained in reserve for future application growth and to account for analysis uncertainties, then the maximum allowable processor loads should be used in the analysis of platform allocation options.

For front-end processing, currently only a Sparc20 processor-based VME board is available. For workstation processing, the highest-rated uniprocessor workstation is a DEC Alpha 600/5/300 with one processor, rated at 337.8 SPECint92. For server processing, the highest rated mid-size multiprocessor server at the time of this analysis is a DEC Alpha 2100/5/250 with 4 processors, rated at 24,996 SPECint-rate92, which can be roughly translated to 1055 SPECint92[1]. The highest rated multiprocessor server at the time of this analysis is a DEC 8400/5/300, with 12 processors, rated at 91,580 SPECint-rate92, which can be roughly translated to 3864 SPECint92. A multiprocessor server is theoretically feasible for the contact applications because the Telemetry, Commanding, and GSS functions can be partitioned to different processors

Table 1. Contact Platform Performance Ratings



SPECint92 Rating
Maximum Allowable Load
Sun SS20/HS21, HyperSPARC VME board
Workstation (Mid-size)
DEC Alpha 250/4/266 with 1 A21064 processor
Workstation (High-end)
DEC Alpha 600/5/300 with 1 A21164 processor
Server (Mid-size)
DEC Alpha 2100/5/250 with 4 A21164 processors
Server (High-end)
DEC Alpha 8400/5/300 with 12 A21164 processors

Processing platform cost was not included in the analysis so that a price versus performance metric could be discerned. The processors shown are probably the most expensive in their class. Further architecture trades could be accomplished if cost were a consideration.