1 / 17

Performance Simulation of Digital Video Cluster Fabrics: Insights and Findings

This professional seminar presents a simulation of a digital video cluster aimed at accurately modeling the performance of interconnecting fabrics within the system. The simulation addresses key assumptions, such as I/O interarrival times and the lack of backpressure from the Gigabit Ethernet IP cards. Core components, including messages and modules, are defined, emphasizing the management of data and control messages across the network. Challenges such as bus fairness, contention, and access efficiency are discussed, revealing learning experiences that closely align simulation results with real-world performance.

madison-gilliam
Télécharger la présentation

Performance Simulation of Digital Video Cluster Fabrics: Insights and Findings

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Digital Video Cluster Simulation Martin Milkovits CS699 – Professional Seminar April 26, 2005

  2. Goal of Simulation • Build an accurate performance model of the interconnecting fabrics in a Digital Video cluster • Assumptions • RAID Controller would follow a triangular distribution of I/O interarrival times • Gigabit Ethernet IP edge card would not impress any backpressure on the I/Os

  3. Fabrics Simulated

  4. Digital Video Cluster

  5. Digital Video Node

  6. Modules, Connections and Messages • Messages represent data packets AND are used to control the model • For data packets – have a non-zero length parameter • Contain routing and source information • Modules handle message processing and routing • By and large represent hardware in the system • PCI Bus module – not actual hardware, but necessary to simulate a bus architecture • Connections allow messages to flow between modules • represent links/busses • Independent connections for data vs. control messages • May be configured with a data rate value to simulate transmission delay

  7. Managing Buffer/Bus access Before transferring a data message (RWM) Need to gain access to transfer link/bus and destination buffer

  8. PCI Bus Challenges • Maintain Bus fairness • Allow multiple PCI bus masters to interleave transactions (account for retry overhead) • Allow bursting if only one master

  9. PCI Bus Module Components • Queue – pending RWM’s • pciBus[maxDevices] array – utilization key • reqArray[maxDevices] – pending rqst messages • Work area – manages RWM actually being transferred by the PCI bus • 3 Message types to handle • rqst messages from PCI bus masters • RMW messages • qCheck self-messages

  10. Handling rqst and RWM messages • When RWM finally hits the work area • Set RMW.transfer value = length of message (1024) • Schedule qCheck self-message to fire in 240ns (time to transfer 128bits)

  11. Handling qCheck Messages

  12. Determining Max Bandwidth

  13. Simulation Ramp-up

  14. 105Second @ 120MBps Results

  15. Contention / Utilization / Capacity

  16. Learning Experiences • PCI Contention • First as a link like any other maintained by the StarGen chip • Buffer contention and access • Originally used retry loops – like actual system - way too much processing time! • Retry messages that are returned are a natural design given the language of messages and connections.

  17. Conclusion / Future Work • Simulation performed within 7% of actual system performance • PCI bus between IB and StarGen potential hotspot • Complete more iterations with minor system modifications (dualDMA, scheduling) • Submitted paper to the Winter Simulation Conference

More Related