CPU-, Speicher- und IRQ-Verhalten messen.

Jitter Tools 1.3.0 bietet drei eigenständige Linux-Befehlszeilenwerkzeuge. CPUJitter beobachtet Ausführungslücken auf einer CPU. MEMjitter misst definierte Speicheroperationen. IRQjitter beobachtet Kernel-IRQ- und softirq-Ereignisse über tracefs. Verwenden Sie sie einzeln, um eine konkrete Messfrage zu beantworten.

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

Die folgenden Beispiele laufen aus einer entpackten Binärdistribution. Nach einem Quellcode-Build liegen dieselben ausführbaren Dateien in ./bin/. Wenn sie über PATH erreichbar sind, lassen Sie das Präfix ./ weg. CPU-Nummern sind Beispiele, keine Platzierungsempfehlung für den Produktivbetrieb. Ersetzen Sie sie durch zulässige, aktive Linux-CPU-IDs auf Ihrem 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

Führen Sie diese Beispiele einzeln aus. CPU- und Speichertests sind aktive Arbeitslasten. IRQjitter ist insofern passiv, als es keinen Testverkehr erzeugt, dennoch verursachen Tracing und Erfassung Overhead. CPU/MEM erfordern weder root, deaktiviertes SMT, CPU-Isolation, eine exklusive CPU noch HFTKernel. IRQ-Erfassung benötigt Zugriff auf einen bestehenden tracefs-Mount und die Berechtigung, eine eigene Instanz zu erstellen; sudo ist eine Möglichkeit, diese Berechtigungen zu erteilen.

Quellcodereferenz: S1, S2, S3, S7.

Das bereitgestellte 1.3.0-Archiv enthält ausschließlich Quellcode. Es enthält keine direkt ausführbaren ELF-Dateien. Die dokumentierte Qualifizierung belegt weder einen abgeschlossenen Rust-Build noch einen realen IRQ-Durchlauf. Der unterstützte Einstiegspunkt für den Quellcode ist test.sh; er erstellt und testet, bevor Binärdateien veröffentlicht werden.

cd jitter-tools-1.3.0
./test.sh

Cargo läuft offline mit einem gesperrten Abhängigkeitssatz und ohne Registry-Abhängigkeiten. Python-Testabhängigkeiten können in .test-env/ innerhalb des Projekts eingerichtet werden. Verwenden Sie --offline, wenn die Umgebung bereits vorbereitet ist und Downloads aus Paketindizes deaktiviert werden müssen.

./test.sh --offline --acceptance

Nach erfolgreichem Abschluss aller erforderlichen Prüfungen veröffentlicht der Ablauf bin/cpujitter, bin/memjitter, bin/irqjitter, bin/build-ok.json und ein versioniertes statisches Release-Archiv. Öffentliche Archivverweise verwenden den kanonischen Namen jitter-tools-1.3.0.tgz. Das Versionspaket enthält BUILD.json, ELF.json, Prüfsummen, Hinweise und Dokumentation. Betrachten Sie einen teilweise abgeschlossenen Quellcode-Build nicht als qualifizierte statische Distribution.

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

Das test.sh der Binärdistribution benötigt sh, readelf, sha256sum und grep. Es ist nicht das Build-Skript für den Quellcode. GNU-static-Programme benötigen zur Laufzeit weder Rust, Python, einen ELF-Interpreter noch benachbarte gemeinsam genutzte Bibliotheken. Sie benötigen weiterhin einen architekturkompatiblen Linux-Kernel, die erforderlichen Systemaufrufe sowie /proc und /sys; IRQjitter benötigt zusätzlich tracefs. ELF-Prüfungen sind Paketierungsnachweise, keine Garantie für Messgenauigkeit oder Unterstützung auf jeder Kernel-Version.

Quellcodereferenz: S1, S2.

CPU/MEM akzeptieren auch --cpu und --interval. IRQjitter 1.3.0 verwendet für diese Einstellungen nur -c und -n. Alle drei akzeptieren angehängte Kurzwerte wie -c4 -n0.1. Verwenden Sie einfache Dezimalsekunden, zum Beispiel 0.1, nicht 100ms, 1e-1 oder .1. Wiederholte Optionen werden abgelehnt.

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

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

