# Limits of the evidence

The questions the measurements on this site cannot answer, and which metric to reach for instead of guessing.

Source: https://docs.jmrp.io/mikroscope/cost/limits/

Every router measurement on this site was taken on one device, an RB5009UG+S+, under that router's
own traffic and the few events [provoked on purpose](https://docs.jmrp.io/mikroscope/playbooks/). They were not taken on
one day: the oldest, the cost of an SSH connect, dates from 2026-08-26 on RouterOS 7.24.1, and the
others from 2026-09-11 on, on 7.24.2 and later 7.24.4; [Tested on](https://docs.jmrp.io/mikroscope/about/status/) dates
each one. The virtual lab's CHR adds correctness, not cost: it is not a board, and none of its
durations or CPU figures measures a router. What follows is what these measurements do not tell you, kept here
rather than left for a reader to discover by being wrong.

## Histogram limits

The histogram `mikroscope_cpu_busy_ticks` (integer busy ticks per sample and core, which keeps
timing jitter out of the bucket choice) recovers **time above a threshold** to one sample. It cannot recover **contiguity**: a 2 s plateau at 30 % and twenty
scattered 100 ms spikes at 30 % look identical in it.

That is what `mikroscope_cpu_busy_run_seconds{threshold="0.5"|"0.9"}` is for —
the length of each run of consecutive samples at or above the threshold,
observed when the run ends, with the run still in progress in
`…_run_open_seconds`.

The trailing-window gauges (`window="1s"|"10s"|"60s"`, `stat="max"|"min"|"p95"`)
show the peak whatever your scrape interval is, because the collector computes them
over the agent's own sample timestamps rather than over your scrape times. To see the _shape_ of a transient
rather than its envelope, `record` it, or let a trigger capture it.

## Sampler timing

How late the sampler woke after its ticker and how long the read took are
`mikroscope_tick_wake_latency_seconds` and `mikroscope_tick_read_seconds`, with
the interval actually achieved in `mikroscope_tick_interval_seconds`. If you
suspect the sampler rather than the router, those three are where to look
first.

## Gaps

The agent keeps 60 s by default. A collector outage shorter than that is
backfilled on reconnect through `since=<seq>`; a longer one is reported as a gap
of known length — a marker in a recording, a counter on the collector. A chart
with a hole in it is a chart telling the truth.

> **Not measured, so not claimed**
>
> Any board that is not the RB5009 described on [Rate ceiling](https://docs.jmrp.io/mikroscope/cost/rate-ceiling/).
> Traffic heavier than about 19 Mbit/s. A 32-bit RouterOS build, which is
> coming on a hEX S but has not arrived. Sustained operation beyond the windows stated. None of
> these are claims this project is making, and none of them should be inferred from the ones it is.

## See also

- [Rate ceiling](https://docs.jmrp.io/mikroscope/cost/rate-ceiling/): the six runs and the conditions they were taken
  under.
- [Agent cost](https://docs.jmrp.io/mikroscope/cost/): the budget, and how to measure the cost on a device that is not
  this one.
- [Tested on](https://docs.jmrp.io/mikroscope/about/status/#not-tested): everything else that has not been tested.