Sum-detail traces: correct idle time in Time Profile and Usage Profile

[lvkale]

Three fixes for summary-detail (.sumd) traces, found while examining a 4-PE sum-detail trace whose Time Profile showed all black (overhead) and emitted "found bad data" warnings.

Fixes

1. SumAnalyzer: Average per-interval idle over PEs, not intervals. getTotalIdlePercentagePerInterval divided each PE's idle percentage by the interval count (copied from the per-PE variant below it) instead of the PE count, making idle ~0 in every interval; Time Profile then showed the missing time as overhead — an all-black chart.

2. Time Profile: Clamp small negative values instead of zeroing the interval. Summary tracing rounds each EP's time within an interval, so a fully busy PE can report a few µs more than the interval size (verified against the raw .sumd data: the flagged intervals were 1001–1003 µs of work in a 1000 µs interval). The derived overhead then goes slightly negative and the bad-data filter discarded the whole interval with a log-corruption warning — for a 0.1% rounding overshoot. Negatives within the existing 5% tolerance are now clamped to zero; only genuinely out-of-range intervals are still discarded.

3. Usage Profile: Show idle time for sum-detail traces. The sum-detail branch of Analysis.GetUsageData filled only per-EP times and never set the idle slot, so bars showed no idle at all. Since .sumd files carry no idle data, it is now taken from the .sum files' per-interval idle percentage averaged over the selected range — the same source Time Profile uses.

Testing

• gradle copyJarToBin + ./bin/projections --exit test/hello.sts clean.
• On a 4-PE sum-detail trace (411 EPs, 4443 intervals): Time Profile now shows the expected idle band instead of all-black overhead, the 10 bad-data warnings are gone, and Usage Profile bars show idle segments consistent with Time Profile.

🤖 Generated with Claude Code