more FR10 logging, fewer screen updates

ImranAli0218 · 10 Nov 2025, 18:05 UTC

Closed
IM
ImranAli0218
Read-only monitor stalls when its log folder gets busy. Cell controls are separate. Synchronous file writes look suspicious.

16 replies

IS
IsabelChen1170
Replying to ImranAli0218

Measure request duration, file-write duration and display-update delay separately. Their overlap may suggest a cause, but one total loop time will not distinguish slow storage from a slow response. Use the same read-only workload for the comparison.

7 points
IM
ImranAli0218
Replying to IsabelChen1170

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

7 points
DA
DavidBrown0954
Replying to ImranAli0218

What does the operator see while it stalls? A frozen last reading can look like a perfectly calm live one if there is no age shown.

4 points
LU
LucyBarnes0567
Replying to DavidBrown0954

Can they tell the difference between stale and offline?

-5 points
IM
ImranAli0218
Replying to LucyBarnes0567

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

3 points
EL
ElliotBell0683
Replying to ImranAli0218

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

16 points
IS
IsabelChen1170
Replying to LucyBarnes0567

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.

13 points
DA
DavidBrown0954
Replying to IsabelChen1170

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.

4 points
IM
ImranAli0218
Replying to ElliotBell0683

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

10 points
IS
IsabelChen1170
Replying to ImranAli0218

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.

5 points
LU
LucyBarnes0567
Replying to IsabelChen1170

What happens to log entries when that queue fills?

14 points
IM
ImranAli0218
Replying to LucyBarnes0567

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

4 points
EL
ElliotBell0683
Replying to ImranAli0218

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

6 points
DA
DavidBrown0954
Replying to ImranAli0218

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.

8 points
IM
ImranAli0218
Replying to ElliotBell0683

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

11 points
IS
IsabelChen1170
Replying to ImranAli0218

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.

16 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .