Re: Issue with tim_txcrd_z

Oh boy. You picked one of the toughest ones to explain completely. The short answer is that this counter is a time counter. Each discrete number represents a 2.5 microsecond of time which the port is fully starved or depleted of transmit buffers. Think of it as a tick counter, where each tick represents 2.5uS. The higher the number, of course the higher amount of time the port has been depleted of transmit buffers.

This generally inidicates a port where there is a 'slow drain' latency occuring. As an example, lets say we connect a storage device to port 12/6 of the FC16-32 blade in slot 12 of the 8510. During the FLOGI(fabric login) the device, and the Brocade port negotiate the number of buffers to allocate. A storage device F port must be able to receive, decode, and store then forward frames from the Brocade, and then repeat this for the next frame in the exchange. A situation where the buffers available to transmit, are less than the number of buffers available on the storage device can happen which then becomes a 'slow drain device'. The receive port determines the speed of the transmission available by limiting the number of credits freed back to the transmit port. If the transmit port on the Brocade switch has all frames in flight, or at the receive end, then the buffer credits available will be zero, and for each 2.5Us, the tim_txcrd_z counter will be increased.

It can cause backpressure through the back end ports of the switch, and even across an E port ISL to another switch. It should be resolved as it can cause issues with other devices if the backpressure is felt across the back end ports, or ISLs causes a congestion within the fabric. The CLI commands to investigate this are portbuffershow, and for investigation of each port virtual circuit and other important flow control counters use portstats64show s/p which will provide very granular information about the frames and timing on each slot/port.

This is a complex calculus when devices and the Brocade switch are not well matched in flow control. Also when widely different speeds are used within a fabric, such as - from a legacy 2Gbps host, attached to a legacy switch, then ISLed to a 8 or 16Gbps switch which allows the 2Gbps traffic to transit a much higher speed backplane, and cause congestion that affects other devices.

More reading can be found in the Fabric Admin Guide, which is downloaded from the top panel of the my.brocade.com website under 'Documentation' in the chapter on "Buffer to buffer credits, and credit recovery".

Best of luck,

doc

Any and all information provided by me is for entertainment value and should not be relied upon as a guaranteed solution or warranty of mechantability. All systems and all networks are different and unique. If you have a concern about data loss, or network disconnection, please open a TAC service request for service through Brocade, or through your OEM equipment provider. If this provided you with a solution to this issue, Please mark it with the button at the bottom "Accept as solution".

Join the Broadcom Community

You have no obligation to provide any ideas, suggestions, comments or other feedback regarding content on the Site, Brocade and Broadcom's products or any information posted on the Site (collectively, “Contributions”). However, any Contributions You voluntarily provide may be used in Brocade and Broadcom products and related specifications or other documentation. Accordingly, if You do make any Contributions on this Site, You agree that Brocade and Broadcom may freely use, disclose, reproduce, license, distribute and otherwise commercialize the Contributions in any Brocade or Broadcom product, technology, service, specification or other documentation, as well as file for, register or otherwise assert copyright, trademark, patents and any other intellectual property rights in and to the Contributions.