[GH-ISSUE #44] stress: report backward gettimeofday steps instead of silently clamping them #37

Closed
opened 2026-11-03 22:02:45 -07:00 by gitea-mirror · 2 comments
Owner

Originally created by @raynorpat on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/RhapsodiOS/RhapsodiOS/issues/44

Summary

The stress suite library (src/Commands/stress/lib/main.c, st_op_end, ffs-perf branch) times each operation with two gettimeofday() calls. Since 76352bb54 it clamps a negative interval to 0, so maxlat= can no longer wrap to 4294967ms when the clock steps backwards (#40).

The clamp keeps the reports sane, but it hides the very symptom #40 describes: a run on an affected kernel looks identical to a run on a fixed one. It was added as a workaround and needs a follow-up.

Proposed change

  • Count backward steps: in st_op_end, count the intervals that came out negative (per worker, summed by the leader).
  • Report them: add a clockback=N field to the PASS line when N > 0. The grammar is unchanged otherwise: a key=value field, no spaces. vm/stress_report.py should carry it into the summary and the kernel comparison.
  • Keep the clamp for maxlat/ops, so latency figures stay meaningful.
  • Optional: a small dedicated test (stress-proc clock or stress-vm clock) that loops gettimeofday() for a few seconds across all CPUs and FAILs with back=N maxback=Nus if time ever goes backwards. That makes #40 a pass/fail regression test instead of a side effect of other tests.

When to revisit

Once #40 is fixed, clockback should read 0 everywhere, and the dedicated test should PASS. Keep the clamp after that as protection against settimeofday / adjtime steps during a run.

Related: #40.

Originally created by @raynorpat on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/RhapsodiOS/RhapsodiOS/issues/44 ## Summary The stress suite library (`src/Commands/stress/lib/main.c`, `st_op_end`, ffs-perf branch) times each operation with two `gettimeofday()` calls. Since 76352bb54 it clamps a negative interval to 0, so `maxlat=` can no longer wrap to `4294967ms` when the clock steps backwards (#40). The clamp keeps the reports sane, but it hides the very symptom #40 describes: a run on an affected kernel looks identical to a run on a fixed one. It was added as a workaround and needs a follow-up. ## Proposed change - **Count backward steps:** in `st_op_end`, count the intervals that came out negative (per worker, summed by the leader). - **Report them:** add a `clockback=N` field to the PASS line when N > 0. The grammar is unchanged otherwise: a key=value field, no spaces. `vm/stress_report.py` should carry it into the summary and the kernel comparison. - **Keep the clamp for `maxlat`/`ops`**, so latency figures stay meaningful. - **Optional:** a small dedicated test (`stress-proc clock` or `stress-vm clock`) that loops `gettimeofday()` for a few seconds across all CPUs and FAILs with `back=N maxback=Nus` if time ever goes backwards. That makes #40 a pass/fail regression test instead of a side effect of other tests. ## When to revisit Once #40 is fixed, `clockback` should read 0 everywhere, and the dedicated test should PASS. Keep the clamp after that as protection against `settimeofday` / `adjtime` steps during a run. Related: #40.
gitea-mirror 2026-11-03 22:02:45 -07:00
Author
Owner

@raynorpat commented on GitHub (Oct 14, 2026):

Implemented on ffs-perf in e1f7a7d84 (not yet pushed or built on a guest). st_op_end counts negative intervals per worker, the leader sums them, and the PASS line gets clockback=N when N > 0. The clamp for maxlat/ops is kept.

Not done: the optional stress-vm clock test, and carrying clockback into the summary and kernel comparison (vm/stress_report.py isn't on ffs-perf). Leaving open for those.

<!-- gh-comment-id:6161001632 --> @raynorpat commented on GitHub (Oct 14, 2026): Implemented on ffs-perf in e1f7a7d84 (not yet pushed or built on a guest). `st_op_end` counts negative intervals per worker, the leader sums them, and the PASS line gets `clockback=N` when N > 0. The clamp for maxlat/ops is kept. Not done: the optional `stress-vm clock` test, and carrying `clockback` into the summary and kernel comparison (`vm/stress_report.py` isn't on ffs-perf). Leaving open for those.
Author
Owner

@raynorpat commented on GitHub (Oct 14, 2026):

Done on ffs-perf (not yet pushed): e1f7a7d84 counts negative op intervals and prints clockback=N on the PASS line (the maxlat/ops clamp stays); 5b1b6a968 adds stress-vm clock (strict compare of each gettimeofday with the previous one, FAILs with back=N maxback=Nus) and stress-vm settime (settimeofday steps back/forward with and without a pending negative adjtime slew; root only, solo, restores the clock on failure and on signals via cf75fcd0d). Both are in vm/runtests (settime only in the solo pass).

On the stock v2 kernel, clock FAILed (back=1, 8.8 ms) and settime FAILed within 1-56 iterations; on the fixed kernel (#40) both PASS and the -x self-checks FAIL as intended.

Not done: carrying clockback into a summary/kernel comparison, since vm/stress_report.py is not on this branch. Reopen or file a follow-up when that script lands.

<!-- gh-comment-id:6170713840 --> @raynorpat commented on GitHub (Oct 14, 2026): Done on ffs-perf (not yet pushed): e1f7a7d84 counts negative op intervals and prints clockback=N on the PASS line (the maxlat/ops clamp stays); 5b1b6a968 adds `stress-vm clock` (strict compare of each gettimeofday with the previous one, FAILs with back=N maxback=Nus) and `stress-vm settime` (settimeofday steps back/forward with and without a pending negative adjtime slew; root only, solo, restores the clock on failure and on signals via cf75fcd0d). Both are in vm/runtests (settime only in the solo pass). On the stock v2 kernel, clock FAILed (back=1, 8.8 ms) and settime FAILed within 1-56 iterations; on the fixed kernel (#40) both PASS and the -x self-checks FAIL as intended. Not done: carrying clockback into a summary/kernel comparison, since vm/stress_report.py is not on this branch. Reopen or file a follow-up when that script lands.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
github-starred/RhapsodiOS#37
No description provided.