Misura il comportamento di CPU, memoria e IRQ.

Jitter Tools 1.3.0 fornisce tre strumenti autonomi a riga di comando per Linux. CPUJitter osserva gli intervalli di mancata esecuzione su una CPU. MEMjitter misura operazioni di memoria dichiarate. IRQjitter osserva eventi IRQ e softirq del kernel tramite tracefs. Usali separatamente per rispondere a una domanda di misurazione specifica.

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

Gli esempi seguenti vengono eseguiti da una distribuzione binaria estratta. Dopo una build dai sorgenti, gli stessi eseguibili si trovano in ./bin/. Se installati nel PATH, ometti il prefisso ./. I numeri CPU sono esempi, non raccomandazioni di collocazione per la produzione. Sostituiscili con ID CPU Linux consentiti e online sul tuo 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

Esegui questi esempi uno alla volta. I test CPU e memoria sono carichi di lavoro attivi. IRQjitter è passivo nel senso che non genera traffico di prova, ma tracciamento e raccolta comportano comunque overhead. CPU/MEM non richiedono root, SMT disabilitato, isolamento CPU, una CPU esclusiva o HFTKernel. La raccolta IRQ richiede accesso a un mount tracefs esistente e il permesso di creare una propria istanza; sudo è un modo per fornire questi permessi.

Riferimento ai sorgenti: S1, S2, S3, S7.

L'archivio 1.3.0 fornito contiene solo sorgenti. Non contiene eseguibili ELF pronti all'uso. La qualificazione registrata non attesta una build Rust completata o un'esecuzione IRQ reale. Il punto di ingresso supportato per i sorgenti è test.sh; compila e testa prima di pubblicare i binari.

cd jitter-tools-1.3.0
./test.sh

Cargo viene eseguito offline con un insieme di dipendenze bloccato e senza dipendenze da registry. Le dipendenze dei test Python possono essere predisposte in .test-env/ all'interno del progetto. Usa --offline quando l'ambiente è già pronto e i download dagli indici dei pacchetti devono essere disabilitati.

./test.sh --offline --acceptance

Dopo il superamento di tutti i controlli richiesti, il processo pubblica bin/cpujitter, bin/memjitter, bin/irqjitter, bin/build-ok.json e un archivio statico di rilascio con versione. I riferimenti pubblici all'archivio usano il nome canonico jitter-tools-1.3.0.tgz. Il bundle include BUILD.json, ELF.json, checksum, avvisi e documentazione. Non considerare una build dai sorgenti completata solo in parte come una distribuzione statica qualificata.

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

Il test.sh della distribuzione binaria richiede sh, readelf, sha256sum e grep. Non è il runner di compilazione dei sorgenti. Gli eseguibili GNU-static non richiedono Rust, Python, un interprete ELF o librerie condivise adiacenti durante l'esecuzione. Richiedono comunque un kernel Linux compatibile con l'architettura, le chiamate di sistema necessarie e /proc e /sys; IRQjitter richiede anche tracefs. Le verifiche ELF attestano il confezionamento, non garantiscono precisione delle misurazioni o supporto su ogni versione del kernel.

Riferimento ai sorgenti: S1, S2.

CPU/MEM accettano anche --cpu e --interval. IRQjitter 1.3.0 usa solo -c e -n per questi controlli. Tutti e tre accettano valori brevi uniti all'opzione come -c4 -n0.1. Usa secondi decimali semplici, per esempio 0.1, non 100ms, 1e-1 o .1. Le opzioni ripetute vengono rifiutate.

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

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

I dati vanno a stdout e la diagnostica a stderr. Reindirizzare stdout non seleziona la modalità JSON o grezza. Usa una durata limitata o Ctrl+C per interrompere. Un SIGINT/SIGTERM gestito emette i record finali quando il canale di output rimane utilizzabile e la pulizia riesce. Una chiamata di sistema bloccata, SIGKILL, un guasto dell'host o una pipe chiusa impediscono qualsiasi garanzia di arresto immediato o output finale completo.

Riferimento ai sorgenti: S2, S3, S9.

La metrica cpu_iteration_elapsed_ns è il tempo trascorso calibrato tra letture consecutive del contatore hardware in un batch di acquisizione. Include il ramo del ciclo, la memorizzazione del timestamp e l'overhead di lettura del contatore. Non è il numero di cicli del core CPU, una misura della consegna degli interrupt dei dispositivi o una classificazione diretta della causa di una pausa.

