Back to Orange Pi, ODROID & Other SBCs community Open

Orange Pi, ODROID & Other SBCs DISCUSSION

SBC storage benchmarks are fast but the logger stalls: which latency should be measured?

Started by shahira SBC storagedata loggingwrite latencyfilesystem bufferingmicroSD reliability
3 replies 248 views 4 participants
Latest activity · 27 Sep 2026

SBC storage benchmarks are fast but the logger stalls: which latency should be measured?

shahira Orange Pi, ODROID & Other SBCs Forum
#1

Community replies 3

Re: SBC storage benchmarks are fast but the logger stalls: which latency should be measured?

#2

Replicate the application's write sizes, flush policy and filesystem conditions. Average sequential throughput can hide long individual delays caused by buffering, allocation or the storage device's internal work. Measure a latency distribution and the worst observed pause under a representative load.

Re: SBC storage benchmarks are fast but the logger stalls: which latency should be measured?

#3

Separate the acquisition queue from the storage writer and size it for a defined stall budget. At 50 kB/s, a two-second pause requires at least 100 kB of queued payload, plus record and queue overhead. Sustained write capacity must still exceed the average production rate.

Re: SBC storage benchmarks are fast but the logger stalls: which latency should be measured?

#4

Test near-full storage and controlled interruption using expendable test data. Define what the application considers durable and how it detects incomplete records on restart. Board image, kernel and storage-driver changes should be recorded with the results because they can change the behavior being measured.

TEP COMMUNITY