Mesurez le comportement du CPU, de la mémoire et des IRQ.

Jitter Tools 1.3.0 fournit trois outils Linux autonomes en ligne de commande. CPUJitter observe les interruptions d'exécution sur un CPU. MEMjitter mesure des opérations mémoire déclarées. IRQjitter observe les événements IRQ et softirq du noyau via tracefs. Utilisez-les séparément pour répondre à une question de mesure précise.

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

Les exemples ci-dessous s'exécutent depuis une distribution binaire décompressée. Après compilation des sources, les mêmes exécutables se trouvent dans ./bin/. S'ils sont installés dans PATH, omettez le préfixe ./. Les numéros de CPU sont des exemples, pas une recommandation de placement en production. Remplacez-les par des identifiants CPU Linux autorisés et actifs sur votre hôte.

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

Exécutez ces exemples un à la fois. Les tests CPU et mémoire sont des charges actives. IRQjitter est passif au sens où il ne génère pas de trafic de test, mais le traçage et la collecte ont un coût. CPU/MEM ne nécessitent ni root, ni SMT désactivé, ni isolation CPU, ni CPU exclusif, ni HFTKernel. La collecte IRQ nécessite l'accès à un montage tracefs existant et l'autorisation de créer sa propre instance ; sudo est une manière d'obtenir ces droits.

Référence source : S1, S2, S3, S7.

L'archive 1.3.0 fournie contient uniquement les sources, sans exécutables ELF prêts à l'emploi. Sa qualification consignée ne prouve pas une compilation Rust achevée ni une exécution IRQ réelle. Le point d'entrée source pris en charge est test.sh ; il compile et teste avant de publier les binaires.

cd jitter-tools-1.3.0
./test.sh

Cargo s'exécute hors ligne avec un jeu de dépendances verrouillé et sans dépendances de registre. Les dépendances de test Python peuvent être installées dans le répertoire local du projet .test-env/. Utilisez --offline lorsque l'environnement est déjà préparé et que les téléchargements depuis l'index de paquets doivent être désactivés.

./test.sh --offline --acceptance

Après réussite de tous les contrôles obligatoires, le processus publie bin/cpujitter, bin/memjitter, bin/irqjitter, bin/build-ok.json et une archive statique versionnée. Les références publiques de l'archive utilisent le nom canonique jitter-tools-1.3.0.tgz. L'ensemble inclut BUILD.json, ELF.json, les sommes de contrôle, les mentions et la documentation. Ne considérez pas une compilation partielle des sources comme une distribution statique qualifiée.

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

Le test.sh de la distribution binaire nécessite sh, readelf, sha256sum et grep. Ce n'est pas l'outil de compilation des sources. Les exécutables GNU statiques ne nécessitent ni Rust, ni Python, ni interpréteur ELF, ni bibliothèques partagées voisines à l'exécution. Ils requièrent toujours un noyau Linux d'architecture compatible, les appels système nécessaires, /proc et /sys ; IRQjitter requiert aussi tracefs. Les contrôles ELF prouvent la conformité des paquets, pas la précision des mesures ni la prise en charge de chaque version du noyau.

Référence source : S1, S2.

CPU/MEM acceptent aussi --cpu et --interval. IRQjitter 1.3.0 utilise uniquement -c et -n pour ces paramètres. Les trois acceptent les valeurs courtes attachées comme -c4 -n0.1. Utilisez des secondes décimales simples, par exemple 0.1, et non 100ms, 1e-1 ou .1. Les options répétées sont refusées.

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

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

Les données vont vers stdout et les diagnostics vers stderr. Rediriger stdout ne sélectionne ni JSON ni le mode brut. Utilisez une durée limitée ou Ctrl+C pour arrêter. Un SIGINT/SIGTERM traité émet les enregistrements finaux si le canal de sortie reste utilisable et si le nettoyage réussit. Un appel système bloqué, SIGKILL, une panne de l'hôte ou un tube fermé empêchent toute garantie d'arrêt immédiat ou de sortie finale complète.

Référence source : S2, S3, S9.

La métrique cpu_iteration_elapsed_ns est le temps écoulé calibré entre des lectures successives du compteur matériel dans un lot de capture. Elle inclut le branchement de boucle, le stockage des horodatages et le coût de lecture du compteur. Ce n'est ni le nombre de cycles du cœur CPU, ni une mesure de livraison des interruptions d'un périphérique, ni une classification directe de la cause d'une pause.