ordered è la modalità predefinita di lettura del contatore; relaxed è un'alternativa esplicita con un contesto distinto. La calibrazione usa sette segmenti di almeno 50 ms rispetto a CLOCK_MONOTONIC_RAW, con una scala fissa per l'esecuzione. Non vengono sottratti né il riferimento né il costo del contatore. Su x86 sono richiesti supporto invariant-TSC dichiarato e accesso utilizzabile al contatore; i contatori non supportati vengono rifiutati anziché sostituiti silenziosamente.

./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 batch contiene un timestamp iniziale e osservazioni completate. L'acquisizione è separata da ancoraggi temporali, validazione, aggregazione e output. Un budget cooperativo del contatore verifica circa 20 ms di lavoro di acquisizione ogni 256 record; non tronca un grande ritardo osservato. ACTIVE% descrive la porzione di acquisizione coperta, non l'utilizzo totale della CPU. Le pause al di fuori dell'acquisizione non vengono osservate da questa metrica.

I nanosecondi vengono calcolati con aritmetica intera verificata e arrotondamento al più vicino: (delta_ticks * 1000000000 + hz / 2) / hz. I timestamp degli eventi per l'assegnazione alle finestre usano la mappatura delimitata dal contatore a MONOTONIC. Il valore e il relativo intervallo iniziale/finale mappato hanno scopi diversi e non devono essere numericamente identici. La precisione fisica sconosciuta rimane null nel flusso.

Riferimento ai sorgenti: S2, S3, S9.

Letture residenti e lettura/modifica/scrittura

Le impostazioni predefinite sono resident, read, sequential, un mapping di 16777216 byte (16 MiB), un passo pari alla pagina di sistema, offset 0 e seed 1. La preparazione tocca ogni pagina base, riscalda il piano di accesso e controlla la residenza iniziale con mincore. Senza un blocco esplicito, questa istantanea non garantisce una residenza continua.

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

read misura un caricamento volatile di un byte. rmw misura caricamento di un byte, incremento con riavvolgimento e scrittura; non è atomico e non misura il completamento della scrittura visibile globalmente. L'intervallo cronometrato include l'overhead di timestamp/fence. Il risultato non è pura latency DRAM.

Pointer chase dipendente

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

--operation chase seleziona automaticamente pointer-chase se non viene esplicitato un pattern. Un pattern esplicito deve essere anch'esso pointer-chase. Gli altri pattern residenti sono sequential, random con reinserimento e permutation. Selezione degli indirizzi e contabilità sono esterne a ogni operazione misurata. Un mapping di 16 MiB con passo di una pagina su un host con pagine da 4096 byte ha 4096 posizioni campionate, non 16 MiB di dati letti a ogni passaggio.

Scritture 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 consente sequential o permutation, senza reinserimento all'interno di un'epoca. write è l'unica operazione e non deve essere specificata. Dopo ogni remap/scarto riuscito, mincore deve confermare l'assenza di pagine residenti prima che inizi una nuova epoca. Il lavoro di reset è tempo di servizio escluso. La prima scrittura di un byte non corrisponde necessariamente a un page fault separato o a un'allocazione fisica di pagina, soprattutto quando THP copre più offset. Remap e madvise sono esperimenti diversi.

Chiamate API di allocazione

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

Alloc crea al massimo un mapping di sua proprietà alla volta e lo smappa prima della chiamata successiva. Solo gli intervalli mmap riusciti entrano nell'istogramma. mmap stabilisce un mapping virtuale, non la popolazione fisica di ogni pagina. Il wrapper C ABI/libc e l'intervallo di timestamp rimangono parte del valore. Il precedente alloc-cycle, la latency malloc/calloc e la generazione automatica di pressione sulla memoria non sono implementati da questa modalità.

Opzioni di disposizione e modalità

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

Alloc rifiuta le opzioni pattern, stride, offset, seed e reset, anche quando i valori assomigliano ai predefiniti. Nessuna modalità di memoria accetta --counter-read di CPUJitter. Mantieni la stessa operazione, pattern, byte, passo, offset, seed, reset e modalità di output quando confronti i risultati.

Riferimento ai sorgenti: S2, S4, S5.

Le impostazioni predefinite sono --lock none, --thp system, politica NUMA ereditata e nessuna richiesta HugeTLB esplicita. Lo strumento non riconfigura il sistema, non aumenta i limiti di blocco, non modifica un pool di huge page e non riprova con una politica più debole. Una richiesta esplicita non supportata fallisce indicandone il 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

Il blocco impedisce lo swapping del mapping finché è mantenuto; non colloca permanentemente i dati nella cache CPU. Una chiamata di suggerimento THP accettata non dimostra il supporto tramite huge page. La rilettura della politica NUMA è distinta dalla collocazione fisica osservata delle pagine. Gli ID NUMA sono 0..4095 e devono essere consentiti dall'host.

