Burst Memory Management
Figure 1 | Overview of the last 30 days.
a: The number of HELD buffers (with their category in different colors). The data storage volume is 24576 buffers (or about 96GB). Definition of Category 0, 1, 2, etc, is here. The size of the reserved pool is adjusted occasionally.
b: The number of overwritten buffers per day (with their category in different colors). Low FOM segments may be overwritten if higher FOM segments need to be HELD buf there weren't enough room for them. Segments with 'STATUS = "DERELICT" or "DEMOTED"' are counted.
c: The number of transmitted (and hence "COMPLETE") buffers per day (with their category in different colors). This is calculated as Ftransmitted = Fnew - Foverwritten - dFtotal where Fnew is the number of newly HELD segments (the bar height in panel d), Foverwritten is the number of overwritten/erased segmenets (the bar height in panel b) and dFtotal is the difference of the total number of HELD buffers (increment/decrement in panel a). Low FOM segments may be overwritten if higher FOM segments need to be HELD but there weren't enough room for them.
d: The number of new buffers per day (with their category in different colors).
e: The number of new buffers per day (with their current status in different colors). The most recent bar tends to have a larger fraction of 'HELD' (pending) buffers.
Memorandum
Segment vs Buffer
A burst segment is a set of burst buffers selected by SITLs and is defined across all four spacecraft. This webpage displays the status of burst segments instead of individual buffers. Each segment evolves with specific rules. See the chart below ('Segment Life Cycle') for how each segment is managed by the Burst Data Management (BDM) system.
A burst buffer is managed on each spacecraft. Nominally, SITLs do not need to worry about how buffers are managed on each spacecraft. However, if you are interested, you can go to the SDC website and view two reports: BDM Buffer Counts and MMS Burst Synch, as described below.
Segment Life Cycle
Each segment has a "STATUS" and it evolves as illustrated below.
Here is a note by Russ Panneton:
- Only a buffer may have an INUSE status, never a data segment, but both may have the HELD status.
- The data segment statuses are not all mutually exclusive. For example, it is possible for a data segment to end up with all of REALLOC+INCOMPLETE+DERELICT+FINISHED."
Burst Reports
BDM Buffer Counts: In this report, the number of buffers in various states is shown for each spacecraft. Also shown (in the line with the label "types") is the total volume of HELD data in MegaBytes. Note that the data storage volume is about 96 GB (implemented in 24576 buffers).
MMS Burst Synch: In this report, the amount of data relative to the spacecraft with the least amount of HELD burst data (the lead spacecraft) is shown for each spacecraft. The lead spacecraft has a value of zero regardless of how much HELD data it actually has onboard. The other numbers represent, in megabits (NOT megabytes), how far behind the lead spacecraft each spacecraft is. This report should help the MOC establish DSN contact plans to even out data downlink and recorder volumes over a period of weeks, not days.
An additional comment by Russ Panneton: Another confusing aspect of BDM may be its buffer management. Take the example earlier in commissioning when we HELD the maximum allowable number of buffers on MMS1. As additional high FOM data segments were defined, the appropriate buffers were HELD on the other Observatories (that had data for those time ranges) and *only as necessary*, low FOM buffers were un-HELD on MMS1 to allow us to hold more recently selected higher FOM data. Even if one Observatory reaches its maximum allowed number of HELD buffers, allocation of buffers on the other Observatories is managed individually for each Observatory. The overall goal is to keep the allocations even but we know we'll have some missed contacts and other conditions that may lead to imbalance in the number of HELD buffers across the constellation. One Observatory becoming full won't lock out data segments from getting buffers on other Observatories. When identifying data segments that must release their HELD buffers, a tie in FOM values is broken by releasing the oldest buffers first.