ordered est le mode de lecture du compteur par défaut ; relaxed est une alternative explicite avec un contexte distinct. La calibration utilise sept segments d'au moins 50 ms par rapport à CLOCK_MONOTONIC_RAW, avec une échelle fixe pour l'exécution. Aucune référence ni coût du compteur n'est soustrait. Sur x86, la prise en charge déclarée d'invariant-TSC et un accès utilisable au compteur sont requis ; les compteurs non pris en charge sont refusés sans remplacement silencieux.

./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 lot contient un horodatage initial et des observations terminées. La capture est séparée des points d'ancrage temporels, de la validation, de l'agrégation et de la sortie. Un budget coopératif du compteur vérifie environ 20 ms de capture toutes les 256 observations ; il ne tronque pas un long délai observé. ACTIVE% décrit la portion de capture couverte, pas l'utilisation totale du CPU. Les pauses hors capture ne sont pas observées par cette métrique.

Les nanosecondes sont calculées par arithmétique entière vérifiée avec arrondi au plus proche : (delta_ticks * 1000000000 + hz / 2) / hz. Les horodatages affectant les événements aux fenêtres utilisent le mappage compteur-MONOTONIC encadré par les points d'ancrage. La valeur et son intervalle début/fin mappé ont des fonctions différentes et ne sont pas nécessairement identiques numériquement. La précision physique inconnue reste null dans le flux.

Référence source : S2, S3, S9.

Lectures résidentes et lecture/modification/écriture

Les valeurs par défaut sont resident, read, sequential, un mappage de 16777216 octets (16 MiB), un pas de la taille d'une page système, un déplacement de 0 et une graine de 1. La préparation touche chaque page de base, réchauffe le plan d'accès et vérifie la résidence initiale avec mincore. Sans verrouillage explicite, cet instantané ne garantit pas le maintien de la résidence.

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

read chronomètre un chargement volatile d'un octet. rmw chronomètre un chargement d'octet, un incrément avec retour à zéro et une écriture ; il n'est pas atomique et ne mesure pas l'achèvement de l'écriture visible globalement. L'intervalle inclut le coût des horodatages/barrières. Le résultat n'est pas une latency DRAM pure.

Parcours dépendant de pointeurs

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

--operation chase sélectionne automatiquement pointer-chase, sauf si un motif est explicite. Un motif explicite doit également être pointer-chase. Les autres motifs résidents sont sequential, random avec remise et permutation. La sélection d'adresse et la gestion sont hors de chaque opération mesurée. Un mappage de 16 MiB avec un pas d'une page sur un hôte à pages de 4096 octets contient 4096 positions échantillonnées, pas 16 MiB de données lues à chaque passage.

Écritures 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 autorise sequential ou permutation, sans remise dans une époque. write est la seule opération et peut être omis. Après chaque remappage/abandon réussi, mincore doit confirmer l'absence de pages résidentes avant une nouvelle époque. La réinitialisation est du temps de service exclu. La première écriture d'un octet ne correspond pas nécessairement à un défaut de page ou à une allocation physique distincte, notamment lorsque THP couvre plusieurs déplacements. Remap et madvise sont des expériences différentes.

Appels API d'allocation

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

Alloc crée au plus un mappage lui appartenant à la fois et le supprime avant l'appel suivant. Seuls les intervalles mmap réussis entrent dans l'histogramme. mmap établit un mappage virtuel, sans peupler physiquement chaque page. L'enveloppe C ABI/libc et l'encadrement temporel restent inclus dans la valeur. L'ancien alloc-cycle, la latency malloc/calloc et la génération automatique de pression mémoire ne sont pas implémentés dans ce mode.

Options de disposition et de mode

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

Alloc refuse les options pattern, stride, offset, seed et reset, même si leurs valeurs ressemblent aux valeurs par défaut. Aucun mode mémoire n'accepte --counter-read de CPUJitter. Conservez les mêmes operation, pattern, bytes, stride, offset, seed, reset et mode de sortie pour comparer les résultats.

Référence source : S2, S4, S5.

Les valeurs par défaut sont --lock none, --thp system, la politique NUMA héritée et aucune demande HugeTLB explicite. L'outil ne reconfigure pas le système, n'augmente pas les limites de verrouillage, ne modifie pas un pool de grandes pages et ne réessaie pas avec une politique moins stricte. Une demande explicite non prise en charge échoue avec sa raison.

./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

Le verrouillage empêche le passage du mappage en swap tant qu'il est maintenu ; il ne garde pas définitivement les données dans le cache CPU. Un appel de conseil THP accepté ne prouve pas l'utilisation de grandes pages. La relecture de la politique NUMA diffère du placement physique observé. Les identifiants NUMA vont de 0..4095 et doivent être autorisés par l'hôte.