Daten gehen an stdout und Diagnosemeldungen an stderr. Eine Umleitung von stdout wählt weder JSON- noch Rohmodus. Verwenden Sie eine begrenzte Dauer oder Ctrl+C zum Stoppen. Ein behandeltes SIGINT/SIGTERM gibt Abschlussdatensätze aus, wenn der Ausgabekanal nutzbar bleibt und die Bereinigung gelingt. Ein blockierter Systemaufruf, SIGKILL, Hostausfall oder eine geschlossene Pipe verhindern jede Garantie für sofortiges Stoppen oder vollständige Abschlussausgabe.

Quellcodereferenz: S2, S3, S9.

Die Metrik cpu_iteration_elapsed_ns ist die kalibrierte verstrichene Zeit zwischen aufeinanderfolgenden Hardwarezähler-Lesezugriffen innerhalb eines Erfassungsblocks. Sie umfasst Schleifenverzweigung, Zeitstempelspeicherung und Zählerlese-Overhead. Sie ist weder die Anzahl der CPU-Kerntakte noch eine Messung der Geräte-Interrupt-Zustellung oder eine direkte Klassifikation der Pausenursache.

ordered ist der Standardmodus für Zählerlesezugriffe; relaxed ist eine explizite Alternative mit eigenem Kontext. Die Kalibrierung nutzt sieben Segmente von mindestens 50 ms gegen CLOCK_MONOTONIC_RAW, mit festem Skalierungsfaktor für den Durchlauf. Weder Baseline noch Zählerkosten werden abgezogen. Auf x86 sind deklarierte invariant-TSC-Unterstützung und nutzbarer Zählerzugriff erforderlich; nicht unterstützte Zähler werden abgelehnt statt stillschweigend ersetzt.

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

Ein Block enthält einen Ausgangszeitstempel und abgeschlossene Beobachtungen. Die Erfassung ist von Zeitankern, Validierung, Aggregation und Ausgabe getrennt. Ein kooperatives Zählerbudget prüft alle 256 Datensätze auf ungefähr 20 ms Erfassungsarbeit; es schneidet keine große beobachtete Verzögerung ab. ACTIVE% beschreibt den abgedeckten Erfassungsanteil, nicht die gesamte CPU-Auslastung. Pausen außerhalb der Erfassung bleiben für diese Metrik unbeobachtet.

Nanosekunden werden mit geprüfter Ganzzahlarithmetik und Rundung auf den nächsten Wert berechnet: (delta_ticks * 1000000000 + hz / 2) / hz. Ereigniszeitstempel für die Fensterzuordnung verwenden die eingeklammerte Counter-to-MONOTONIC-Abbildung. Der Wert und sein abgebildetes Start-/Endintervall dienen unterschiedlichen Zwecken und müssen nicht numerisch identisch sein. Unbekannte physische Genauigkeit bleibt im Datenstrom null.

Quellcodereferenz: S2, S3, S9.

Residente Lesezugriffe und Lesen/Ändern/Schreiben

Standard sind resident, read, sequential, eine Abbildung von 16777216 Byte (16 MiB), eine Schrittweite in Systemseitengröße, Offset 0 und Seed 1. Die Vorbereitung berührt jede Basisseite, wärmt den Zugriffsplan auf und prüft die anfängliche Residenz mit mincore. Ohne explizite Sperre ist diese Momentaufnahme keine Zusage fortdauernder Residenz.

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

read misst einen flüchtigen Byte-Lesezugriff. rmw misst Byte-Lesen, Inkrementieren mit Überlauf und Speichern; es ist nicht atomar und misst nicht den global sichtbaren Abschluss des Schreibzugriffs. Die Messklammer enthält Zeitstempel-/Fence-Overhead. Das Ergebnis ist keine reine DRAM-latency.

Abhängiges pointer chase

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

--operation chase wählt automatisch pointer-chase, sofern kein Muster explizit angegeben wurde. Ein explizites Muster muss ebenfalls pointer-chase sein. Weitere residente Muster sind sequential, random mit Zurücklegen und permutation. Adressauswahl und Verwaltung liegen außerhalb jeder gemessenen Operation. Eine seitenweise durchlaufene 16 MiB-Abbildung auf einem Host mit 4096-Byte-Seiten hat 4096 abgetastete Positionen; pro Durchlauf werden nicht 16 MiB Nutzdaten gelesen.

First-touch-Schreibzugriffe

./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 erlaubt sequential oder permutation, ohne Zurücklegen innerhalb einer Epoche. write ist die einzige Operation und muss nicht angegeben werden. Nach jedem erfolgreichen Remap/Discard muss mincore bestätigen, dass keine Seiten resident sind, bevor eine neue Epoche beginnt. Reset-Arbeit ist ausgeschlossene Servicezeit. Ein erster Byte-Schreibzugriff ist nicht zwingend ein eigener Seitenfehler oder eine physische Seitenallokation, besonders wenn THP mehrere Offsets hinterlegt. Remap und madvise sind unterschiedliche Experimente.

