580,608,000 to 518,400,000 bytes
Less data written during normal recording.
This comparison reviews the proposed design’s storage and resource budget. Whether the complete recording service meets all requirements remains open.
RECORDER DESIGN
Keep the history.
Cut the overhead.
For the same complete 30-day history, FI’s proposed layout reserves 25.18% less storage on the recorder itself. The comparison below keeps the same recording task.
Storage calculated from the proposed design
THE SAME RECORD TASK30 days
One record each second.
All 2,592,000 records retained.
Each record keeps its 64-byte payload and required timing data, with two durable logs.
1,410,048,000 to 1,161,216,000 bytes
Less data read during normal recording.
1,658,880,000 to 663,552,000 bit-level checksum steps
Fewer bit-level checksum steps for timing records.
Remove duplicate work.
The layout stores shared identification once, reducing each record’s timing data from 48 to 24 bytes. It also reserves less extra local storage. The complete recording remains available for export and review.
Recorder and input-history storage.
Adding the same complete input-history store to both designs gives a 19.97% reduction in combined reserved storage: 1,453,784,064 to 1,163,480,256 bytes.
Recovery tradeoff and unchanged work
A smaller routine recovery scan
Routine restart reads 98.72% less data: 656,580,608 → 8,391,072 bytes before saving the restart and final-state records. This path assumes one writer and previously checked storage that remains unchanged. It postpones the full corruption check. The complete diagnostic scan remains available and reads 594,374,304 bytes before saving those records.
These figures count bytes read during recovery.
Work that remains
Both designs make 15,552,000 requests to save writes durably and export the same complete 228,096,016-byte recording.
Conventional software can use the same layout.