The heartbeat cycle's rate as a feedback loop from the Rolling Window of Truth #195

New Issue

2026-11-13T22:30:57Z

rajames commented

2026-11-13 22:30:57 +00:00

Captain Bob, 2026-11-13: "The 256 should probably be either a kconfig knob or a feedback loop for RWOT"; then "File it and continue".

Now

A node's heartbeat cycle runs every HEARTBEAT_CHECK_FREQUENCY word calls, default 256, as v3's does. The cycle runs the tick, background decay, the window's service, L8, and inference every 1000 ticks (#189 Phase 7, ruled "By execution, as v3"). It is a Kconfig knob in Kconfig.heartbeat, and the v4 mesh reads it (v4/include/v4/mesh.h; local commit 23795039, pushed with Phase 7). The rate is fixed for the build.

Proposed

Let the Rolling Window of Truth set the rate: a feedback loop beside Loop #5, the window tuner. Ideas to weigh:

When the window's diversity is changing fast, the regime is shifting, so cycle more often. When it is steady, cycle less, which saves the cycle's cost.
Keep the tick execution-driven, so it stays the same on every architecture and so does dict_hash: the rate would depend only on what the node executed, never on wall time.
Bounds and hysteresis, as L8's are, so the rate cannot oscillate.
Kconfig's value stays as the starting rate, and as the fixed rate when the loop is turned off.

Not v3

v3 has no such loop. This is new design after parity, not part of it: after #189 Phase 7.

Captain Bob, 2026-11-13: "The 256 should probably be either a kconfig knob or a feedback loop for RWOT"; then "File it and continue". ## Now A node's heartbeat cycle runs every `HEARTBEAT_CHECK_FREQUENCY` word calls, default 256, as v3's does. The cycle runs the tick, background decay, the window's service, L8, and inference every 1000 ticks (#189 Phase 7, ruled "By execution, as v3"). It is a Kconfig knob in `Kconfig.heartbeat`, and the v4 mesh reads it (`v4/include/v4/mesh.h`; local commit 23795039, pushed with Phase 7). The rate is fixed for the build. ## Proposed Let the Rolling Window of Truth set the rate: a feedback loop beside Loop #5, the window tuner. Ideas to weigh: - When the window's diversity is changing fast, the regime is shifting, so cycle more often. When it is steady, cycle less, which saves the cycle's cost. - Keep the tick execution-driven, so it stays the same on every architecture and so does `dict_hash`: the rate would depend only on what the node executed, never on wall time. - Bounds and hysteresis, as L8's are, so the rate cannot oscillate. - Kconfig's value stays as the starting rate, and as the fixed rate when the loop is turned off. ## Not v3 v3 has no such loop. This is new design after parity, not part of it: after #189 Phase 7.

rajames added this to the v4.0.0-beta.0 milestone 2026-11-13 22:30:57 +00:00

rajames added the

labels 2026-11-13 22:30:58 +00:00

Sign in to join this conversation.