Mida el comportamiento de CPU, memoria e IRQ.

Jitter Tools 1.3.0 proporciona tres herramientas independientes de línea de comandos para Linux. CPUJitter observa intervalos sin ejecución en una CPU. MEMjitter mide operaciones de memoria declaradas. IRQjitter observa eventos de IRQ y softirq del kernel mediante tracefs. Utilícelas por separado para responder a una pregunta de medición específica.

./cpujitter --version
./memjitter --version
./irqjitter --version

Los ejemplos siguientes se ejecutan desde una distribución binaria descomprimida. Tras compilar el código fuente, los mismos ejecutables están en ./bin/. Si están instalados en PATH, omita el prefijo ./. Los números de CPU son ejemplos, no una recomendación de ubicación para producción. Sustitúyalos por ID de CPU Linux permitidos y en línea en su host.

grep -E "Cpus_allowed_list|Mems_allowed_list" /proc/self/status
cat /sys/devices/system/cpu/online

./cpujitter -c 4 --duration 10

./memjitter -c 4 --duration 10

sudo ./irqjitter -c 1 --duration 10

Ejecute estos ejemplos uno por uno. Las pruebas de CPU y memoria son cargas de trabajo activas. IRQjitter es pasivo en el sentido de que no genera tráfico de prueba, pero el trazado y la recolección siguen teniendo sobrecarga. CPU/MEM no requieren root, SMT desactivado, aislamiento de CPU, una CPU exclusiva ni HFTKernel. La recolección de IRQ requiere acceso a un montaje tracefs existente y permiso para crear su propia instancia; sudo es una forma de proporcionar esos permisos.

Referencia del código fuente: S1, S2, S3, S7.

El archivo 1.3.0 suministrado contiene únicamente código fuente. No contiene ejecutables ELF listos para usar. Su calificación registrada no acredita una compilación Rust completada ni una ejecución real de IRQ. El punto de entrada admitido para el código fuente es test.sh; compila y prueba antes de publicar los binarios.

cd jitter-tools-1.3.0
./test.sh

Cargo se ejecuta sin conexión, con un conjunto fijo de dependencias y sin dependencias de registro. Las dependencias de prueba de Python pueden aprovisionarse en .test-env/ dentro del proyecto. Utilice --offline cuando el entorno ya esté preparado y deban desactivarse las descargas desde índices de paquetes.

./test.sh --offline --acceptance

Una vez superados todos los controles obligatorios, el flujo de trabajo publica bin/cpujitter, bin/memjitter, bin/irqjitter, bin/build-ok.json y un archivo de distribución estática versionado. Las referencias públicas al archivo utilizan el nombre canónico jitter-tools-1.3.0.tgz. El conjunto de la versión incluye BUILD.json, ELF.json, sumas de verificación, avisos y documentación. No trate una compilación del código fuente parcialmente completada como una distribución estática calificada.

./test.sh
./cpujitter --build-info
./memjitter --build-info
./irqjitter --build-info

El test.sh de la distribución binaria requiere sh, readelf, sha256sum y grep. No es el ejecutor de compilación del código fuente. Los ejecutables estáticos GNU no necesitan Rust, Python, un intérprete ELF ni bibliotecas compartidas adyacentes en tiempo de ejecución. Siguen necesitando un kernel Linux compatible con la arquitectura, las llamadas al sistema requeridas y /proc y /sys; IRQjitter también necesita tracefs. Las comprobaciones ELF son pruebas del empaquetado, no una garantía de precisión de medición ni de compatibilidad con todas las versiones del kernel.

Referencia del código fuente: S1, S2.

CPU/MEM también aceptan --cpu y --interval. IRQjitter 1.3.0 utiliza únicamente -c y -n para estos controles. Las tres herramientas aceptan valores cortos adjuntos como -c4 -n0.1. Utilice segundos decimales simples, por ejemplo 0.1, no 100ms, 1e-1 ni .1. Se rechazan las opciones repetidas.

./cpujitter -c4 -n0.1 --duration 5

./cpujitter -c 4 --raw --json --samples 1000 > cpu-raw.jsonl 2> cpu-raw.stderr.log

Los datos se envían a stdout y los diagnósticos a stderr. Redirigir stdout no selecciona el modo JSON ni el modo sin procesar. Utilice una duración finita o Ctrl+C para detener la ejecución. Un SIGINT/SIGTERM gestionado emite registros finales cuando el canal de salida sigue siendo utilizable y la limpieza tiene éxito. Una llamada al sistema bloqueada, SIGKILL, un host que ha fallado o una tubería cerrada impiden garantizar una detención inmediata o una salida final completa.

