Cisco Cisco Nexus 5010 Switch Libro bianco

White Paper

Page 3 of 8

●

Maximum transmission unit (MTU) on the transmitting end of receiver R: If R intends to emit a PAUSE

frame, the PAUSE frame cannot preempt another frame currently being transmitted in the same direction

(from R to S). You can safely assume that the PAUSE frame will pass ahead of any other packet queued in R

for transmission, but you do not want to corrupt a packet that is currently in flight. In the worst case, R

generates a PAUSE frame right when the first bit of a maximum-size packet MTU[R] has started engaging the

transmission logic. The maximum-size packet in flight in front of the PAUSE frame delays the emission of the

PAUSE frame; as such, it can belong

to any CoS, and we’ll need to account for the largest MTU configured

across all CoSs.

●

Speed of wire W: Bits travel at 70 percent of the speed of light in a twin-ax copper cable, and at 65 percent of

the speed of light in a single-mode fiber. Therefore, every 100 meters of cable delays reception of a packet by

an additional 476 nanosecond (ns) for copper cables and by an additional 513 ns for single-mode fibers. At 10

Gbps, while a PAUSE frame spends 476 ns traversing 100 meters of copper cable, sender S will transmit an

additional 4760 bits (595 bytes) in the opposite direction, or an additional 5130 bits (641 bytes) for the 513 ns

of delay in a single-mode fiber. The rest of this discussion will take into account the worst case: 641 bytes for

every 100 meters.

If you view the cable as a buffer in itself, this buffer holds a certain amount of data when the PAUSE frame
starts its journey. The amount of data “stored” in the cable when the PAUSE frame is injected is exactly the

same as the amount of new data that is injected by sender S while the PAUSE frame traverses the wire.

Therefore, combining the previous element with this one, overall you need to double the contribution to the

threshold that every 100 meters of cable adds. That brings the total cable length contribution to 1282 bytes for

every 100 meters, or approximately 1300 bytes. This is the only variable element in the definition of the

receiver thresholds.

●

Transceiver latency: As with the speed of the wire, the latency introduced by both the transceivers in R (the

transmitting end of the PAUSE frame) and S (the receiving end of the PAUSE frame) delays the PAUSE

frame and therefore maps directly to a certain amount of additional data generated in the opposite direction

from S to R. Again, every 512 ns of latency mean an additional 640 bytes to account for, and again, the

contribution must be doubled, yielding 1280 bytes per 512 ns of combined transceivers latency. In general,

though, the contribution of Small Form-Factor Pluggable Plus (SFP+) transceivers to the overall byte count is

negligible (less than 512 ns) compared to all the other elements listed here, and therefore this piece can be

ignored moving forward

●

Response time of sender S: After a PAUSE frame has been received by S, the internal logic of S will spend

an implementation-dependent amount of time processing the frame and responding to the request to stop

transmission. The PFC definition caps this time to 60 quanta for any implementation. As seen previously, 60

quanta are 512 * 60 = 30,720 bits (3840 bytes).

●

MTU on the transmitting end of sender S: After sender S finally decides to comply with the PAUSE request

made by receiver R, S can stop only at packet boundaries, to avoid packet corruptions. In the worst case, S

will have completed processing of the PAUSE frame when the first bit of a maximum-size packet MTU[S] has
started engaging the transmission logic. Contrary to MTU[R], MTU[S] impacts the receiver’s buffers only if it’s

meant for the CoS that triggered the PAUSE in the first place, since packets destined to other CoS will use a

different buffer pool; as such, the worst case for MTU[S] is the MTU configured for that CoS.

This assumption can be made because none of the implementations at Cisco currently supports 10GBASE-T transceivers. With

2.5 microseconds of latency per transceiver, the current state of the art 10GBASE-T transceivers would account for the equivalent of
a total of 12,800 bytes of delay, and it would not be possible to ignore such a large amount of additional buffering