Une taille HugeTLB explicite doit être une puissance de deux supérieure à la page de base de l'OS, au plus 1 GiB, et diviser la taille du mappage. Elle est incompatible avec un verrouillage explicite ou un conseil THP autre que system. La préparation résidente nécessite un MADV_POPULATE_WRITE réussi sur cette plage. Le pool existant, les quotas, les autorisations et l'opération requise du noyau doivent permettre la demande ; aucun repli vers les pages ordinaires n'est effectué.

La politique demandée, les opérations réussies et l'état observé du mappage sont enregistrés séparément. Les observations initiales figurent dans meta ; les observations finales sont écrites sur stderr avant unmap. Les informations indisponibles ou non attribuables restent null. Les instantanés des fichiers proc et les vérifications de politique ajoutent du travail de service ; comparez donc des politiques identiques.

Référence source : S2, S6.

IRQjitter utilise un thread lecteur en espace utilisateur et sa propre instance tracefs. Les points de trace IRQ requis sont irq_handler_entry, irq_handler_exit, softirq_raise, softirq_entry et softirq_exit. L'instance doit prendre en charge l'horloge de trace mono. L'outil ne monte pas tracefs, ne change pas ses droits par chmod, ne modifie pas l'affinité IRQ/RSS, n'arrête pas irqbalance et n'active pas de moteur alternatif.

grep " tracefs " /proc/mounts

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

CPU du collecteur et CPU observés

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

Sans --target-cpus, les événements pris en charge sont observés sur tous les CPU actifs, y compris celui du collecteur. Une liste telle que 2,4-7 restreint la collecte, pas seulement l'affichage. L'activité IRQ déplacée hors de cet ensemble sort de la couverture. Le branchement à chaud des CPU est surveillé dans l'ensemble initial des CPU possibles, et ses changements sont signalés avec les informations de couverture.

Trois métriques temporelles distinctes

Une source IRQ est identifiée par la métrique, le CPU réel, le numéro et le nom de source. Les comptes décrivent les observations terminées des gestionnaires, pas les interruptions physiques ou les paquets. Des paires numéro/nom identiques ne prouvent pas une identité persistante du périphérique après reconfiguration. Une durée nulle peut refléter la résolution des horodatages textuels de trace, souvent à la microseconde, plutôt qu'un temps physique nul.

Aperçu, détails et événements bruts

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 est valable uniquement pour les fenêtres compactes et est incompatible avec --json ou --raw. JSON conserve déjà les fenêtres par CPU/source. Cette version ne contient ni mode timerlat ni moteur eBPF. Le véritable softirq TIMER reste observable.

Observations facultatives du travail/budget NAPI

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

--napi requiert un point de trace napi:napi_poll pris en charge. La métrique est napi_poll_work, unité work, pas des nanosecondes. Elle indique la valeur de travail retournée et le budget. at_budget exige un budget positif avec un travail égal au budget ; over_budget exige un travail supérieur à un budget positif. Aucun ne prouve à lui seul une accumulation de paquets. La durée NAPI, la latency IRQ-to-NAPI et un identifiant supposé de file matérielle ne sont pas fournis.

Paramètres des fenêtres et des ressources

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

Les échantillons terminés tardivement sont signalés comme tardifs, sans déplacement dans une fenêtre ultérieure ni réécriture des anciennes sorties. Une sortie lente peut retarder la lecture de trace et provoquer des pertes dans les tampons du noyau. Le collecteur vérifie les paramètres et statistiques des tampons, mais des lectures vides ou l'absence d'avis de perte ne prouvent pas une couverture complète. L'instrumentation s'exécute aussi sur les CPU des événements, pas seulement sur celui du collecteur.

Référence source : S2, S7, S8.

Colonnes compactes CPU/MEM

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

Un seuil temporel ajoute un suffixe comme >5000=N, où N est le nombre de valeurs strictement supérieures à la limite. Une population vide a COUNT=0 et des statistiques NA, pas une latency nulle. IRQ --details ajoute METRIC, SOURCE, UNIT et les champs NAPI BUDGET_MAX, AT_BUDGET et OVER_BUDGET ; les valeurs non applicables sont NA.

Colonnes de l'aperçu 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 et WAIT sont des populations distinctes. Chacune regroupe les histogrammes compatibles des sources sur les CPU observés pour cette métrique et cette fenêtre ; les percentiles sont recalculés à partir des comptes de classes regroupés, pas moyennés à partir des percentiles des sources.

