Re: [PATCH v3] rt-tests: hwlatdetect: Add MTBF calculation

On Wed, 25 Feb 2026 at 01:45, John Kacur <[email protected]> wrote:
> With newer kernels you can get multiple latency events ie, the count  per
> timestamp but you don't know when they occurred. (the timestamp measures the occurence
> of the first event)
> Does it therefore make more sense to measure the mean time between samples
> (distinct timestamp entries)
>
> Does the following make more sense?
>
> if detect.samples > 1:
>     info(f"MTBF: {(float(detect.last) - float(detect.first)) / (len(detect.samples) - 1):.3f} seconds")

I disagree. Naturally, a longer sampling width increases the error.
While using the total number of samples instead of the number of
failures might appear more deterministic (since it avoids the
resolution error inherent in width length), it fails to estimate MTBF.
Such a metric becomes proportional to the duration of the sampling
width (by several failures per sample width), whereas a true MTBF
should remain independent of it.

Your question has led me to consider how non-sampling periods
contribute to the error margin. The adjusted MTBF should therefore be
compensated by multiplying it by the ratio of window to width. I’ll
send an updated patch that includes this compensation factor.

Thanks
Costa