# Línea base en reposo Sesenta segundos en reposo de un MikroTik RB5009 leídos a 10 Hz: el suelo de ocupación, un squeeze de softnet que nunca es cero y un log del kernel mudo. Source: https://docs.jmrp.io/mikroscope/es/playbooks/idle/ **En resumen:** en reposo, los cuatro núcleos del RB5009 de referencia están ocupados un 6–8 %, `time_squeeze` nunca es cero (unos 200 cada 20 s) y el log del kernel calla. Lee todos los demás casos contra esa forma: un flujo constante de sucesos del kernel en reposo es la anomalía, y un squeeze distinto de cero, por sí solo, no. Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · 2026-09-12 · agente a 10 Hz en un contenedor privilegiado efímero ## Grabación Tres tramos de 20 segundos: ```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 ``` Los porcentajes se calcularon después a partir de los deltas de ticks en bruto que envía el agente; el agente nunca los convierte en porcentajes. Esta lectura no tiene gráfico: es anterior al historial del almacén InfluxDB de referencia, que empieza el 2026-09-19. El [gráfico grabado](https://docs.jmrp.io/mikroscope/es/playbooks/idle/#gráfico-grabado) de abajo es un `record` posterior del mismo router en reposo. ## Qué mirar - **Un 6–8 % de ocupación en los cuatro núcleos es el suelo de este router**, no un problema. Son DNS, DHCP, WireGuard, el bridge y su propio mantenimiento. - **`time_squeeze` nunca es cero** (~200 cada 20 s). Un squeeze distinto de cero es normal; lo que importa es el _cambio_ bajo carga, que muestra [la inundación de paquetes](https://docs.jmrp.io/mikroscope/es/playbooks/packet-flood/). Una alerta con "squeeze > 0" te despertaría para siempre. - **`arch_timer` y `switch0` son siempre las dos fuentes de interrupciones con más actividad.** - **Cero sucesos del kernel es el estado sano.** Cualquier flujo constante de `events` en reposo merece el tratamiento del [caso del bucle](https://docs.jmrp.io/mikroscope/es/playbooks/loop/): así empezó. ## Squeezes de fondo El suelo del squeeze se volvió a medir en las 24 h hasta el 2026-09-16 a las 07:00 UTC, en el mismo equipo, sobre 3 738 704 muestras por CPU: - alrededor del 11,2 % de las muestras llevan un squeeze de fondo; - el 1,2 % lleva exactamente dos; - el 0,21 % lleva exactamente tres. En este router, el 2026-09-15, una regla que marcaba cualquier squeeze saltó 92 veces en veinte minutos, y no significaba nada. Así que la marca `burst` del colector es una desviación respecto a la norma del propio equipo. Marca una muestra cuyo número de paquetes estuvo en su mediana móvil o por debajo y que tiene: - un paquete descartado, o - más squeezes de los que esa CPU suele tener: por encima de su percentil 90 móvil y al menos 3. Las líneas base móviles abarcan diez segundos de reloj de pared a cualquier cadencia. Tres muestras marcadas en una CPU en 60 s disparan la detección `microburst`; una sola muestra marcada se queda en un dato. > **Cierto en este equipo, no en el tuyo** > > Este suelo es un RB5009 con el reloj fijado a 1400 MHz, que ejecuta el DNS, el DHCP, el WireGuard > y el bridge de su propietario. Un router con otros servicios, un reloj que escala o una placa > distinta tiene otra forma en reposo. Toma los mismos sesenta segundos en el tuyo antes de leer > cualquier otro caso contra ella. ## Gráfico grabado [![RB5009UG+S+, 70 s a 10 Hz: 700 muestras en 69,9 s sobre cuatro núcleos, con tres marcadores discontinuos: «baseline, router idle» a los 12 s, «dashboards check started» a los 30 s y «check finished» a los 50 s. La ocupación por núcleo se mantiene baja, con excursiones de una sola muestra al 100 %; el panel de softnet muestra time squeezes y un cero plano en los descartes; la memoria disponible se mantiene entre 662 y 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) [Abre el gráfico a tamaño completo](https://raw.githubusercontent.com/jmrplens/mikroscope/main/site/src/assets/walkthrough/rb5009-walkthrough.svg) (SVG, 1200 × 754) para leer sus etiquetas en un móvil. Los rótulos de los paneles van en inglés porque `plot` los escribe así: el título lo pones tú con `--title`, el resto es el vocabulario del kernel. Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-16 · un `record` de 70 s a 10 Hz, 700 muestras en 69,9 s, el router por lo demás en reposo, tres notas escritas en el terminal de `record` Es una grabación real de un router en reposo, la forma contra la que se lee todo lo demás. Las tres líneas discontinuas son las notas escritas en el terminal de `record` durante ella; las etiquetas las llevan enteras porque caben, y una más larga se acorta en vez de montarse sobre la siguiente. - **t = 12 s, `baseline, router idle`.** No pasa nada, y los paneles lo dicen: cada núcleo promedia menos del 10 % en toda la grabación, y en el tramo tranquilo que sigue a esta nota los cuatro juntos promedian un 3,9 %. - **t = 30 a 50 s, entre `dashboards check started` y `check finished`.** Un navegador cargando los dos paneles de Grafana contra el colector de este mismo router. Los cuatro núcleos juntos promedian un 5,0 % en ese tramo, y el trabajo llega en dos ráfagas cortas justo después de la nota: el núcleo 0 al 50 % o por encima durante 0,6 s desde los 32,3 s, y otros 0,3 s a los 33,2 s. - **El trabajo está en excursiones cortas.** 76 de las 700 muestras tienen un núcleo al 50 % o por encima, en 46 tramos separados; 38 de ellos duran una sola muestra, y el más largo dura 1,4 s, al principio de la grabación y antes de la primera nota. El planificador del kernel pone cada excursión en el núcleo que esté libre. Una muestra aislada —un núcleo al 100 % durante 100 ms— mueve una media de un segundo sobre cuatro núcleos en un 2,5 %. - **softnet: `dropped` plano en cero, `time_squeeze` entre 0 y unos 20 por segundo.** No se perdió nada en 70 s. Los squeezes son el fondo de este equipo, no un suceso; lo que el colector llama microburst es un racimo de ellos —tres muestras marcadas en un mismo núcleo dentro de 60 s—, y nunca uno solo. - **Memoria disponible, de 662 a 671 MiB.** Unos 9 MiB de vaivén normal en toda la grabación, sin ningún escalón en ninguno de los dos extremos de la comprobación de los paneles. El propio `cpu-load` de RouterOS, a 1 s, da este minuto por un puñado plano de puntos porcentuales. La grabación muestra de qué está hecho ese puñado: qué núcleo se llevó cada excursión, cuánto duró y dónde caen las notas frente a ella. > **Cierto en este equipo, no en el tuyo** > > Una grabación, en un router, a 10 Hz, con el router por lo demás en reposo. Las cifras por panel > de arriba están leídas de este gráfico, no vueltas a medir. ## Véase también - [Inundación de paquetes](https://docs.jmrp.io/mikroscope/es/playbooks/packet-flood/): lo que hace el squeeze cuando sí cambia. - [Bucle de capa 2](https://docs.jmrp.io/mikroscope/es/playbooks/loop/): lo que resultó ser un flujo constante de sucesos en reposo. - [Reglas de detección](https://docs.jmrp.io/mikroscope/es/sinks/detections/): la regla `microburst` y las demás, con lo que cada una no puede afirmar.