Why One Ethernet Bit Rate Can Require Very Different Packet Rates

Count the time between successive frame starts

A NIC or switch proposal can quote both Gb/s and millions of packets per second. The first describes a bit-rate boundary; the second needs a definition of the processed object. For this comparison, count one complete Ethernet MAC frame per event, from destination address through the Frame Check Sequence, or FCS. Include headers, data, any padding and FCS in that frame length.

The preamble and Start of Frame Delimiter precede that counted frame. The basic accounting uses seven preamble octets plus one delimiter octet. An inter-frame gap follows before the next transmission. A frame-size label therefore omits time needed by the repeated sequence.

Think of consecutive frames passing one observation point. Each cycle must accommodate the preceding allowance, the counted frame and the intervening gap. Shortening the frame shortens only the middle part; the other allowances recur more often per second. That is why the frame-event demand rises as frame length falls.

An octet-time means the time needed for eight bits at the chosen accounting rate. Gap octet-times represent elapsed time, not additional bytes delivered inside the frame.

References: [A1][R1]

Define the 100 Gb/s model before dividing

RFC 2544, published in March 1999 as an Informational benchmark document, supplies a historical accounting reference in Appendix B: 64 preceding bits, eight times the frame length in bits, and 96 gap bit-times. Its section 9.1 includes the 64-byte and 1,518-byte frame sizes used here.

Now invent a steady-state, one-direction MAC-level time budget of exactly 100,000,000,000 bit/s. Choose basic untagged frames, with lengths including FCS. Assign eight preceding octet-times and a long-run average of 12 gap octet-times per frame. Exclude pause activity, other traffic, additional idle time and implementation limits. The resulting formula is frames/s = 100,000,000,000 / [8 × (frame bytes + 8 + 12)].

The average qualification matters. Altera's version 16.1 Low Latency 100-Gbps Ethernet IP Core guide, section 3.2.1.6, describes a deficit idle counter maintaining a 12-byte average gap. That implementation example supports treating the gap as an average budget rather than imposing exactly 12 physical idle bytes after every frame.

This model uses the MAC accounting rate, not raw optical baud or an encoded PHY bit rate. Do not deduct PCS coding or FEC overhead again from the stipulated 100 Gb/s. Describing a particular physical encoding requires its own interface and PHY definition. RFC 2544 does not specify 100GbE behavior; the calculations below are original arithmetic using the explicitly chosen model.

References: [R1][I1]

Work the 64-byte and 1,518-byte cases

For repeated 64-byte frames, the accounted cycle occupies 64 + 8 + 12 = 84 octet-times, or 672 bit-times. Dividing 100,000,000,000 by 672 gives approximately 148,809,524 frames/s: about 148.81 million frames/s.

For repeated 1,518-byte frames, the cycle occupies 1,518 + 8 + 12 = 1,538 octet-times, or 12,304 bit-times. Dividing the same rate by 12,304 gives approximately 8,127,438 frames/s: about 8.127 million frames/s.

The ratio is 1,538 / 84 = approximately 18.31. Filling the same modeled bit-rate budget with the smaller frames requires about 18.31 times as many frame events. The ratio includes the recurring allowances; dividing 1,518 by 64 would compare frame bytes alone.

Both lengths already include FCS, so adding it again would overcount. The 1,518-byte choice describes this basic untagged example, not a universal maximum for every Ethernet frame format. Neither calculated rate measures application throughput, host software objects, switch latency or an actual device's processing performance.

Apply a fictional 100-million-frame/s processing ceiling

Suppose an invented device advertises a 100 Gb/s port and has a hard processing ceiling of 100 million frames/s for the one-direction forwarding path being considered. Stipulate that the ceiling counts the same complete frames as the model and that every other resource is unlimited. These are teaching assumptions, with no actual product or measured result behind them.

With 64-byte frames, filling the modeled port budget requires about 148.81 million frame events/s. The stipulated ceiling allows only 100 million. At that ceiling, 100 million frames/s would occupy 100,000,000 × 672 = 67,200,000,000 bit-times per second, equivalent to 67.2 Gb/s of the modeled occupancy budget. This quantity includes the gap allowance; it is neither frame-data throughput nor application goodput.

With 1,518-byte frames, the requirement is only about 8.127 million events/s. Under these teaching assumptions, the 100-million-frame/s ceiling does not prevent filling the modeled budget with 1,518-byte frames. A real product still needs measured forwarding evidence; this invented example establishes no actual product performance.

The port-rate label and processing ceiling can therefore coexist while supporting different conclusions for the two frame populations. The buyer needs the frame-size-dependent forwarding evidence. The 18.31 ratio does not imply 18.31 times the CPU cost; this arithmetic contains no processor-work model.

Make the supplier's packet-rate evidence match the requirement

Request a measured forwarding result with its frame length and size convention attached. Establish whether FCS is included, where events are counted, which direction is covered and whether a headline rate belongs to one port, several ports or a shared device resource. A switch-wide aggregate cannot be assigned in full to every port.

Keep the exact offered hardware and software context, forwarding features, protocol, traffic pattern, observation interval and loss criterion with the result. For a minimum-frame claim, distinguish a theoretical framing limit from evidence that the offered path actually forwards that population. RFC 2544 section 26.1 makes the historical distinction explicit by separating theoretical-media rates from measured device results and retaining frame size with an advertised rate.

For traffic with several frame sizes, ask for evidence covering the intended distribution and simultaneous ports. State whether the distribution is expressed by frame count or byte volume: half the bytes in small frames does not mean half the frames are small. Extra idle time, control traffic or pauses also change the available time budget; the two pure-size examples cannot stand in for that workload.

Use the related MTU and MSS article to establish which bytes a packet-length claim counts. Use the offload article when a reported packet rate counts host objects rather than complete external frames. Use the forwarding-mode article when the requirement concerns latency. Resolving those questions supplies the right inputs and observation boundaries; each remains a separate decision from repeated-frame occupancy.

If a supplier supplies only the port bit rate, the packet-processing question remains open. If its minimum-frame result is properly scoped, it can answer that capacity question without establishing application completion time or the behavior of a different traffic mix. Ask for the evidence needed for the actual purchase requirement.

References: [R1]

Carry approved equipment choices into the cabling inquiry

If the equipment choice creates a separate physical connection project, Leviathan's Structured Cabling & Fiber Installation service can discuss routing, assembly installation, dressing, labeling and agreed connection records using customer-furnished or separately sourced materials.

Use the related service and project-inquiry links to share a nonconfidential outline of the approved endpoints, patching, routes, materials responsibilities and required handoff. Packet-processing evaluation and network configuration remain with the appointed technical owners; this explanation supplies no field procedure or work approval.

References: [L1]