1 / 7

Optimizing Flight Software Architecture for Solid-State Disk Performance

This document outlines a specialized flight software architecture designed by Jim Beatty in the Ohio State Computing Environment. The architecture caters to a dynamic set of processes running on a legacy SBS CR-7 Pentium III system with a stripped-down Linux installation. Key considerations include avoiding memory leaks, managing data flow to and from solid-state disks and RAMdisks, and minimizing file accesses. The system ensures graceful operation resumes after restarts while efficiently prioritizing event queues. Critical insights into logging, configuration management, and data transit are also detailed.

marika
Download Presentation

Optimizing Flight Software Architecture for Solid-State Disk Performance

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. Flight Software Architecture Jim Beatty Ohio State

  2. Computing Environment • SBS CR-7 Pentium-III at 700 MHz • ‘Stripped’ Linux installation based on RH 9.0 • 512 MB RAM • 256MB configured as RAMdisk. • 1 GB Flash disk for system • 40 GB solid-state disk for data archive • No swap!

  3. Dataflow Diagram

  4. Issues • The system must never page or swap. • Fixed suite of processes • Avoid memory leaks • Repetitive writing to solid state disk must be limited to well below the device specs. • This is subtle, because filesystem data structures are involved and we do not directly control physical writes. • Minimize file accesses by appropriate blocking. • RAMdisk is our scratch and temporary space and is limited. • System must gracefully resume operation on restart.

  5. What goes on solid-state disk? • Events are archived to solid-state disk only after passing the prioritizer. • /run/priority/subrun directory tree • Command and housekeeping logs are blocked and placed on the solid state disk. • Configuration snapshots are periodically archived to the solid-state disk. • These include event queue pointer snapshots. • We can choose to define a master configuration to be assumed on the next restart.

  6. What goes on RAMdisk? • Packets and file pointers. • Current configuration (since modifications via commands may cause multiple writes per change). • Log data not yet archived to solid state disk. • Logs used for debugging • Periodically truncated. • Logged to external storage during testing.

  7. How event queueing works • Pointers into the event queues are used to track the next event: • for each priority queue • for header and for transient packet generation. • Checkpoint pointers to archive periodically. • On restart, transmission begins from the last checkpoint, but can be commanded to skip to the most recent data. • Data ‘in transit’ at the time of reset is permanently lost. • Need to understand the impact of this on deadtime determination • Playback can be used to fill in gaps

More Related