more FR10 logging, fewer screen updates

One loop currently does all three. We only recorded total duration. Adding the separate timings.

Can they tell the difference between stale and offline?

No. Last value stays green. Age is only in the log they're waiting for.

Imran, does that mean the whole window freezes, or just the displayed value stops changing?

Lucy, that distinction needs to survive the redesign too. An old observation should not automatically be called a communication failure. It may be the application that is stuck before making the next request.

Isabel, yes. From the other bench we need to know whether the reading is current before we need the detailed reason. I wouldn't hide the age in another page.

Elliot, window freezes too. Separate timings show the long gaps inside log writes in our captured runs.

Move the diagnostic writes out of that updating path in the test version, with a bounded queue and an explicit overflow policy. Do not turn a slow disk into unlimited memory growth. Keep measuring communication as well; these runs need not explain every delay.

What happens to log entries when that queue fills?

Proposal drops excess diagnostic entries with a visible dropped-entry count. It won't block sampling for them.

Would the support export include that dropped count, Imran, or could someone mistake the remaining entries for a complete incident trace?

And please test the visible stale state while the log destination is deliberately slow. A smooth normal run won't show whether the new display still freezes at the awkward moment.

Test version stays responsive with slow writes and reports dropped diagnostics in the export. Delayed reads show stale. Long-duration comparison isn't finished.

Keep the sample observation time distinct from the time the screen redraws. That is worth checking after the responsiveness fix, since a busy application can repaint an old value very efficiently.