# Techo de muestreo

Seis ejecuciones medidas a 10, 20, 50 y 100 Hz en un RB5009 con la configuración de serie, sin perder ni una muestra, y lo que aporta muestrear más rápido.

Source: https://docs.jmrp.io/mikroscope/es/cost/rate-ceiling/

**El agente no perdió ninguna muestra en el RB5009 a ninguna cadencia hasta el tope de 100 Hz de la
propia CLI**, con todas las fuentes leídas en cada tick en el peor caso. Eso no es una extrapolación
desde la cifra de 10 Hz: son seis ejecuciones.

## Ejecuciones

Cada cifra sale del propio cgroup del agente, viaja en cada muestra y se lee de vuelta desde el almacén, con el conjunto completo de fuentes.
Cada fila es una ventana con el anillo ya lleno:

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-18 · ventanas de 300 s en régimen estacionario (con el anillo ya lleno), conjunto completo de fuentes, la configuración que se envía —anillo de 60 s, límite de memoria derivado de él y el tope de contenedor de serie de 64M— con el colector reenviando a InfluxDB 3

Las ejecuciones medidas:

| cadencia | suelos | CPU de un núcleo | µs/muestra | RSS | ticks retrasados | huecos / descartes |
| --- | --- | --- | --- | --- | --- | --- |
| 10 Hz (por defecto) | por defecto | **2,69 %** | 2 685 | 13,2 MiB | **0** | 0 / 0 |
| 20 Hz | por defecto | **4,61 %** | 2 303 | 15,4 MiB | **0** | 0 / 0 |
| 50 Hz | por defecto | **9,63 %** | 1 926 | 23,3 MiB | **0** | 0 / 0 |
| 100 Hz | por defecto | **16,83 %** | 1 684 | 45,7 MiB | 5 (0,02 %) | 0 / 0 |
| 50 Hz | `FLOOR_HZ=50` | **22,56 %** | 4 511 | 25,1 MiB | 4 (0,03 %) | 0 / 0 |
| 100 Hz | `FLOOR_HZ=100` | **42,70 %** | 4 270 | 49,5 MiB | 178 (0,59 %) | 0 / 0 |

`FLOOR_HZ` significa que cada fuente se lee en cada tick, sin ningún suelo por
fuente — el peor caso que se le puede pedir al agente.

**Todas las filas corrieron la configuración que se envía** y no pasaron ninguna
opción de memoria: el anillo de 60 s es el valor por defecto y el límite se
deriva de él —16 MiB a 10 y 20 Hz, 25 a 50, 48 a 100— bajo el tope de contenedor
de serie de 64M. La campaña anterior no podía hacer eso: necesitaba
`--memory-max 96M` a 50 Hz y `128M` a 100, y su fila de 10 Hz guardaba un anillo
de 300 s. Mismo equipo, mismas fuentes: **entre un 38 y un 59 % menos de memoria
por fila, y la CPU sin moverse**: 2,85 % de un núcleo a 10 Hz el 2026-09-15 frente a
2,69 % el 2026-09-18.

La memoria sigue cambiando de fila en fila porque el anillo cambia: guarda 60 s
de muestras sea cual sea el ritmo, así que diez veces el ritmo son diez veces el
anillo.

> **No se perdió nada a ninguna cadencia, en ninguna configuración**
>
> Los segundos muestreados cubrieron el reloj de pared hasta 1,0000 en las seis ejecuciones, y la
> cadencia entregada fue la configurada con tres cifras — 99,98 Hz en la peor de ellas, la de
> 100 Hz con cada fuente en cada tick. El colector no informó de ningún hueco y su destino de
> InfluxDB 3 de ningún descarte en ninguna ventana.

## Leer la tabla

### Coste por muestra

Una muestra cuesta 2 685 µs a 10 Hz frente a 1 684 µs a 100 Hz. No es
una paradoja, son los suelos funcionando: las fuentes caras se amortizan entre más muestras.
`/proc/slabinfo`, una de las fuentes caras (13,8 kB), se lee cada 2 ticks a 10 Hz y cada 17 a 100 Hz, así que una
muestra media cuesta menos mientras la _frecuencia_ de lecturas de slabinfo se queda cerca de su suelo de 6 Hz en ambos casos (5 Hz a 10 Hz, unos 5,9 Hz a 100 Hz). Así que diez veces los datos
cuestan unas 6,3 veces la CPU, no diez: 16,83 % a 100 Hz frente
a 2,69 % a 10.

Con `FLOOR_HZ` no hay nada que amortizar y el coste por muestra es plano —
son 4 511 µs a 50 Hz y 4 270 µs a 100 Hz — así que la CPU
escala linealmente con la cadencia: 22,56 %, y luego 42,70 %.

