How does interrupt coalescing tuning influence throughput vs latency tradeoff?
In a 1M TPS architecture, the Network Interface Card (NIC) is the front door. Every time a packet arrives, the NIC can either "ring the doorbell" (send an interrupt to the CPU) immediately or wait for more packets to arrive so it can hand them over in a single batch.
This mechanism is Interrupt Coalescing (IC), and it is the primary lever for balancing Throughput vs. Latency.
The CPU treats an interrupt as a high-priority "stop everything" command.
Low Coalescing (Immediate): The NIC interrupts the CPU for every packet.
Latency: Minimal. The CPU sees the data the microsecond it arrives.
Throughput: Poor. At 1M TPS, the CPU would spend 100% of its time performing Context Switches and ISR (Interrupt Service Routine) overhead, leaving zero cycles for actual transaction logic. This is known as an "Interrupt Storm."
High Coalescing (Batching): The NIC waits for $N$ microseconds or $M$ packets before firing an interrupt.
Latency: Increased. The first packet in the batch sits in the NIC buffer waiting for its "friends" to arrive.
Throughput: Maximal. The CPU wakes up once, processes a huge "burst" of packets in its cache, and returns to work.
When modeling 1M TPS, you aren't looking for a single value; you are looking for the Saturation Point.
If you set your coalescing timer to $50\mu s$, you are adding a forced "floor" to your minimum latency. For a high-frequency trading system, $50\mu s$ is an eternity. For a standard REST API, it’s negligible.
As you increase the batch size, your Instructions Per Cycle (IPC) improves because the CPU stays in the "packet processing" loop longer. This reduces "Instruction Cache" misses because the code for handling a packet stays "hot" in the L1 cache.
If your coalescing is tuned too low at 1M TPS, you hit Receive Side Livelock.
The Symptom: Your CPU usage is 100%, but your actual transaction throughput drops to near zero.
The Reason: The CPU is so busy acknowledging interrupts that it never has a "slice" of time long enough to actually execute the COMMIT logic or database code.
For high-scale systems, we use two main strategies to bypass the harsh tradeoff:
Modern Linux drivers use a hybrid approach. They start with interrupts, but under high load (like 1M TPS), they switch to Polling Mode. The CPU simply loops and checks the NIC for new data without waiting for an interrupt. This effectively "auto-tunes" coalescing based on load.
Most enterprise NICs (Intel, Mellanox) have an Adaptive-RX setting.
Low Traffic: It lowers coalescing to keep latency snappy.
High Traffic: It automatically raises coalescing to protect the CPU from melting.
| Workload Type | IC Setting | Typical Value | Priority |
| HFT / Ultra-Low Latency | Off / Minimal | $1\mu s$ or 0 | Latency is King |
| 1M TPS High Throughput | Moderate | $20\mu s - 50\mu s$ | Efficiency/Batching |
| Bulk Data Transfer | High | $100\mu s +$ | Throughput/CPU overhead |
At 1M TPS, Static Interrupt Coalescing is a trap. If you set it too high, your P99 latency suffers. If you set it too low, your system collapses under its own weight.
The Solution: Use Adaptive RX/TX coalescing combined with RSS (Receive Side Scaling) to spread those interrupts across multiple CPU cores. This prevents any single core from being "pinned" by the interrupt storm while others sit idle.