Una dimensione HugeTLB esplicita deve essere una potenza di due maggiore della pagina base del sistema operativo, al massimo 1 GiB, e dividere la dimensione del mapping. È incompatibile con blocco esplicito o suggerimenti THP diversi da system. La preparazione residente richiede MADV_POPULATE_WRITE riuscito per quell'intervallo. Pool esistente, quote, permessi e operazione del kernel richiesta devono supportare la richiesta; non esiste un ripiego su pagine ordinarie.

Politica richiesta, operazioni riuscite e stato osservato del mapping vengono registrati separatamente. Le osservazioni iniziali compaiono in meta; quelle finali del mapping vengono scritte su stderr prima dello smappaggio. Le informazioni non disponibili o non attribuibili rimangono null. Istantanee dei file proc e verifiche delle politiche aggiungono lavoro di servizio; confronta quindi esecuzioni con politiche corrispondenti.

Riferimento ai sorgenti: S2, S6.

IRQjitter usa un thread di lettura userspace e una propria istanza tracefs. I tracepoint IRQ richiesti sono irq_handler_entry, irq_handler_exit, softirq_raise, softirq_entry e softirq_exit. L'istanza deve supportare il clock di tracciamento mono. Non monta tracefs, non ne modifica i permessi con chmod, non cambia l'affinità IRQ/RSS, non arresta irqbalance e non abilita un backend alternativo.

grep " tracefs " /proc/mounts

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

CPU del collector e CPU osservate

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

Senza --target-cpus, vengono osservati gli eventi supportati su tutte le CPU online, inclusa la CPU del collector. Un elenco CPU come 2,4-7 limita la raccolta, non solo la presentazione. L'attività IRQ che si sposta fuori dall'insieme selezionato è fuori copertura. L'hotplug CPU viene monitorato entro l'insieme iniziale delle CPU possibili e le modifiche vengono segnalate con informazioni sulla copertura.

Tre metriche temporali distinte

Una sorgente IRQ è identificata da metrica, CPU effettiva, numero e nome della sorgente. I conteggi descrivono osservazioni di handler completate, non interrupt fisici o pacchetti. Coppie identiche di numero/nome della sorgente non dimostrano un'identità persistente del dispositivo attraverso le riconfigurazioni. Un tempo trascorso pari a zero può riflettere la risoluzione dei timestamp testuali delle tracce, comunemente a livello di microsecondi, anziché un tempo fisico nullo.

Panoramica, dettagli ed eventi grezzi

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 è valido solo per finestre compatte e non può essere combinato con --json o --raw. JSON conserva già i record di finestra per CPU/sorgente. Questa versione non contiene una modalità timerlat o un backend eBPF. Il vero softirq TIMER rimane osservabile.

Osservazioni facoltative di lavoro/budget NAPI

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

--napi richiede un tracepoint napi:napi_poll supportato. La metrica è napi_poll_work, unità work, non nanosecondi. Riporta il valore di lavoro restituito e il budget. at_budget richiede un budget positivo con lavoro uguale al budget; over_budget richiede lavoro superiore a un budget positivo. Nessuno dei due dimostra da solo un arretrato di pacchetti. Non vengono forniti durata NAPI, latency da IRQ a NAPI o un ID di coda hardware dedotto.

Controlli delle finestre e delle risorse

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

I campioni completati in ritardo vengono segnalati come tardivi e non spostati in una finestra successiva né usati per riscrivere output precedente. Un output lento può ritardare la lettura delle tracce e causare perdite nei buffer del kernel. Il collector verifica controlli e statistiche dei buffer, ma né letture vuote né assenza di avvisi di perdita dimostrano una copertura completa. La strumentazione di tracciamento gira anche sulle CPU degli eventi, non solo sulla CPU del collector.

Riferimento ai sorgenti: S2, S7, S8.

Colonne compatte CPU/MEM

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

Una soglia temporale aggiunge un suffisso come >5000=N, dove N è il conteggio strettamente superiore al limite. Una popolazione vuota ha COUNT=0 e statistiche NA, non latency zero. IRQ --details aggiunge METRIC, SOURCE, UNIT e i campi specifici NAPI BUDGET_MAX, AT_BUDGET e OVER_BUDGET; i valori non applicabili sono NA.

Colonne della panoramica 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 e WAIT sono popolazioni separate. Ciascuna combina gli istogrammi compatibili delle sorgenti sulle CPU osservate per quella metrica e finestra; i percentili vengono ricalcolati dai conteggi delle classi raggruppate, non mediati tra i percentili delle sorgenti.