Referencia del código fuente: S2, S3, S9.

La métrica cpu_iteration_elapsed_ns es el tiempo transcurrido calibrado entre lecturas consecutivas del contador de hardware dentro de un lote de captura. Incluye la bifurcación del bucle, el almacenamiento de marcas de tiempo y la sobrecarga de lectura del contador. No es el recuento de ciclos del núcleo de CPU, una medición de entrega de interrupciones de dispositivos ni una clasificación directa de la causa de una pausa.

ordered es el modo predeterminado de lectura del contador; relaxed es una alternativa explícita con un contexto distinto. La calibración utiliza siete segmentos de al menos 50 ms frente a CLOCK_MONOTONIC_RAW, con una escala fija para la ejecución. No se resta ningún valor de referencia ni costo del contador. En x86, se requieren compatibilidad declarada con TSC invariable y acceso utilizable al contador; los contadores no compatibles se rechazan en lugar de sustituirse silenciosamente.

./cpujitter -c 4 -n 1 --duration 30
./cpujitter -c 4 -n 1 --duration 30 --counter-read relaxed

./cpujitter -c 4 -n 1 --duration 30 \
  --threshold cpu_iteration_elapsed_ns=5000

./cpujitter -c 4 --duration 30 --json > cpu.jsonl 2> cpu.stderr.log

Un lote tiene una marca de tiempo inicial y observaciones completadas. La captura está separada de los anclajes del reloj, la validación, la agregación y la salida. Un presupuesto cooperativo del contador comprueba aproximadamente 20 ms de trabajo de captura cada 256 registros; no recorta un retraso observado grande. ACTIVE% describe la parte de captura cubierta, no la utilización total de CPU. Las pausas que ocurren fuera de la captura no se observan para esta métrica.

Los nanosegundos se calculan con aritmética entera comprobada y redondeo al entero más cercano: (delta_ticks * 1000000000 + hz / 2) / hz. Las marcas de tiempo de los eventos para asignarlos a ventanas utilizan el mapeo acotado del contador a MONOTONIC. El valor y su intervalo de inicio/fin mapeado tienen propósitos distintos y no tienen por qué ser numéricamente idénticos. La precisión física desconocida permanece como null en el flujo.

Referencia del código fuente: S2, S3, S9.

Lecturas y lecturas/modificaciones/escrituras en memoria residente

Los valores predeterminados son resident, read, sequential, un mapeo de 16777216 bytes (16 MiB), un paso del tamaño de página del sistema, desplazamiento 0 y semilla 1. La preparación toca cada página base, precalienta el plan de acceso y comprueba la residencia inicial con mincore. Sin un bloqueo explícito, esa instantánea no garantiza una residencia continua.

./memjitter -c 4 --bytes 16777216 --duration 30
./memjitter -c 4 --operation rmw --pattern random --seed 1 --duration 30

read cronometra una carga volátil de byte. rmw cronometra una carga de byte, un incremento con desbordamiento modular y un almacenamiento; no es atómico ni mide la finalización globalmente visible del almacenamiento. El intervalo cronometrado incluye la sobrecarga de marcas de tiempo y barreras. El resultado no es la latency pura de DRAM.

Seguimiento dependiente de punteros

./memjitter -c 4 --operation chase --bytes 16777216 \
  --seed 1 --duration 30

--operation chase selecciona pointer-chase automáticamente salvo que el patrón sea explícito. Un patrón explícito también debe ser pointer-chase. Otros patrones de memoria residente son sequential, random con reemplazo y permutation. La selección de direcciones y la gestión de registros quedan fuera de cada operación medida. Un mapeo de 16 MiB con pasos de una página en un host con páginas de 4096 bytes tiene 4096 posiciones muestreadas, no 16 MiB de datos leídos en cada pasada.

Escrituras de first-touch

./memjitter -c 4 --mode first-touch --reset remap \
  --bytes 16777216 --duration 30

./memjitter -c 4 --mode first-touch --reset madvise \
  --pattern permutation --seed 1 --duration 30

First-touch permite sequential o permutation, sin reemplazo dentro de una época. write es la única operación y no necesita especificarse. Tras cada remapeo/descarte exitoso, mincore debe confirmar que no hay páginas residentes antes de iniciar una nueva época. El trabajo de restablecimiento es tiempo de servicio excluido. La primera escritura de un byte no implica necesariamente un fallo de página independiente ni una asignación de página física, especialmente cuando THP respalda varios desplazamientos. Remap y madvise son experimentos diferentes.

Llamadas a la API de asignación

