[Top] | [Previous] | [Next]

5.1.2 Contact Performance Drivers - High Data Rates

Several possible functional allocations can be eliminated by studying LAN data throughput and processing load requirements. Table B-1 provides values of Throughputmax (with archiving) for various telemetry rates that exist within the SCN environment. For the highest telemetry rate case, Nominal Throughputmax = 22,432 Kbps and Non-nominal Throughputmax = 24,736 Kbps. From Appendix B, Section B-7.1, ThroughputGSS = 43,622 bps. Thus, the total Non-nominal Throughputmax = 24,780 Kbps. This rate is just within the throughput capability of an ATM LAN segment (25 Mbps) at the current level of TCP/IP protocol performance. Thus, any of the eight telemetry options defined in Appendix B can be employed.

LAN timing uncertainties do not affect any of the telemetry or GSS processing requirements. However, the time-critical commanding requirement discussed in Appendix C eliminates Commanding Option 8.

The maximum load for a single platform is the sum of the Telemetry, Commanding, and GSS loads for all applicable functions:

Telemetry 232.060 SPECint92

Commanding 49.800

GSS 0.093

281.953 SPECint92

This load would be over 83% of a DEC Alpha 600 workstation, which exceeds the 50% processor margin requirement. Also, the FRD requires multiple Telemetry activities and a second Telemetry process would introduce even higher loads. Since the processes with the largest load are Display (128 SPECint92), Telemetry Monitor (79.01), and Command Verify (35.6 SPECint92), these functions are candidates for allocation to other platforms.

Since the workstation platform is limited to a load of 169 SPECint92, the Display function, which requires 128 SPECint92, easily can fit. However, adding the Telemetry Monitor function would exceed the performance margin. Thus, Telemetry Options 6, 7, and 8 are eliminated.

The Front-End platform is limited to a load of 66 SPECint92, which restricts the processing functions to Command Constraint Check and Verify (49.82 SPECint92 total), or Telemetry Extract and Convert (25.05 SPECint92 total). Thus Telemetry options 1 and 2 and Commanding Option 1 are eliminated.

Analyzing the server load, the maximum load across Telemetry options 3, 4, and 5 and Commanding options 2 through 6 occurs with Telemetry option 5 and Commanding option 6. The sum of the Telemetry, Commanding, and GSS loads for these functions is:

Extract 14.01 SPECint92

Convert 11.04

Monitor 79.01

Constraint Check 14.22

Verification 35.60

GSS 0.09

153.97 SPECint92

This load would be less than 15% of the DEC Alpha 2100 server capacity (but 45% of the DEC Alpha 600 workstation, which could also be configured as a server). Therefore, even at the highest telemetry rates and with non-nominal processing, a mid-sized DEC Alpha server could support more than one contact activity.

It may be desirable to avoid separating the Telemetry Monitor, Command Verification and Constraint Check processes, all of which rely on an inference engine or similar procedural routine. Thus, Commanding Options 3, 5, and 7 could be eliminated, but not for performance reasons. Also, Commanding Options 2 and 4 can be eliminated because all three functions could not be supported on a single front-end processor.

The remaining architecture alternatives, Telemetry Options 3, 4, and 5 and Commanding Option 6, allocate Display to the workstation, Command Transmission and Telemetry Sync to the front-end, and the other functions to a combination of the front-end or server platforms. The resulting functional allocation is shown in Figure 10, with the dotted lines surrounding the processes allocated to each platform. Note that the GSS processing load (Table B-5), while very small in comparison to the other processes, is shown for completeness.

Figure 10. Contact function and workload distribution for high data rates.

The numbers in parentheses are the workloads in units of SPECint92

Additional variations in functional allocation may be discerned. For example, the Execute Command Plan function could be allocated to the Workstation, since it is a negligible load. This alternative would be desirable if command plan execution were accomplished through a script language, which was directly initiated and executed by the operator.