Allokations-API-Aufrufe

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

Alloc erstellt jeweils höchstens eine eigene Abbildung und hebt sie vor dem nächsten Aufruf auf. Nur erfolgreiche mmap-Intervalle gehen in das Histogramm ein. mmap richtet eine virtuelle Abbildung ein, keine physische Belegung jeder Seite. Der C-ABI-/libc-Wrapper und die Zeitstempelklammer bleiben Teil des Werts. Der frühere alloc-cycle, malloc-/calloc-latency und automatische Speicherdruckerzeugung werden von diesem Modus nicht implementiert.

Layout- und Modusoptionen

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

Alloc lehnt Optionen für Muster, Schrittweite, Offset, Seed und Reset ab, selbst wenn ihre Werte den Standards ähneln. Kein Speichermodus akzeptiert CPUJitters --counter-read. Behalten Sie für Ergebnisvergleiche dieselbe Operation, dasselbe Muster, dieselbe Bytezahl, Schrittweite, Offset, Seed, Reset und denselben Ausgabemodus bei.

Quellcodereferenz: S2, S4, S5.

Standard sind --lock none, --thp system, geerbte NUMA-Richtlinie und keine explizite HugeTLB-Anforderung. Das Werkzeug konfiguriert das System nicht um, erhöht keine Sperrgrenzen, ändert keinen Huge-Page-Pool und versucht es nicht mit einer schwächeren Richtlinie erneut. Eine explizite nicht unterstützte Anforderung scheitert mit Begründung.

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

Eine Sperre verhindert das Auslagern der Abbildung, solange sie gehalten wird; sie hält Daten nicht dauerhaft im CPU-Cache. Ein akzeptierter THP-Hinweisaufruf beweist keine Huge-Page-Hinterlegung. Das Zurücklesen der NUMA-Richtlinie unterscheidet sich von der beobachteten physischen Seitenplatzierung. NUMA-IDs liegen bei 0..4095 und müssen vom Host erlaubt sein.

Eine explizite HugeTLB-Größe muss eine Zweierpotenz größer als die Basis-Seitengröße des Betriebssystems sein, höchstens 1 GiB betragen und die Abbildungsgröße teilen. Sie ist nicht mit expliziter Sperrung oder THP-Hinweisen außer system kompatibel. Residente Vorbereitung erfordert erfolgreiches MADV_POPULATE_WRITE für diesen Bereich. Bestehender Pool, Quoten, Berechtigungen und erforderliche Kernel-Operation müssen die Anforderung unterstützen; es gibt keinen Rückfall auf gewöhnliche Seiten.

Angeforderte Richtlinie, erfolgreiche Operationen und beobachteter Abbildungszustand werden getrennt aufgezeichnet. Anfängliche Beobachtungen erscheinen in meta; abschließende Abbildungsbeobachtungen werden vor dem Aufheben an stderr geschrieben. Nicht verfügbare oder nicht zuordenbare Informationen bleiben null. Proc-Datei-Momentaufnahmen und Richtlinienprüfungen verursachen zusätzliche Servicearbeit; vergleichen Sie daher Durchläufe mit übereinstimmenden Richtlinien.

Quellcodereferenz: S2, S6.

IRQjitter verwendet einen Userspace-Lesethread und eine eigene tracefs-Instanz. Erforderliche IRQ-Tracepoints sind irq_handler_entry, irq_handler_exit, softirq_raise, softirq_entry und softirq_exit. Die Instanz muss die Trace-Uhr mono unterstützen. Es mountet tracefs nicht, ändert dessen Rechte nicht per chmod, ändert keine IRQ-/RSS-Affinität, stoppt irqbalance nicht und aktiviert kein alternatives Backend.

grep " tracefs " /proc/mounts

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

Collector-CPU und beobachtete CPUs

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

Ohne --target-cpus werden unterstützte Ereignisse auf allen aktiven CPUs beobachtet, einschließlich der Collector-CPU. Eine CPU-Liste wie 2,4-7 schränkt die Erfassung ein, nicht nur die Darstellung. IRQ-Aktivität, die den gewählten Satz verlässt, liegt außerhalb der Abdeckung. CPU-Hotplug wird innerhalb des anfänglichen Rahmens möglicher CPUs überwacht; Änderungen werden mit Abdeckungsinformationen gemeldet.

