Cut-Through or Store-and-Forward: What a GPU Switch Latency Number Leaves Out

The decision is when forwarding can begin

A low switch-latency figure is useful only when the buyer knows which interval it describes. In a GPU Ethernet proposal, the immediate question is whether an offered forwarding path and its quoted timing match the traffic being compared. The mode name explains one mechanism inside that path.

Cisco's Nexus 9000 NX-OS 10.3(x) switching-mode chapter, updated June 26, 2024, distinguishes forwarding after destination details are available from waiting for the complete frame and its cyclic redundancy check (CRC). The former is cut-through; the latter is store-and-forward. The chapter also states that cut-through is unavailable on Nexus 9800. Support must therefore be established for the exact offered hardware and software.

Ethernet's Frame Check Sequence, or FCS, is a trailing field used for CRC error detection. Forwarding can already be underway when a cut-through device discovers that the completed frame fails that check. Earlier forwarding is not the same thing as completing the error check earlier.

References: [C1][C3]

Name the input and output events behind the number

Two reports can use the same time unit while starting their clocks at different events. Timing from the first input bit includes a different interval from timing only after the last input bit arrives. Ending at the first output bit also answers a different question from ending when the complete output frame has left.

RFC 1242, published in July 1991, makes this distinction explicit in its historical latency terminology. Section 3.8 uses different input-bit boundaries for its device categories and discusses a cut-through case with negative last-bit-in to first-bit-out latency. A benchmark name or a modern mode label is therefore insufficient: retain the actual boundary definition.

Cisco document 225840, updated May 7, 2026, identifies packet size, forwarding mode and enabled features as latency qualifications. Its stated equipment context is Nexus 9000 Cloud Scale with NX-OS 10.6(X). It also qualifies mirrored ingress/egress packet deltas as upper-bound estimates that can include mirroring and timestamping overhead.

For an offer comparison, have the supplier identify the input event, output event and locations covered. Establish whether the value describes one switch, a network path, a round trip or an application operation. The separate hardware-timestamp guide explains the clock relationship when timestamps come from different systems; changing clocks or capture locations cannot be resolved by a forwarding-mode label.

References: [R1][C2]

What 64 and 1,500 counted bytes actually tell you

Consider fictional comparison CT-01. Offer A highlights cut-through timing with a 64-byte size label. Offer B highlights store-and-forward timing with a 1,500-byte size label. Before ranking their latency figures, the buyer needs to know what each length counts and whether the timing boundaries and traffic conditions match. These are invented offers, not product specifications or measurements.

To isolate the arithmetic, invent an ideal bit pipe carrying exactly 100,000,000,000 bits per second. Count only a stipulated group of bytes, with eight bits per byte. Occupancy time is counted bits divided by that rate. For 64 counted bytes, 64 x 8 = 512 bits; 512 / 100,000,000,000 seconds equals 5.12 ns. For 1,500 counted bytes, 1,500 x 8 = 12,000 bits; the corresponding time is 120 ns.

These stripped quantities exclude every other framing byte, coding overhead, queue delay, ASIC processing, feature processing and path delay. Neither byte count is being asserted to represent an entire Ethernet transmission, an IP MTU or application payload. The values are solely the time occupied by those stipulated bits in this invented pipe.

Subtracting the two times compares different counted lengths. It does not calculate actual cut-through latency, actual store-and-forward latency or a saving between them. The model contains no forwarding-start event, header-processing requirement or device behavior from which to derive that saving.

CT-01 instead exposes why packet length belongs beside the headline. Receiving more counted bits takes longer at the same stipulated rate. Whether that reception interval is included in a reported latency depends on the report's boundary; how it overlaps forwarding depends on the actual device and conditions. Request comparable evidence for A and B before ranking the offers.

An error observed downstream may have arrived from upstream

