Fibre Channel (SAN)

Reply
Visitor
Posts: 1
Registered: ‎07-27-2011

FCping output.

Hallo if I do a "fcping --number 200 10:00:00:00:c9:5c:7f:06" i get the following result(excerpt):

received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:197 usec

received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:9580 usec

received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:211 usec

received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:13817 usec

received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:213 usec

received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:5071 usec

received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:238 usec

received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:9482 usec

received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:216 usec

received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:9549 usec

received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:210 usec

received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:13811 usec

received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:232 usec

received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:5137 usec

200 frames sent, 200 frames received, 0 frames rejected, 0 frames timeout

Round-trip min/avg/max = 181/4486/16596 usec

Every second result is high. Has anyone an idea?

If we do a s(same switch same dest port) :

"fcping --number 10 --interval 1  10:00:00:00:c9:5c:7f:06"

This is the result :

Destination:    10:00:00:00:c9:5c:7f:06

Pinging 10:00:00:00:c9:5c:7f:06 with 12 bytes of data:
received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:289 usec
received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:291 usec
received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:275 usec
received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:270 usec
received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:554 usec
received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:290 usec
received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:277 usec
received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:545 usec
received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:367 usec
received reply from 10:00:00:00:c9:5c:7f:06: 12 bytes time:271 usec
10 frames sent, 10 frames received, 0 frames rejected, 0 frames timeout
Round-trip min/avg/max = 270/342/554 usec

I can't explain it anyone can ?

With kind regards

Hein Reumkens.

Valued Contributor
Posts: 761
Registered: ‎06-11-2010

Re: FCping output.

Hi,

fcping is a tool designed to test connectivity, not response time and the times reported are not valid. You have to bear in mind that fcping run by the CP (and it is probably a modification of underlying OS ping command) and not directly by the ASICs, so any measure will not be accurate and should not be taken into consideration.

Rgds

Occasional Contributor
Posts: 14
Registered: ‎11-12-2009

Re: FCping output.

From BCSM Nutshell:

"The fcping command can also be used to identify a marginal link. Issue fcping from the switch with the questionable connection; use WWN of questionable device as the source and look at the response times, consider using the length and number of frame operands to send more data. If you have a marginal connection and send enough frames and/or data you should be able to catch responses with a much longer response time."

Isn't it buffercredit related? Does fcping allocate/use the buffercredit system to get to the other side of the link? Because I see some interesting behaviour.

Checking a mostly idle connection, using an interval of 1 second, we see normal latency, for example 1 ms. Pinging the same connection, using --number 400 and interval of 1 second, also (mostly) normal latency of 1 ms. Now ping with only using --number 400. We get way higher latencies. Of course, this can be caused by asics, but couldn't it be the case that fcping also runs out of buffer credits?

/edit

Tested with huge amount of buffers, makes no difference. fcping seems useless indeed for measuring latency

Join the Community

Get quick and easy access to valuable resource designed to help you manage your Brocade Network.

vADC is now Pulse Secure
Download FREE NVMe eBook