Par exemple, softirq_entry_without_observed_raise incrémente les diagnostics d'appariement. Cela ne prouve pas un débordement de l'anneau de trace, et une durée entrée/sortie valide ultérieure peut être conservée. Les statistiques des tampons et les marqueurs textuels de perte peuvent se chevaucher ; ne les additionnez pas pour inventer un total de pertes.

Résumés de fin d'exécution

La sortie compacte affiche # SUMMARY, des lignes # TOTAL et un état final après la dernière fenêtre, y compris la fenêtre partielle finale. Les détails CPU/MEM et IRQ résument chaque série ; l'aperçu IRQ produit des totaux temporels regroupés distincts et, en option, des totaux de travail NAPI. Le résumé d'aperçu IRQ inclut MAX_CPU et MAX_SOURCE pour préserver la source du plus grand événement observé.

Les totaux utilisent les comptes et sommes exacts des fenêtres intégralement rapportées, une moyenne pondérée, les extrema et les classes d'histogramme fusionnées. Ce ne sont pas des moyennes de moyennes ou de percentiles de fenêtres. scope=reported_windows exclut les échantillons non rapportés et tardifs. La source liée à un maximum identifie une observation, pas une cause racine prouvée.

JSON Lines pour l'automatisation

Utilisez --json pour conserver les métadonnées, les fenêtres par série, les raisons de qualité, les enregistrements de pertes/ruptures et l'enregistrement final end. Utilisez --raw --json pour les échantillons individuels. Le texte du résumé compact n'est pas ajouté au JSON. Les grands entiers comme les nanosecondes, comptes et sommes sont des chaînes décimales ; analysez-les comme entiers, pas comme nombres flottants. Une valeur null est inconnue, pas nulle au sens numérique.

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

L'enregistrement final sépare execution, la qualité et cleanup.confirmed. observations_aggregated est important en mode fenêtres ; un observations_emitted nul ne signifie pas qu'aucune donnée n'a été collectée si les valeurs ont été agrégées en fenêtres. Conservez le fichier complet et stderr, pas seulement certaines lignes de fenêtres.

Référence source : S8, S9.

Ce sont les codes documentés de l'outil, pas une garantie pour chaque shell, enveloppe de délai ou signal fatal. Conservez les statuts non nuls ; n'ajoutez pas || true pour faire paraître un résultat réussi. Un tube fermé par head peut empêcher les enregistrements finaux. --samples ou --duration est la manière prise en charge de limiter une capture.

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

Comparez des exécutions équivalentes

Pour comparer un noyau standard à HFTKernel, utilisez la même compilation de l'exécutable, le même rôle CPU, mode mémoire, opération, motif, taille, graine, politique de réinitialisation, politiques mémoire explicites, mode de lecture du compteur, lot, destination de sortie, taille de fenêtre et durée. Conservez les métadonnées du noyau, de la topologie et de l'ordonnanceur de chaque exécution. Modifiez la variable visée sans changer simultanément la définition de la mesure.

Exécutez chaque expérience séparément. Cette version autorise deux outils actifs sur le même CPU, mais leurs exécutions interfèrent et ne constituent pas des références indépendantes. Séparez le traçage diagnostique de la mesure A/B principale lorsque l'objectif est d'éviter d'ajouter une charge de traçage différente d'un seul côté.

Comparez ensemble les comptes, distributions, maxima, dépassements de seuils, couverture et qualité. Ne moyennez pas les p99 entre exécutions ou fenêtres. Le total compact d'une exécution regroupe les histogrammes rapportés dans cette exécution ; une analyse exacte des populations entre exécutions exige de conserver des données sous-jacentes compatibles. Le CLI CPU/MEM 3.x et ses populations de mesure ne sont pas interchangeables avec les anciens profils de référence 2.x déjà publiés sur le site HFTKernel.

Référence source : S1, S3, S6, S9.

Un arrêt IRQ normal arrête l'enregistrement, vide dans des limites définies, désactive les événements de l'outil, ferme les descripteurs, supprime uniquement sa propre instance et rétablit l'affinité. Un échec traité reste un échec même si le nettoyage ultérieur libère les ressources. SIGKILL et une panne de l'hôte ne permettent pas de garantir la suppression complète de l'instance.

Référence source : S2, S3, S6, S7, S8, S9.

Ce guide repose sur le code source fourni de Jitter Tools 1.3.0, les analyseurs CLI et les contrats de mesure. Il ne certifie ni la précision temporelle en conditions réelles ni la compatibilité avec toutes les distributions. Les chemins ci-dessous sont relatifs à l'archive source.

Archive source: jitter-tools-1.3.0.tgz
SHA-256: 39f803db80f8e598af67fa93171b0c0ead0c6350d2911bc9368b639cdee746ec