Cisco's CRC explanation describes how a cut-through device can mark a frame's FCS as invalid after transmission has begun, a behavior called CRC stomping. Its precise implementation varies by platform. It also explains that one corrupt frame can increment error counters on several cut-through devices. Store-and-forward can discard a frame that fails the CRC check before forwarding it.

The purchase implication follows from that propagation mechanism. The location where an error is observed and the location where corruption originated are separate questions. An output-error indication does not, by itself, prove that the observing switch damaged the frame.

In a fictional path with two cut-through switches followed by a store-and-forward switch, stipulate a payload corruption that leaves the forwarding headers usable and fails the CRC check. The frame reaches the first switch already corrupt. The downstream switch can discard that frame even though the original corruption happened earlier. This illustrates observation location only; it supplies no actual trace, faulty-component diagnosis or approved topology.

A proposal to replace the final cable solely because an error appears at the downstream receiver has skipped the causal question. The responsible equipment or network specialist needs evidence connecting the original corruption to the proposed component-level action. The FEC guide explains the separate distinction between corrected bits, blocks and CRC-dropped packets; those quantities should retain their own meanings.

References: [C3]

A configured mode does not describe every loaded-network event

The 10.3(x) switching-mode chapter says congestion causes buffering, with buffered packets transmitted in store-and-forward fashion even though the global configuration remains unchanged. Thus a cut-through setting alone does not establish how every frame progresses under load.

For the buyer, a figure obtained without competing traffic leaves the contended condition unanswered. Ask whether a supplied result concerns an isolated flow or the intended simultaneous traffic, and whether it reports a minimum, average or a stated percentile over a defined observation. A favorable minimum cannot establish the behavior of the slower observations it omits.

Keep this question separate from nominal fabric capacity. The switch-bandwidth and oversubscription guide explains the capacity of populated uplinks. That capacity comparison does not supply queue delay, just as a forwarding-mode claim does not increase the capacity of an outgoing link.

A one-switch interval also leaves work outside that interval unresolved. GPU communication can involve a larger path and participating endpoints; a collective-operation result concerns the operation it actually measures. Use the NCCL metric guide when reviewing that evidence rather than treating a port-to-port number as the duration of the collective.

References: [C1]

Make the latency claim answer the equipment choice

For CT-01, neither offer earns a performance preference from its mode label or unmatched packet-size example. First establish the exact switch model, ASIC or line-card variant where relevant, software release, ingress and egress port rates, supported forwarding behavior and enabled features behind each claim. A family-level capability is insufficient evidence for a different offered variant.

Then decide whether the evidence answers the same requirement. A comparison of unloaded switch forwarding needs matching frame definitions and timing boundaries. A requirement concerning communication during simultaneous GPU traffic needs evidence for that traffic condition and the relevant path. A requirement concerning completed application work needs evidence at the application boundary. These are different purchase questions even when the same switch appears in all three.

Error handling belongs beside the timing claim. Have the supplier explain the offered platform's treatment of failed FCS checks and the meaning of its observations. Earlier transmission and local discard of an invalid frame describe different properties; the buyer must weigh the applicable behavior against the actual requirement.

If the offered hardware and timing records are comparable, they can inform a switch selection. If one result omits its length definition, feature state or load condition, the comparison remains unresolved. This is a basis for requesting the missing evidence, not an instruction to change modes or a conclusion that either fabric meets a workload requirement.

Carry the selected equipment into the physical cabling scope

Once the equipment and network owners approve the connection plan, Leviathan's structured cabling service can discuss installation, routing, dressing, labeling and connection records for the agreed customer-supplied fiber and copper assemblies. Use the service and project-inquiry links below to share the approved endpoint schedule, specified materials, customer-appointed materials supplier, routes, site constraints and required handoff records.

The physical scope follows that approved plan. Switch configuration, forwarding-mode selection and workload qualification remain with the appointed technical owners. Any instrument testing requires confirmed equipment, personnel, methods and criteria for the engagement. This article explains evidence for an equipment purchase; it supplies no field procedure or approval to work on a live connection.

References: [L1]