Files
LithosAnanake/docs/formal/scraps/architecture/03-architecture/heartbeat-system/critical-insight.tex
T

99 lines
4.2 KiB
TeX

%% SCRAP: architecture/03-architecture/heartbeat-system/critical-insight
%% SOURCE: docs/working/architecture/03-architecture/heartbeat-system/critical-insight.md
%% STATUS: HISTORICAL
%% FITS: dev-guide/ch-heartbeat
%% EDITORIAL: lifted — prose rewritten to press voice
\section{The Heartbeat Rate Is Variable, Not Fixed}
A pivotal observation reframed the design of the Phase 2 Design of
Experiments (DoE): the StarForth heartbeat is not a fixed one-millisecond
tick. It is a \emph{variable} rate that the runtime modulates in response to
load. The interval is held in the \lstinline{tick_ns} field of the heartbeat
worker, defaulting to roughly $1{,}000{,}000$~ns (1~kHz) but adjustable by the
inference engine at runtime.
\begin{lstlisting}[language=C]
/* HeartbeatWorker */
uint64_t tick_ns; /* default ~1,000,000 ns; modulated under load */
/* heartbeat_thread_main() */
uint64_t tick_ns = worker->tick_ns ? worker->tick_ns : HEARTBEAT_TICK_NS;
\end{lstlisting}
This rate modulation is the physics feedback mechanism itself, and the quality
of that modulation is what differentiates one configuration from another.
\subsection{Why the Earlier Baseline Was Incomplete}
The Stage~1 baseline ran with the heartbeat thread disabled
(\lstinline{HEARTBEAT_THREAD_ENABLED=0}). Without the thread there is no
\lstinline{tick_ns} modulation, no adaptive response to load, and no physics
in motion. The Stage~1 conclusion---that a handful of configurations were
``stable''---measured only the absence of variation in a static tick. It could
not speak to the responsiveness of heartrate modulation, because modulation was
switched off.
\subsection{The Intended Physics Story}
Here the thermodynamic framing is used as a control-theory metaphor for runtime
scheduling. When workload rises, the inference engine lengthens
\lstinline{tick_ns}, slowing the heartbeat and yielding more CPU time to
parameter tuning. Physics parameters then converge faster, and the system
adapts.
\begin{itemize}
\item A good configuration is \emph{responsive} (\lstinline{tick_ns} grows
under load), \emph{smooth} (no wild oscillation), and \emph{efficient}
(net performance improves).
\item A poor configuration is \emph{unresponsive} (rate stays fixed),
\emph{oscillating}, or \emph{inefficient} (adaptation makes matters
worse).
\end{itemize}
\subsection{What Phase 2 Should Measure}
The primary metric is heartrate modulation quality, not jitter in a fixed tick.
Per run, the harness should capture:
\begin{itemize}
\item \textbf{Rate trajectory.} The sequence of \lstinline{tick_ns} values,
converted to frequency as $f_{\text{Hz}} = 10^{9} / \mathtt{tick\_ns}$.
\item \textbf{Load--heartrate correlation.} The correlation between
per-tick workload and heartrate. A negative correlation
(slower heartbeat under heavier load, hence more thinking time) is the
desired adaptive response; near-zero correlation indicates no
adaptation.
\item \textbf{Stability.} Whether the rate converges to a steady state, how
smoothly, and how quickly it settles.
\item \textbf{Performance impact.} Whether modulation actually shortens
execution time.
\end{itemize}
The golden configuration is not the one with the steadiest heartbeat but the
one with the best adaptive response---ideally a strong load--heartrate coupling
that settles within roughly one thousand ticks.
\subsection{The Missing Instrumentation}
At the time of this analysis the thread discarded \lstinline{tick_ns} after
sleeping; the trajectory was never captured. The remedy is to log a rate sample
per tick into a rolling buffer carried on the VM, recording the tick number,
the interval in nanoseconds, the contemporaneous workload, and a timestamp.
\begin{lstlisting}[language=C]
struct HeartbeatRateSample {
uint64_t tick_number;
uint64_t tick_ns; /* the heartbeat rate */
uint64_t workload_ops; /* dictionary lookups this tick */
uint64_t timestamp_ns;
};
\end{lstlisting}
Offline analysis then computes the load--heartrate correlation directly from
the trajectory, identifying which configuration responds best to changing
workload.
%% PATENT: heartrate modulation as an adaptive-runtime feedback mechanism is
%% patent-adjacent; no claim language is drafted here.