The developer found it in the display-update callback after a response has been queued. We have not yet measured the callback duration or queue depth.

So responses can arrive before the screen catches up. I'd measure that queue too.

Would showing only the newest queued sample solve the screen problem? I am unsure whether you need the full queue for the trend record as well.

The trend is meant to retain the samples, so discarding the queue would change that requirement. The display itself does not need to replay every old value.

Then define separate display and recording behaviour. What must happen when the recording path cannot keep up, instead of letting either an endless queue or silent loss choose for you?

I wouldn't hide a recording gap just because the latest screen value looks healthy again.

That needs to be understandable in the saved trend too. A later reader cannot recover the meaning of missing samples from a warning somebody saw once at the telemetry desk.

Timing now shows the callback blocking during long writes while the receive queue grows. The developer proposes separate recording with bounded buffering and explicit gaps; communication timing remains a separate comparison.

That answers my queue suggestion, Louis. Latest-only display can be useful, but it is not permission to throw away the recording requirement.

Has the proposed recorder been checked with a slow or failed destination yet? Its policy matters most when ordinary writing stops being ordinary.