I enabled detailed inspection-status logs and our FR10 diagnostic display now sometimes sits on an old reading while the folder is busy. This is a bench replay setup with a fixture block; cell controls are separate. File writing looks suspicious, but how should I measure it without overlooking communication delays?
Time request handling, file writing and display updates separately on the same occurrence, using elapsed durations as well as the observation time; folder activity alone does not identify the blocking stage.
I've instrumented those stages in the replay. The long display gaps coincide with long file-write durations on several occurrences. Some request durations are long too, so there may be more than one source of delay.
Can you compare the same recorded input with detailed logging reduced, without changing the request or display workload? That would help test the writing suspicion rather than rely only on coincident timings.
Make observation age visible meanwhile, because a stuck but plausible reading can mislead someone arriving after the display stopped updating; this does not imply the separate cell controls have stopped.
Before moving writes to another worker, agree what the recorder must retain. A bounded queue needs a deliberate overflow policy and a visible failure state. An unlimited queue can hide a slow destination for a while and then create a different problem.
Reduced-detail replay removes the largest display pauses, while the slow request cases remain. I have proposed a separate bounded writer and freshness display. Recording requirements are still being agreed, so no overflow policy chosen yet.
Keep both timing findings. The writer change may address the display waiting on file work, but it should not close the request-delay enquiry or label every earlier pause as a disk problem.
Also test how the recorder ends and restarts with queued work outstanding. Maintenance needs to know whether a log is complete, incomplete or unavailable, not discover later that a tidy shutdown message was only about the display process.
Keep recording health separate from reading freshness, since a fresh display can coexist with missing logs and a healthy recorder can faithfully store stale observations.
Those conditions are now in the test plan, including shutdown with queued work. Nothing deployed yet. We have evidence that writes contribute to the pauses, not a completed recorder change or an explanation for the slower requests.