70 likes | 182 Views
Flight Software Architecture. Jim Beatty Ohio State. 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!.
E N D
Flight Software Architecture Jim Beatty Ohio State
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!
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.
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.
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.
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