Skip to content

Conversation

@acooks
Copy link
Owner

@acooks acooks commented Dec 28, 2025

No description provided.

acooks and others added 2 commits December 28, 2025 10:31
The jt-sample thread (throughput measurement) had priority 2 while
jt-toptalk (packet processing) had priority 3. With SCHED_FIFO on the
same CPU core, expensive packet processing work could preempt the 1ms
sampling tick, causing gaps in throughput measurements.

Raise jt-sample priority to 4 (highest) so the sampling thread can
always preempt packet processing when needed. The 1ms tick has the
strictest timing requirement and should never be delayed.

New priority order:
- jt-sample: 4 (highest) - 1ms tick must not be delayed
- jt-toptalk: 3 - packet capture
- jt-intervals: 2 - interval computation
- jt-compute: 1 (lowest) - stats aggregation

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
Add compile-time option RT_CPU_TOPTALK to pin packet capture threads
(jt-toptalk, jt-intervals) to a different CPU core than the sampling
thread (jt-sample).

Default configuration:
- RT_CPU=0: sampling thread on CPU 0
- RT_CPU_TOPTALK=1: packet capture threads on CPU 1

This provides complete isolation between the 1ms sampling tick and
packet processing work, eliminating CPU contention on multi-core
systems (which is all modern systems).

For single-core systems (rare): make RT_CPU=0 RT_CPU_TOPTALK=0

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
@acooks acooks merged commit 6eef437 into master Dec 28, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants