Io report caller interval

[homm]

This PR is a port of the timer-related changes from #59.

Sampling and calculation fixes

Sampling now matches the requested interval

Previously, a requested 1 s interval was internally handled as 4 x 250 ms samples plus an extra averaging pass, with the sampling loop implemented in IOReport::get_sample.

In this branch, the same 1 s interval is sampled as an actual 1 s interval instead of being split into smaller internal windows.

That earlier 4 x 250 ms scheme was introduced as a workaround for the behavior described in issue #10. However, the later investigation showed that the original problem had a different cause: the older implementation sampled only a fixed 80 ms window and then slept for the remainder of the interval, while get_metrics used that short window as the sampling duration.

Now that sampling is structured around consecutive real samples and their delta, the reported metrics are derived from the actual elapsed interval itself. Because of that, the extra 4 x 250 ms smoothing loop is no longer necessary. It also allowed the IOReport sampling path to become substantially simpler by removing the internal multi-sample orchestration that used to live in IOReport::get_sample.

Interval management is now fully owned by the caller

Another related change is that sampling no longer sleeps internally.

Previously, IOReport itself managed timing by sleeping between internal samples in IOReport::get_sample. In this branch, that responsibility is moved out of IOReport::get_sample, which now just computes the delta between the previous sample and the current one. It does not block, does not sleep, and does not decide how often sampling should happen.

This is a better separation of responsibilities:

• IOReport is responsible only for sample-to-sample delta calculation;
• the caller is responsible for scheduling and interval management;
• the elapsed time used for metric calculation is the actual measured interval, not a synthetic sub-interval chosen inside the sampling layer.

Reduced interval drift

The measurements and timings were changed since #59 to account for the 100ms minimum interval.

The same change also reduces drift across repeated short samples.

Startup time, which is not changed in this version:

$ time macmon pipe -i 100 -s 1 > /dev/null
0.12s user 0.53s system 22% cpu 2.925 total

Excluding the 100ms interval, it is about 2.925s - 100ms = 2.825s.

With -i 100 -s 100, the requested sampling time is 100 x 100ms = 10s:

$ time macmon pipe -i 100 -s 100 > /dev/null
0.83s user 3.35s system 19% cpu 21.015 total

$ time target/release/macmon pipe -i 100 -s 100 > /dev/null
0.32s user 1.61s system 15% cpu 12.821 total

The total runtime excluding startup dropped from about 21.015s - 2.825s = 18.19s to about 12.821s - 2.825s = 9.996s, which perfectly matches the requested 10s. In the old versions, there was a large 8s drift due to ignoring the IOReportCreateSamples time itself multiplied by 4.

[homm]

@vladkens unlike #59, this is not a draft. It is an isolated change based on the current main branch, with a few improvements over the original #59 implementation.