Drei unterschiedliche Zeitmetriken

Eine IRQ-Quelle wird durch Metrik, tatsächliche CPU, Quellennummer und Namen identifiziert. Zähler beschreiben abgeschlossene Handler-Beobachtungen, keine physischen Interrupts oder Pakete. Identische Quellennummer-/Namenspaare beweisen keine dauerhafte Geräteidentität über Neukonfigurationen hinweg. Ein Zeitwert von null kann die Auflösung textueller Trace-Zeitstempel widerspiegeln, meist im Mikrosekundenbereich, statt physisch null Zeit.

Übersicht, Details und Rohereignisse

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 ist nur für kompakte Fenster gültig und nicht mit --json oder --raw kombinierbar. JSON bewahrt bereits Fensterdatensätze je CPU/Quelle. Diese Version enthält weder timerlat-Modus noch eBPF-Backend. Der echte TIMER-softirq bleibt beobachtbar.

Optionale NAPI-Arbeits-/Budgetbeobachtungen

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

--napi erfordert einen unterstützten Tracepoint napi:napi_poll. Die Metrik ist napi_poll_work, Einheit work, nicht Nanosekunden. Sie meldet zurückgegebenen Arbeitswert und Budget. at_budget erfordert ein positives Budget und einen Arbeitswert gleich dem Budget; over_budget erfordert einen Arbeitswert größer als ein positives Budget. Keines von beiden beweist allein einen Paketrückstau. NAPI-Dauer, IRQ-zu-NAPI-latency und eine abgeleitete Hardware-Warteschlangen-ID werden nicht bereitgestellt.

Fenster- und Ressourceneinstellungen

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

Spät abgeschlossene Stichproben werden als verspätet gemeldet und weder in ein späteres Fenster verschoben noch zum Umschreiben alter Ausgabe verwendet. Langsame Ausgabe kann das Trace-Lesen verzögern und Kernel-Pufferverluste verursachen. Der Collector prüft Einstellungen und Pufferstatistiken, doch weder leere Lesezugriffe noch das Fehlen einer Verlustmeldung beweisen vollständige Abdeckung. Trace-Instrumentierung läuft auch auf Ereignis-CPUs, nicht nur auf der Collector-CPU.

Quellcodereferenz: S2, S7, S8.

Kompakte CPU/MEM-Spalten

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

Ein Zeitschwellenwert ergänzt ein Suffix wie >5000=N, wobei N die Anzahl streng oberhalb der Grenze ist. Eine leere Population hat COUNT=0 und NA-Statistiken, nicht null latency. IRQ --details ergänzt METRIC, SOURCE, UNIT und die NAPI-spezifischen Felder BUDGET_MAX, AT_BUDGET und OVER_BUDGET; nicht zutreffende Werte sind NA.

Spalten der IRQ-Übersicht

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 und WAIT sind getrennte Populationen. Jede vereint kompatible Quellhistogramme über die beobachteten CPUs für diese Metrik und dieses Fenster; Perzentile werden aus zusammengeführten Klassenanzahlen neu berechnet, nicht über Quellenperzentile gemittelt.

Zum Beispiel erhöht softirq_entry_without_observed_raise die Paarungsdiagnosezähler. Dies belegt keinen Trace-Ring-Überlauf, und eine gültige nachfolgende Eintritts-/Austrittsdauer kann weiterhin erhalten bleiben. Pufferstatistiken und textuelle Verlustmarkierungen können sich überschneiden; addieren Sie sie nicht zu einer erfundenen Gesamtverlustzahl.

Zusammenfassungen am Durchlaufende

Die kompakte Ausgabe druckt nach dem letzten Fenster einschließlich des letzten Teilfensters # SUMMARY, # TOTAL-Zeilen und einen Endstatus. CPU/MEM und IRQ-Details fassen jede Reihe zusammen; die IRQ-Übersicht erzeugt getrennte zusammengeführte Zeitsummen und optionale NAPI-Arbeitssummen. Die Zusammenfassung der IRQ-Übersicht enthält MAX_CPU und MAX_SOURCE, sodass das größte beobachtete Ereignis seine Quelle behält.

Gesamtergebnisse verwenden exakte Anzahlen und Summen vollständig gemeldeter Fenster, gewichteten Mittelwert, Extremwerte und zusammengeführte Histogrammklassen. Sie sind keine Mittelwerte von Fenstermittelwerten oder Perzentilen. scope=reported_windows schließt nicht gemeldete und verspätete Stichproben aus. Eine einem Maximum zugeordnete Quelle ist eine Beobachtungsidentität, keine nachgewiesene Grundursache.