./memjitter -c 4 --mode alloc --bytes 65536 --duration 30
./memjitter -c 4 --mode alloc --operation mmap --samples 65 --json

Alloc crea como máximo un mapeo propio a la vez y lo desmapea antes de la siguiente llamada. Solo los intervalos mmap exitosos entran en el histograma. mmap establece un mapeo virtual, no la materialización física de todas las páginas. La envoltura C ABI/libc y el intervalo de marcas de tiempo siguen formando parte del valor. Este modo no implementa el antiguo alloc-cycle, la latency de malloc/calloc ni la generación automática de presión de memoria.

Opciones de distribución y modo

./memjitter -c 4 --mode first-touch --duration 30 \
  --threshold mem_first_touch_ns=20000

Alloc rechaza las opciones de patrón, paso, desplazamiento, semilla y restablecimiento, incluso cuando sus valores se parecen a los predeterminados. Ningún modo de memoria acepta --counter-read de CPUJitter. Mantenga la misma operación, patrón, bytes, paso, desplazamiento, semilla, restablecimiento y modo de salida al comparar resultados.

Referencia del código fuente: S2, S4, S5.

Los valores predeterminados son --lock none, --thp system, la política NUMA heredada y ninguna solicitud explícita de HugeTLB. La herramienta no reconfigura el sistema, amplía los límites de bloqueo, cambia la reserva de páginas enormes ni reintenta con una política menos estricta. Una solicitud explícita no compatible falla e indica el motivo.

./memjitter -c 4 --bytes 65536 --lock resident --duration 10

./memjitter -c 4 --mode first-touch --lock onfault \
  --reset remap --bytes 65536 --duration 10

./memjitter -c 4 --thp never --duration 10
./memjitter -c 4 --thp prefer --duration 10

./memjitter -c 4 --numa-node 0 --duration 10

./memjitter -c 4 --bytes 2097152 \
  --hugetlb-bytes 2097152 --duration 10

El bloqueo impide el intercambio a swap del mapeo mientras se mantiene; no coloca los datos permanentemente en la caché de CPU. Una llamada aceptada de indicación THP no demuestra que se usen páginas enormes. Leer la política NUMA configurada es distinto de observar la ubicación física de las páginas. Los ID NUMA son 0..4095 y deben estar permitidos por el host.

Un tamaño HugeTLB explícito debe ser una potencia de dos mayor que la página base del sistema operativo, de hasta 1 GiB, y dividir el tamaño del mapeo. Es incompatible con el bloqueo explícito o con indicaciones THP distintas de system. La preparación de memoria residente requiere que MADV_POPULATE_WRITE tenga éxito para ese rango. La reserva existente, las cuotas, los permisos y la operación necesaria del kernel deben admitir la solicitud; no se recurre a páginas ordinarias como alternativa.

La política solicitada, las operaciones exitosas y el estado observado del mapeo se registran por separado. Las observaciones iniciales aparecen en meta; las observaciones finales del mapeo se escriben en stderr antes de desmapear. La información no disponible o no atribuible permanece como null. Las instantáneas de archivos proc y las comprobaciones de políticas añaden trabajo de servicio, por lo que deben compararse ejecuciones con políticas equivalentes.

Referencia del código fuente: S2, S6.

IRQjitter utiliza un hilo lector en el espacio de usuario y su propia instancia tracefs. Los tracepoints de IRQ requeridos son irq_handler_entry, irq_handler_exit, softirq_raise, softirq_entry y softirq_exit. La instancia debe admitir el reloj de trazado mono. No monta tracefs, cambia sus permisos con chmod, modifica la afinidad IRQ/RSS, detiene irqbalance ni activa un backend alternativo.

grep " tracefs " /proc/mounts

sudo ./irqjitter -c 1 --tracefs /sys/kernel/tracing --duration 15

CPU del recolector frente a CPU observadas

sudo ./irqjitter -c 1 --target-cpus 4-7 --duration 30

Sin --target-cpus, se observan los eventos compatibles de todas las CPU en línea, incluida la CPU del recolector. Una lista de CPU como 2,4-7 restringe la recolección, no solo la presentación. La actividad de IRQ que se desplaza fuera del conjunto seleccionado queda fuera de la cobertura. La conexión en caliente de CPU se supervisa dentro del conjunto inicial de CPU posibles, y los cambios se notifican con información de cobertura.

Tres métricas de tiempo distintas

Una fuente de IRQ se identifica mediante la métrica, la CPU real, el número y el nombre de la fuente. Los recuentos describen observaciones completadas de manejadores, no interrupciones físicas ni paquetes. Los pares idénticos de número/nombre de fuente no demuestran una identidad persistente del dispositivo tras una reconfiguración. Un valor transcurrido de cero puede reflejar la resolución de las marcas de tiempo textuales de la traza, habitualmente del orden de microsegundos, y no un tiempo físico nulo.