### Ticks retrasados

La muestra se produce igual y se entrega igual, llevando su `dt_ns` real, así
que cualquier tasa calculada a partir de ella sigue siendo correcta. Es un
emborronamiento, no un agujero, y se ve en
`mikroscope_tick_interval_seconds`. A 100 Hz con todo en cada tick, 29 777 de
29 994 intervalos —el 99,3 %— cayeron aun así dentro de 11 ms de un período de
10 ms; el percentil 99,5 fue 11,3 ms y el peor intervalo suelto, 21,7 ms.

## Lectura frente a CPU

Con los suelos por defecto, todas las fuentes de un tick se leen en menos de
2 ms en el 97,7 % de las muestras a 100 Hz, holgadamente dentro de un período de
10 ms. `FLOOR_HZ` empuja el 1,45 % de las lecturas más allá
de 5 ms —y ni una sola de 29 996 bajó de 2 ms—, y esos son los ticks que se
retrasan: el 0,593 % de ellos a 100 Hz con cada fuente en cada
tick, frente al 0,017 % con los suelos por defecto. El margen de CPU es mayor que el margen de tiempo,
que es por lo que el techo es una afirmación sobre E/S y no sobre el A72. Incluso con los suelos
por defecto a 100 Hz la lectura media fue de 1,2 ms pero la peor de 17,9 ms, y un tick cuya lectura
dura más que su período llega tarde por definición. De ahí, y no de un muro de CPU con
un 16,83 % de un núcleo, vienen los pocos retrasos de esa ejecución.

## Memoria por cadencia

La memoria es el anillo. Todas las demás cifras —el runtime de Go, el margen del
recolector, la fragmentación del asignador— se derivan de cuántas entradas
guarda, porque el límite blando de memoria se calcula justo de ahí. Así que la
pregunta «¿puede esta placa muestrear a 100 Hz?» es sobre todo «¿puede guardar
100 × tus segundos de búfer en muestras?», y la respuesta para toda la tabla de
arriba es que sí, dentro del tope de serie de 64M.

**Compra el margen en segundos de búfer, no en ingenio.** A 100 Hz un búfer de
20 s ocupa 6,59 MiB y deriva un límite de 17 MiB —el mismo alivio que daría
comprimir el anillo 4,7×, y la compresión se midió en este equipo en
**+1 331 µs por muestra**, que a 100 Hz son +74 % de CPU y seis veces los ticks
retrasados—. Los segundos son gratis; la compresión no.

## Cadencias más altas

Resolución de porcentaje de CPU no. El jiffie son 10 ms, así que a 100 Hz una
muestra contiene 0 o 1 ticks ocupados y la proporción de ocupación por muestra
tiene dos valores posibles. Por encima de unos 20 Hz los contadores de ticks
dejan de ser un porcentaje y pasan a ser un indicador de ocupación; a partir de
ahí la resolución la pone la PMU.

Lo que sí compra una cadencia mayor es todo lo que no está cuantizado por el
jiffie — cuentas de paquetes de softnet, deltas de interrupciones, contadores
de la PMU, las marcas de tiempo del propio log del kernel — y una cota más
estrecha sobre cuánto puede esconderse una ráfaga entre dos muestras.

> **No medido, luego no afirmado**
>
> Cualquier cadencia en una placa que no sea esta, y qué pasa bajo una carga de tráfico mayor que la
> corriente de este router — unos 19 Mbit/s en la WAN mientras corrían estas
> ventanas, con picos a 933 Mbit/s. Antes de citar un número para tu equipo, vuelve a medirlo allí:
> dos lecturas del `/metrics` del colector separadas 60 s en régimen estacionario, o los propios
> `cpu_us` y `rss` del agente en el almacén que uses — `mikroscope_self` en InfluxDB y en los
> almacenes SQL, con otros nombres en el resto, que
> [Medir en tu router](https://docs.jmrp.io/mikroscope/es/cost/#medirlo-en-tu-propio-equipo) enumera.

## Véase también

- [Coste del agente](https://docs.jmrp.io/mikroscope/es/cost/): el presupuesto contra el que se miden estas
  ejecuciones, y las tres órdenes para medirlo tú.
- [Límites de la evidencia](https://docs.jmrp.io/mikroscope/es/cost/limits/): lo que `/metrics` puede y no puede
  recuperar a cualquiera de estas cadencias.
- [Probado en](https://docs.jmrp.io/mikroscope/es/about/status/#campaigns): las dos campañas de cadencias y todas las
  demás medidas que hay detrás de estas páginas.