# Idle baseline Sixty idle seconds on a MikroTik RB5009 read at 10 Hz: the busy floor, a softnet squeeze that is never zero, and a kernel log that stays silent. Source: https://docs.jmrp.io/mikroscope/playbooks/idle/ **In short:** on the reference RB5009 at idle, the four cores sit at 6–8 % busy, `time_squeeze` is never zero (about 200 per 20 s), and the kernel log is silent. Read every other case study against that shape: a steady stream of kernel events at idle is the anomaly, and a nonzero squeeze on its own is not. Measured on RB5009UG+S+ · 4 × 1.4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · 2026-09-12 · agent at 10 Hz in an ephemeral privileged container ## Recording Three 20-second buckets: ```text t busy% per-core busy% ctxt sirq squeeze temp MHz events 0 7.1 10.5 7.9 4.3 5.8 41793 325 296 36.2 1400 0 1 8.4 8.0 7.8 9.9 7.8 60518 251 223 36.2 1400 0 2 6.5 7.1 5.2 6.7 6.8 58259 199 179 36.3 1400 0 ``` The percentages were computed afterwards from the raw tick deltas the agent ships; the agent never turns them into percentages. This reading has no chart: it predates the history of the reference InfluxDB store, which begins on 2026-09-19. The [recorded chart](https://docs.jmrp.io/mikroscope/playbooks/idle/#recorded-chart) below is a later `record` of the same router at rest. ## What to look at - **6–8 % busy across four cores is this router's floor**, not a problem. It is DNS, DHCP, WireGuard, the bridge and its own housekeeping. - **`time_squeeze` is never zero** (~200 per 20 s). A nonzero squeeze is normal; what matters is the _change_ under load, which [the packet flood](https://docs.jmrp.io/mikroscope/playbooks/packet-flood/) shows. Alerting on "squeeze > 0" would page you forever. - **`arch_timer` and `switch0` are always the top two interrupt sources.** - **Zero kernel events is the healthy state.** Any steady stream of `events` at idle deserves the treatment in [the loop case study](https://docs.jmrp.io/mikroscope/playbooks/loop/): that is how it started. ## Background squeezes The squeeze floor was measured again in the 24 h to 2026-09-16 07:00 UTC, on the same device, over 3 738 704 per-CPU samples: - about 11.2 % of samples carry one squeeze as background; - 1.2 % carry exactly two; - 0.21 % carry exactly three. On this router on 2026-09-15, a rule that flagged any squeeze fired 92 times in twenty minutes, and meant nothing. So the collector's `burst` flag is a deviation from the device's own norm. It flags a sample whose packet count was at or below its trailing median and that has either: - a dropped packet, or - more squeezes than that CPU usually has: above its trailing 90th percentile and at least 3. The trailing baselines span ten seconds of wall clock at any rate. Three flagged samples on one CPU within 60 s raise the `microburst` detection; one flagged sample stays a data point. > **True of this device, not of yours** > > This floor is one RB5009 with its clock pinned at 1400 MHz, running its owner's DNS, DHCP, > WireGuard and bridge. A router with different services, a scaling clock or a different board has a > different idle shape. Take the same sixty seconds on yours before reading any other case study > against it. ## Recorded chart [![RB5009UG+S+, 70 s at 10 Hz: 700 samples over 69.9 s on four cores, with three dashed markers — “baseline, router idle” at 12 s, “dashboards check started” at 30 s and “check finished” at 50 s. Per-core busy stays low with single-sample excursions to 100 %; the softnet panel shows time squeezes and a flat zero for dropped; memory available stays between 662 and 671 MiB.](https://raw.githubusercontent.com/jmrplens/mikroscope/main/site/src/assets/walkthrough/rb5009-walkthrough.svg)](https://raw.githubusercontent.com/jmrplens/mikroscope/main/site/src/assets/walkthrough/rb5009-walkthrough.svg) [Open the chart at full size](https://raw.githubusercontent.com/jmrplens/mikroscope/main/site/src/assets/walkthrough/rb5009-walkthrough.svg) (SVG, 1200 × 754) to read its labels on a phone. Measured on RB5009UG+S+ · 4 × 1.4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-16 · a 70 s `record` at 10 Hz, 700 samples over 69.9 s, the router otherwise at rest, three notes typed into `record`'s terminal This is a real recording of a router at rest, the shape everything else is read against. The three dashed lines are the notes typed into `record`'s terminal during it; the chips carry them in full because they fit, and a longer one is shortened rather than laid over the next. - **t = 12 s, `baseline, router idle`.** Nothing is happening, and the panels say so: every core averages under 10 % over the whole recording, and over the quiet stretch that follows this note the four together average 3.9 %. - **t = 30 to 50 s, between `dashboards check started` and `check finished`.** A browser loading the two Grafana dashboards against this router's own collector. The four cores together average 5.0 % over that stretch, and the work arrives in two short bursts right after the note: core 0 at or above 50 % for 0.6 s from 32.3 s, and again for 0.3 s at 33.2 s. - **The work is in short excursions.** 76 of the 700 samples have a core at or above 50 %, in 46 separate stretches; 38 of those are one sample long, and the longest is 1.4 s, at the start of the recording and before the first note. The kernel's scheduler puts each excursion on whichever core is free. One isolated sample — one core at 100 % for 100 ms — moves a four-core, one-second average by 2.5 %. - **softnet: `dropped` flat at zero, `time_squeeze` between 0 and about 20 per second.** Nothing was lost in 70 s. The squeezes are this device's background rather than an event; what the collector calls a microburst is a cluster of them — three flagged samples on one core inside 60 s — and never a single one. - **memory available, 662 to 671 MiB.** About 9 MiB of ordinary churn across the recording, with no step at either end of the dashboards check. RouterOS's own `cpu-load`, at 1 s, reports this minute as a flat few per cent. The recording shows what the few per cent are made of: which core took each excursion, how long it lasted, and where the notes fall against it. > **True of this device, not of yours** > > One recording, on one router, at 10 Hz, with the router otherwise at rest. The per-panel figures > above are read off this chart, not re-measured. ## See also - [Packet flood](https://docs.jmrp.io/mikroscope/playbooks/packet-flood/): what the squeeze does when it does change. - [Layer-2 loop](https://docs.jmrp.io/mikroscope/playbooks/loop/): what a steady stream of events at idle turned out to be. - [Detection rules](https://docs.jmrp.io/mikroscope/sinks/detections/): the `microburst` rule and the others, with what each may not claim.