How does cut-through switching reduce inter-node commit latency?
In the world of distributed databases and high-performance clusters (like Oracle RAC or SQL Server AG), the "Commit" is the finish line. But before that transaction is finalized, the nodes must agree, and the data must traverse the network.
In this microsecond race, the architecture of your network switch matters just as much as the speed of your NVMe drives. This is where Cut-Through Switching becomes the secret weapon for reducing inter-node latency.
To understand the benefit, we have to look at how a switch handles a packet:
Store-and-Forward (The Old Way): The switch waits to receive the entire packet (e.g., a 1.5KB or 9KB Jumbo Frame), stores it in its internal RAM, checks the CRC for errors, and then decides where to send it.
The Penalty: Latency is tied to packet size. A larger packet takes longer to "store," creating a linear delay.
Cut-Through (The Fast Way): The switch only reads the first few bytes (the MAC address header). As soon as it knows the destination, it starts streaming the packet out of the egress port—even while the rest of the packet is still arriving on the ingress port.
The Benefit: Latency is constant, regardless of packet size.
A database commit in a cluster isn't one message; it’s a volley of small, time-sensitive packets (Prepare, Acknowledge, Commit).
In a Store-and-Forward network, a 9KB Jumbo Frame (common in database interconnects) can add $10\mu\text{s} - 20\mu\text{s}$ of "dwell time" inside the switch. In a Cut-Through network (like Cisco Nexus or Arista 7000 series), that delay drops to $<500\text{ns}$.
The Result: When you multiply this by the multiple "hops" and "round-trips" required for a cluster commit, you save significant time on every single transaction.
Database Redo Logs are extremely sensitive to "jitter" (variance in latency). Store-and-forward switches can introduce variable delays if the switch CPU is busy checking CRCs on large background packets (like a backup).
The Cut-Through Benefit: Because the switch hardware (ASIC) starts forwarding almost instantly, the "Log Writer" (LGWR) experiences a highly predictable, deterministic path. This stabilizes your log file sync times.
| Packet Size | Store-and-Forward Delay | Cut-Through Delay |
| 64 Bytes (Small ACK) | $~5\mu\text{s}$ | $~0.5\mu\text{s}$ |
| 1500 Bytes (Standard) | $~15\mu\text{s}$ | $~0.5\mu\text{s}$ |
| 9000 Bytes (Jumbo) | $~80\mu\text{s}$ | $~0.5\mu\text{s}$ |
Note: In a Cut-Through environment, the switch is so fast that the "distance" of the fiber optic cable often becomes a larger factor than the switch itself!
There is one "catch" with Cut-Through switching: It cannot check for errors. Since the switch starts forwarding before the end of the packet (where the CRC footer lives), it will happily forward a "corrupt" packet.
In a Healthy Data Center: This is rarely an issue. Modern fiber optics have extremely low error rates.
The Database Safety Net: Even if the switch forwards a corrupt packet, the NIC or the Database Engine itself will catch the checksum error and request a retransmit. The speed gain is almost always worth the tiny risk of "bad" packets traveling one hop further.
To maximize the benefits for your database cluster:
Uniform Switching: Ensure your entire private interconnect path is Cut-Through. If you mix a Cut-Through switch with a Store-and-Forward switch, the "slowest link" defines your commit latency.
L1/L2 Proximity: Keep your RAC or cluster nodes on the same physical switch (Top-of-Rack) to avoid "Multi-Hop" delays, even if those hops are cut-through.
RDMA (RoCE/InfiniBand): Cut-through switching is the foundation of RDMA. Without it, the "Zero-Copy" benefits of RDMA would be negated by the "Store-and-Wait" delays of the switch.
Cut-Through switching turns the network from a "Post Office" (that sorts and stores mail) into a "Pipe" (that just flows). For high-frequency database commits, this reduction in "per-packet dwell time" is the difference between an application that feels "snappy" and one that feels "laggy." If your cluster is running on Gen 4 NVMe and 100Gbps NICs, make sure your switch isn't holding your data back for a CRC check it doesn't need.