Vista general, detalles y eventos sin procesar

sudo ./irqjitter -c 1 -n 1 --duration 30
sudo ./irqjitter -c 1 -n 1 --details --duration 30
sudo ./irqjitter -c 1 -n 1 --json --duration 30 > irq.jsonl 2> irq.stderr.log

sudo ./irqjitter -c 1 --target-cpus 4 --raw --json \
  --duration 2 > irq-raw.jsonl 2> irq-raw.stderr.log

--details solo es válido para ventanas compactas y no puede combinarse con --json ni --raw. JSON ya conserva los registros de ventanas por CPU/fuente. Esta versión no incluye un modo timerlat ni un backend eBPF. La softirq TIMER real sigue siendo observable.

Observaciones opcionales de trabajo/presupuesto de NAPI

sudo ./irqjitter -c 1 --napi --duration 15
sudo ./irqjitter -c 1 --napi --details --duration 15

--napi requiere un tracepoint napi:napi_poll compatible. La métrica es napi_poll_work, con unidad work, no nanosegundos. Informa del valor de trabajo devuelto y del presupuesto. at_budget requiere un presupuesto positivo y un trabajo igual al presupuesto; over_budget requiere un trabajo mayor que un presupuesto positivo. Ninguno demuestra por sí solo una acumulación de paquetes pendientes. No se proporcionan la duración de NAPI, la latency de IRQ a NAPI ni un ID de cola de hardware inferido.

Controles de ventanas y recursos

sudo ./irqjitter -c 1 --target-cpus 4-7 -n 1 \
  --threshold 10000 --duration 30

Las muestras completadas tardíamente se notifican como tardías y no se trasladan a una ventana posterior ni se utilizan para reescribir la salida anterior. Una salida lenta puede retrasar la lectura de trazas y provocar pérdidas en los búferes del kernel. El recolector comprueba los controles y las estadísticas de los búferes, pero ni las lecturas vacías ni la ausencia de avisos de pérdida demuestran una cobertura completa. La instrumentación de trazas también se ejecuta en las CPU de los eventos, no solo en la CPU del recolector.

Referencia del código fuente: S2, S7, S8.

Columnas compactas de CPU/MEM

TIME(s) CPU COUNT MIN AVG P99<= P99.9<= MAX ACTIVE% LOSS QUALITY PART

Un umbral de tiempo añade un sufijo como >5000=N, donde N es el recuento estrictamente superior al límite. Una población vacía tiene COUNT=0 y estadísticas NA, no latency cero. --details de IRQ añade METRIC, SOURCE, UNIT y los campos específicos de NAPI BUDGET_MAX, AT_BUDGET y OVER_BUDGET; los valores no aplicables son NA.

Columnas de la vista general de IRQ

TIME(s) IRQ_N IRQ_P99<= IRQ_MAX SOFT_N SOFT_P99<= SOFT_MAX WAIT_N WAIT_P99<= WAIT_MAX PAIR_GAPS LATE BUFFER OTHER PART

IRQ, SOFT y WAIT son poblaciones separadas. Cada una combina histogramas de fuentes compatibles de las CPU observadas para esa métrica y ventana; los percentiles se recalculan a partir de los recuentos agrupados de los intervalos, no mediante el promedio de percentiles de las fuentes.

Por ejemplo, softirq_entry_without_observed_raise incrementa los diagnósticos de emparejamiento. No demuestra un desbordamiento del búfer circular de trazas, y todavía puede conservarse una duración válida de entrada/salida posterior. Las estadísticas de los búferes y los marcadores textuales de pérdida pueden solaparse; no los sume para inventar un recuento total de pérdidas.

Resúmenes al final de la ejecución

La salida compacta imprime # SUMMARY, filas # TOTAL y un estado de finalización después de la última ventana, incluida la ventana parcial final. CPU/MEM y los detalles de IRQ resumen cada serie; la vista general de IRQ genera totales de tiempo agrupados separados y totales opcionales de trabajo NAPI. El resumen de la vista general de IRQ incluye MAX_CPU y MAX_SOURCE, de modo que el mayor evento observado conserva su fuente.

Los totales utilizan recuentos y sumas exactos de ventanas comunicadas por completo, media ponderada, extremos e intervalos del histograma combinados. No son promedios de medias ni de percentiles de ventanas. scope=reported_windows excluye las muestras no comunicadas y tardías. Una fuente asociada a un máximo es una identidad de observación, no una causa raíz demostrada.

