In the world of 1 million TPS, the BIOS is often where the battle is won or lost. While C-states (CPU Power States) are fantastic for your electricity bill and laptop battery, they are the silent killers of deterministic, low-latency performance.

If you are modeling a system for high-frequency workloads, C-states introduce a "stochastic tax" that makes sub-millisecond consistency impossible.

1. What are C-States? (The "Sleepy" CPU)

C-states are power-saving modes that the CPU enters when it thinks it’s idle.

• C0: The CPU is fully powered and executing instructions (The Goal).

• C1/C1E: The clock is stopped, but the CPU can wake up almost instantly ($<1\mu s$).

• C3/C6/C7: Deep sleep. The cache is flushed, the voltage is lowered, and parts of the core are physically powered down.

2. The Impact: The "Wake-Up" Latency Penalty

At 1M TPS, a single transaction arrives every 1 microsecond. If your CPU has entered a deep C-state (like C6) to save power during a tiny lull in traffic, it can take 50 to 200 microseconds to "warm up" and start executing instructions again.

The Math of the Disaster

If your arrival rate ($\lambda$) is $1,000,000$ per second and your CPU takes $100\mu s$ to wake up:

1. The first transaction triggers the wakeup.

2. While the CPU is "waking up," 100 more transactions arrive and sit in the NIC or OS buffer.

3. By the time the CPU is at C0, it is already facing a massive Queueing Delay.

This creates the classic "Sawtooth" Latency Profile: most requests are fast, but every few seconds, a batch of requests experiences a massive spike (the wake-up penalty).

3. C-States and "The Latch Spinning" Connection

In our previous discussion on SMT and Latch Spinning, we noted that threads often "spin" to avoid sleeping.

• If C-states are ENABLED: When a thread finally stops spinning and calls a HLT (Halt) or MWAIT instruction to yield, the hardware may immediately drop that core into a deep C-state.

• The Result: When the lock is finally released, the waiter can't just start running; it has to wait for the hardware to ramp up voltage and clocks. This turns a $5\mu s$ lock contention into a $100\mu s$ system stall.

4. The Jitter Factor: Frequency Scaling (P-States)

C-states are often paired with P-states (SpeedStep/Turbo Boost). When a core wakes up from a C-state, it doesn't always jump to its max Turbo frequency immediately. It may start at a "base" frequency (e.g., 2.2GHz) and gradually ramp up to 4.0GHz as the load stays high.

• The Impact: Your first 10,000 transactions in a burst are processed slower than the next 10,000. This creates intra-query skew that is impossible to solve in software.

5. Summary: BIOS Tuning for 1M TPS

6. How to Model the "C-State Tax"

If you cannot disable C-states (e.g., in a shared cloud environment), you must model your system using a Bimodal Distribution:

1. Mode 1 (Hot): Service time $S_1$ (CPU is awake).

2. Mode 2 (Cold): Service time $S_1+\text{Wakeup Latency}$.

At 1M TPS, even a 0.1% chance of hitting Mode 2 will destroy your P99.99 latency targets.

The Architect's Verdict

For 1M TPS, you want your CPUs to be "Always On, Always Hot." This means disabling C-states in the BIOS or using the Linux kernel parameter intel_idle.max_cstate=0 and processor.max_cstate=0. You are trading power efficiency for determinism.