JSON Lines für Automatisierung

Verwenden Sie --json, um Metadaten, Fenster je Reihe, Qualitätsgründe, Verlust-/Lückendatensätze und den abschließenden Enddatensatz zu behalten. Verwenden Sie --raw --json für Einzelstichproben. Kompakter Zusammenfassungstext wird nicht an JSON angehängt. Große Ganzzahlwerte wie Nanosekunden, Anzahlen und Summen sind Dezimalzeichenfolgen; parsen Sie sie als Ganzzahlen, nicht als Gleitkommazahlen. Ein null-Wert ist unbekannt, nicht null im numerischen Sinn.

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

Der Enddatensatz trennt execution, Qualität und cleanup.confirmed. observations_aggregated ist für den Fenstermodus wichtig; observations_emitted gleich null bedeutet nicht, dass keine Daten erfasst wurden, wenn Werte in Fenstern aggregiert wurden. Bewahren Sie die vollständige Datei und stderr auf, statt nur ausgewählte Fensterzeilen.

Quellcodereferenz: S8, S9.

Dies sind die dokumentierten Codes des Werkzeugs, keine Zusage für jede Shell, jeden Timeout-Wrapper oder jedes fatale Signal. Behalten Sie einen Status ungleich null bei; vermeiden Sie || true, um ein Ergebnis erfolgreich erscheinen zu lassen. Eine durch head geschlossene Pipe kann Abschlussdatensätze verhindern. --samples oder --duration ist der unterstützte Weg, eine Erfassung zu begrenzen.

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

Gleichartige Durchläufe vergleichen

Verwenden Sie für einen Vergleich zwischen Standardkernel und HFTKernel denselben Programm-Build, dieselbe CPU-Rolle, Speichermodus, Operation, Muster, Größe, Seed, Reset-Richtlinie, explizite Speicherrichtlinien, Zählerlesemodus, Blockgröße, Ausgabeziel, Fenstergröße und Dauer. Bewahren Sie Kernel-, Topologie- und Scheduler-Metadaten jedes Durchlaufs auf. Ändern Sie die beabsichtigte Variable, statt zugleich die Messdefinition zu ändern.

Führen Sie jedes Experiment separat aus. Diese Version erlaubt zwei aktive Werkzeuge auf derselben CPU, ihre Durchläufe beeinflussen sich dann jedoch gegenseitig und sind keine unabhängigen Baselines. Halten Sie diagnostisches Tracing von der primären A/B-Messung getrennt, wenn verhindert werden soll, dass nur auf einer Seite zusätzliche Trace-Last entsteht.

Vergleichen Sie Anzahlen, Verteilungen, Maxima, Schwellenüberschreitungen, Abdeckung und Qualität gemeinsam. Mitteln Sie p99-Werte nicht über Durchläufe oder Fenster. Ein kompaktes Gesamtergebnis führt gemeldete Histogramme innerhalb dieses Durchlaufs zusammen; exakte populationsbezogene Analysen über mehrere Durchläufe erfordern die Aufbewahrung kompatibler zugrunde liegender Daten. CLI und Messpopulationen von CPU/MEM 3.x sind nicht mit den älteren, bereits auf der HFTKernel-Website veröffentlichten 2.x-Benchmarkprofilen austauschbar.

Quellcodereferenz: S1, S3, S6, S9.

Geordnetes IRQ-Beenden stoppt die Aufzeichnung, leert innerhalb begrenzter Grenzen, deaktiviert eigene Ereignisse, schließt Deskriptoren, entfernt nur die eigene Instanz und stellt die Affinität wieder her. Ein behandelter Fehler bleibt ein Fehler, auch wenn spätere Bereinigung Ressourcen freigibt. Bei SIGKILL und Hostausfall ist eine vollständige Instanzentfernung nicht garantiert.

Quellcodereferenz: S2, S3, S6, S7, S8, S9.

Dieses Handbuch basiert auf dem bereitgestellten Jitter Tools 1.3.0-Quellcode, den CLI-Parsern und den Messverträgen. Es bestätigt weder die Genauigkeit realer Zeitmessungen noch die Kompatibilität mit jeder Distribution. Die folgenden Quelldateipfade sind relativ zum Quellarchiv.

Quellarchiv: jitter-tools-1.3.0.tgz
SHA-256: 39f803db80f8e598af67fa93171b0c0ead0c6350d2911bc9368b639cdee746ec