JSON Lines para automatización

Utilice --json para conservar los metadatos, las ventanas por serie, los motivos de calidad, los registros de pérdidas/intervalos sin cobertura y el registro terminal de finalización. Utilice --raw --json para muestras individuales. El texto de resumen compacto no se añade a JSON. Los valores enteros grandes, como nanosegundos, recuentos y sumas, son cadenas decimales; analícelos como enteros, no como números de coma flotante. Un valor null es desconocido, no cero.

jq 'select(.type == "meta")' cpu.jsonl
jq 'select(.type == "end") | {execution, exit_code, quality, cleanup}' cpu.jsonl
jq 'select(.type == "window") | {series, stats, coverage}' cpu.jsonl

El registro de finalización separa execution, la calidad y cleanup.confirmed. observations_aggregated es importante para el modo de ventanas; un observations_emitted de cero no significa que no se hayan recopilado datos si los valores se agregaron en ventanas. Conserve el archivo completo y stderr, en lugar de solo líneas de ventanas seleccionadas.

Referencia del código fuente: S8, S9.

Estos son los códigos documentados de la herramienta, no una garantía sobre cada shell, envoltura de tiempo de espera o señal fatal. Conserve los estados distintos de cero; evite añadir || true para que un resultado parezca exitoso. Una tubería cerrada por head puede impedir los registros finales. --samples o --duration es la forma admitida de limitar una captura.

out="jitter-run-$(date -u +%Y%m%dT%H%M%SZ)"
mkdir "$out"
./cpujitter --build-info > "$out/build-info.json"

if ./cpujitter -c 4 -n 1 --duration 30 --json \
    > "$out/cpu.jsonl" 2> "$out/cpu.stderr.log"; then
    rc=0
else
    rc=$?
fi
printf "%s\n" "$rc" > "$out/exit-code.txt"
printf "Saved %s, exit code %s\n" "$out" "$rc"

case "$rc" in
  0) echo "Completed; inspect the end record." ;;
  3) echo "Partial/unqualified; inspect quality and cleanup before comparing." ;;
  *) echo "Run did not complete normally; inspect diagnostics." >&2 ;;
esac

Compare ejecuciones equivalentes

Para comparar el kernel estándar con HFTKernel, utilice la misma compilación del ejecutable, función de CPU, modo de memoria, operación, patrón, tamaño, semilla, política de restablecimiento, políticas explícitas de memoria, modo de lectura del contador, lote, destino de salida, tamaño de ventana y duración. Conserve los metadatos del kernel, la topología y el planificador de cada ejecución. Cambie la variable prevista en lugar de cambiar al mismo tiempo la definición de la medición.

Ejecute cada experimento por separado. Esta versión permite lanzar dos herramientas activas en la misma CPU, pero entonces las ejecuciones interfieren entre sí y no constituyen referencias independientes. Mantenga el trazado de diagnóstico separado de la medición A/B principal cuando el objetivo sea evitar introducir una carga de trazado diferente en solo una de las partes.

Compare conjuntamente los recuentos, las distribuciones, los máximos, las superaciones de umbral, la cobertura y la calidad. No promedie valores p99 entre ejecuciones o ventanas. Un total compacto de toda la ejecución agrupa los histogramas comunicados dentro de esa ejecución; un análisis exacto de poblaciones entre ejecuciones requiere conservar datos subyacentes compatibles. La CLI 3.x de CPU/MEM y sus poblaciones de medición no son intercambiables con los perfiles de pruebas 2.x anteriores ya publicados en el sitio de HFTKernel.

Referencia del código fuente: S1, S3, S6, S9.

El cierre ordenado de IRQ detiene el registro, vacía los datos dentro de límites definidos, desactiva los eventos propios, cierra los descriptores, elimina únicamente su propia instancia y restaura la afinidad. Un fallo gestionado sigue siendo un fallo aunque la limpieza posterior libere los recursos. SIGKILL y los fallos del host no permiten garantizar la eliminación completa de la instancia.

Referencia del código fuente: S2, S3, S6, S7, S8, S9.

Esta guía se deriva del código fuente, los analizadores de CLI y los contratos de medición suministrados con Jitter Tools 1.3.0. No certifica la precisión de las mediciones de tiempo en ejecución ni la compatibilidad con todas las distribuciones. Las rutas de archivos de código fuente que se indican a continuación son relativas al archivo de código fuente.

Archivo de código fuente: jitter-tools-1.3.0.tgz
SHA-256: 39f803db80f8e598af67fa93171b0c0ead0c6350d2911bc9368b639cdee746ec