Per esempio, softirq_entry_without_observed_raise incrementa la diagnostica di abbinamento. Non dimostra un overflow del ring di tracciamento e una durata ingresso/uscita valida successiva può comunque essere conservata. Statistiche dei buffer e marcatori testuali di perdita possono sovrapporsi; non sommarli in un conteggio totale di perdite artificioso.

Riepiloghi di fine esecuzione

L'output compatto stampa # SUMMARY, righe # TOTAL e uno stato finale dopo l'ultima finestra, inclusa quella parziale finale. CPU/MEM e i dettagli IRQ riepilogano ogni serie; la panoramica IRQ produce totali temporali raggruppati separati e totali facoltativi del lavoro NAPI. Il riepilogo della panoramica IRQ include MAX_CPU e MAX_SOURCE, così l'evento massimo osservato mantiene la propria sorgente.

I totali usano conteggi e somme esatti delle finestre interamente riportate, media ponderata, estremi e classi di istogramma unite. Non sono medie delle medie o dei percentili delle finestre. scope=reported_windows esclude i campioni non riportati e tardivi. Una sorgente associata a un massimo è un'identità di osservazione, non una causa primaria dimostrata.

JSON Lines per l'automazione

Usa --json per conservare metadati, finestre per serie, motivi di qualità, record di perdite/interruzioni e record finale. Usa --raw --json per i singoli campioni. Il testo compatto dei riepiloghi non viene aggiunto a JSON. I valori interi ampi come nanosecondi, conteggi e somme sono stringhe decimali; interpretali come interi, non numeri in virgola mobile. Un valore null è sconosciuto, non zero.

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

Il record finale separa execution, qualità e cleanup.confirmed. observations_aggregated è importante per la modalità a finestre; observations_emitted uguale a zero non significa che non siano stati raccolti dati se i valori sono stati aggregati in finestre. Conserva il file completo e stderr, invece delle sole righe di finestra selezionate.

Riferimento ai sorgenti: S8, S9.

Questi sono i codici documentati dello strumento, non una promessa per ogni shell, wrapper di timeout o segnale fatale. Conserva uno stato diverso da zero; evita di aggiungere || true per far apparire riuscito un risultato. Una pipe chiusa da head può impedire i record finali. --samples o --duration è il modo supportato per limitare un'acquisizione.

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

Confronta esecuzioni equivalenti

Per un confronto tra kernel standard e HFTKernel, usa la stessa build eseguibile, ruolo CPU, modalità di memoria, operazione, pattern, dimensione, seed, politica di reset, politiche di memoria esplicite, modalità di lettura del contatore, batch, destinazione di output, dimensione della finestra e durata. Conserva i metadati di kernel, topologia e scheduler di ogni esecuzione. Modifica la variabile prevista invece di cambiare contemporaneamente la definizione della misurazione.

Esegui ogni esperimento separatamente. Questa versione consente di avviare due strumenti attivi sulla stessa CPU, ma le esecuzioni interferiscono e non costituiscono riferimenti indipendenti. Mantieni il tracciamento diagnostico separato dalla misurazione A/B principale quando l'obiettivo è evitare di introdurre un carico di tracciamento diverso su un solo lato.

Confronta insieme conteggi, distribuzioni, massimi, superamenti delle soglie, copertura e qualità. Non mediare i valori p99 tra esecuzioni o finestre. Un totale compatto dell'intera esecuzione raggruppa gli istogrammi riportati al suo interno; un'analisi precisa della popolazione tra esecuzioni richiede la conservazione di dati sottostanti compatibili. La CLI e le popolazioni di misurazione CPU/MEM 3.x non sono intercambiabili con i vecchi profili benchmark 2.x già pubblicati sul sito HFTKernel.

Riferimento ai sorgenti: S1, S3, S6, S9.

La chiusura IRQ ordinata arresta la registrazione, svuota entro limiti definiti, disabilita gli eventi propri, chiude i descrittori, rimuove solo la propria istanza e ripristina l'affinità. Un errore gestito rimane tale anche se la pulizia successiva libera le risorse. SIGKILL e un guasto dell'host non possono garantire la rimozione completa dell'istanza.

Riferimento ai sorgenti: S2, S3, S6, S7, S8, S9.

Questa guida deriva dai sorgenti forniti di Jitter Tools 1.3.0, dai parser CLI e dai contratti di misurazione. Non certifica la precisione delle misurazioni temporali reali né la compatibilità con ogni distribuzione. I percorsi dei sorgenti seguenti sono relativi all'archivio dei sorgenti.

Archivio dei sorgenti: jitter-tools-1.3.0.tgz
SHA-256: 39f803db80f8e598af67fa93171b0c0ead0c6350d2911bc9368b639cdee746ec