Draft statement of work
Compliance with DOE Security Mandates (TR-1)
Download 0.66 Mb.
|
- Navigate this page:
- 3.11On-Line Document (TR-2)
- 4.0Dawn High-Level Hardware Requirements
- 4.1Dawn 0.5 petaFLOP/s System (MR)
3.10Compliance with DOE Security Mandates (TR-1)DOE Security Orders have changed over time. From time to time, these mandates cause LLNS and/or it’s Subcontractors, to fix bugs or implement security features in vendor operating systems and utilities. Offeror may handle bug fixes as follows: A “bug” is interpreted to mean that a product does not perform as documented. If a “bug” is discovered, there are standard reporting procedures which must be followed for tracking purposes. Additionally, the report from Offeror would be escalated by the Offeror or the ASC Program office to achieve priority resolution. For implementation of security features in Offeror’s operating system and utilities, Offeror requires written notification of the changes to DOE Security Orders or their interpretation that would force changes in system functionality. If the request for change would result in a modification consistent with standard commercial offerings and product plans, the Offeror may perform the change. If the change is outside the range of standard offerings, the Offeror may make the operating system source code available to the LLNS (at no additional cost, assuming the LLNS holds the proper USL and other prerequisite licenses) under the terms and conditions of the Offeror’s standard source code offering.
3.12Early Access to Sequoia Software Technology (TR-1)The Offeror may propose mechanisms to provide LLNS early access to Sequoia software technology and to test software releases and patches before installation on Sequoia that includes other steps before installing the software on Dawn and the dual boot environment on Sequoia. End of Section 3 4.0Dawn High-Level Hardware RequirementsThe ASC Program requires early access to stable code development platforms for the rapid development of Stockpile Stewardship applications for the Sequoia system. As such, the Dawn system size, measured in number of cores, should be more than half way between Purple at LLNL (8,192 core hero runs) and Sequoia O(2.5M) cores+threads. This will allow ASC code developers to achieve a significant advance in ASC IDC and Science applications scalability in the Dawn timeframe and lessen the jump from Purple and BGL at LLNL to Sequoia. Thus, it is imperative that the Dawn code development environment present the same hardware and software model to code developers that will be available on Sequoia. In particular, hardware issues such as memory hierarchy, CN interconnect topology and message passing support should present the same issues to application performance that will be experienced in the Sequoia. As an example, if high cache utilization is required for application performance on Sequoia, then Dawn must present the same performance challenges and opportunities for optimization. In addition, the ASC Program requires additional production petascale capacity. Thus, the Dawn system should deliver stable, cost-effective cycles to a wide variety of the ASC Program workload. It is envisioned that Dawn will come from Offeror’s current (or very near term) product offering and provide, to the maximum extent possible, a code development environment congruent with that of Sequoia. In specifying the Dawn system LLNS was motivated by four factors:
This Dawn system will be delivered to LLNL. The specific hardware requirements of the Dawn system are delineated in Section 4, “Dawn Hardware Requirements”. The specific software requirements for the Dawn system are delineated in Section 5, “Dawn Software Requirements”. There is only one mandatory requirement for Dawn, Section 4.1 “Dawn 0.5 petaFLOP/s System.” Technical options for Dawn are identified in Section 4.3. In addition, the integrated system features of Section 6 apply to Dawn as well as Sequoia. Rather than replicate all of the Sequoia hardware requirements in this section, LLNS includes all of the Sequoia hardware requirements and their associated priorities (TR-1, TR-2 and TR-3) and then notes differences for Dawn. However, during the course of executing the Sequoia subcontract(s), LLNS anticipates that more functionality will be provided over time. The RFP Proposal Evaluation and Proposal Preparation Instructions indicate where in the RFP response Offerors may delineate in detail the proposed schedule of hardware and software deliverables and. in particular, the Dawn and technology refresh deliverables, if applicable. In addition to the hardware and software requirements, the Offeror will deliver any additional features consistent with the objectives of this project and Offeror’s Full-Term Plan of Record, which the Offeror believes will be of benefit to LLNS. All of the Sequoia Hardware requirements (section 2) apply to the Dawn system(s), except that the following requirements supercede Section 2.
4.2(4.3) Dawn Component Scaling (TR-1)This requirement supercedes Section 2.3. In order to provide the Offeror with maximum flexibility to meet the goals of the ASC Program, the exact configuration of the Dawn scalable system is not specified. Rather, the Dawn configuration is given in terms of lower bounds on component attributes relative to the peak performance of the proposed configuration. The Dawn scalable system configuration may meet or exceed the following parameters: Memory Size (Byte:FLOP/s) 0.3 Memory Bandwidth (Byte/s/FLOP/s) 1.0 Intra-Cluster Network Aggregate Link Bandwidth (Bytes/s/FLOP/s) 0.1 Intra-Cluster Network Bi-Section Bandwidth (Bytes/s/FLOP/s) 0.001 System Sustained SAN Bandwidth (GB/s:petaFLOP/s) 384 High Speed External Network Interfaces (GB/s:petaFLOP/s) 96
Download 0.66 Mb. Share with your friends:
|