[hitHuang]

Summary

timerjitter() uses cur_cnt++ < max_cnt as the loop condition. The
post-increment fires even on the final check that exits the loop, so
cur_cnt ends up one greater than the number of samples actually
collected, and avg = avg / cur_cnt divides by a count that's too
large by one. Fix by incrementing cur_cnt inside the loop body
instead.

Impact

Only affects apps/testing/sched/timerjitter's reported avg value.
No API/Kconfig/doc changes.

Testing

QEMU RISC-V (rv-virt:knsh_romfs), CONFIG_TESTING_TIMERJITTER=y,
CONFIG_USEC_PER_TICK=1000.

Before:

nsh> timerjitter
timer jitter in 1 run:
(latency/us) min: 5549, avg: 2774, max 5549

After:

nsh> timerjitter
timer jitter in 1 run:
(latency/us) min: 5256, avg: 5256, max 5256

Note: this app has other pre-existing issues beyond this one, e.g.
with CONFIG_USEC_PER_TICK=10000:

nsh> timerjitter
timer jitter in 0 run:
(latency/us) min: 18446744073709551615, avg: nan, max 0

and with certain argument combinations:

nsh> timerjitter 10000 10
time frame missed 1
timer jitter in 10 run:
(latency/us) min: 10593, avg: -1355, max 18446744073709550551

There are likely more such issues (a Claude-assisted scan surfaces
several). This PR intentionally only fixes the off-by-one above since
it affects basic correctness. The rest are left alone — I'm not
familiar enough with NuttX apps' design conventions to know whether
they're intentional simplicity trade-offs, so I'd rather not guess at
fixes for them here.

[linguini1]

Could you raise issues for the other problems you spotted? If you don't want to submit patches for them then at least we have a record :)

[hitHuang]

@linguini1 Done — filed BUG#3634 keep a record of the other issues I spotted while testing. Didn't include fixes for now since I'm not fully sure what the expected behavior should be in each case, but wanted to make sure they're tracked.