Of the many test scripts I ran on the Nexus 5000 this was, without any doubt, the most significant. The switch offers many powerful features, including guaranteed rate of traffic, automatic bandwidth management, and automated traffic span.
However, PFC is what legitimates FCoE as a viable convergence protocol that can bridge the gap between application servers and storage, and it makes the Nexus 5000 a much-needed component in datacenter consolidation projects.
One last question remained still unanswered in my evaluation: The Nexus 5000 had proven to have the features needed to be the connection point between servers and storage in a unified environment, but did the machine have enough bandwidth and responsiveness for the job?
To answer those I moved the testing to a different setting where the Nexus 5020 was connected to 8 hosts running NetPipe.
NetPipe is a remarkable performance benchmark tool that works particularly well with switches because you can measure end-to-end (host-to-host) performance and record (in Excel-compatible format) how those results vary when using different data transfers sizes.
A summary of what you can do with NetPipe is shown in the figure here (screen image).
In essence you can set NetPipe to use one way or bidirectional data transfers and increase the data transfer size gradually within a range., recording the transfer rate in megabytes per second and the latency in microseconds..
I ran my tests with a data size range from 1 byte to 8,198 bytes, but for clarity I am not listing the whole range of results but only a few, following a power of two pattern.
Also to mimic a more realistic working condition, I ran the same tests first without any other traffic on the switch and then added one and two competing flows of traffic.
Finally, to have a better feeling of how much the switch impacts transfer rate and latency, I ran the same test back to back, in essence replacing the switch with a direct connection between the two hosts.
It's interesting to note how the transfer rate increases gradually with higher data size reaching numbers very close to the theoretical capacity of 10G Ethernet.
The latency numbers, where lower is better, is obviously the most important proof of the switch responsiveness. Even if we consider the best results where the Nexus 5020 is in the path, the delta with the back-to back stays between 3 and 3.5 microseconds, which is essentially the latency added by the switch.
This number is not only very close to what Cisco suggests for the 5020 , but is probably the shortest latency that you can put between your applications and your data.
A step for network consolidation
When reviewing products such as the Nexus 5000 that bear the first implementation of an innovative technology is often difficult to maintain judgments about of the technology separated from that about the solution. Which is probably why, at the end of my evaluation, I tend to think of the Nexus 5020 and of FCoE as a whole -- which they are, because at the moment there is no other switch that let you implement the new protocol.
However, even if I break apart the two, each piece has merits of its own. I like the unified view that FCoE brings to network transport and I like the speed and feather-light impact that the Nexus 5020 brings to that union.
Obviously the Nexus 5000 is a first version product and however well rounded, it's easy to predict that future versions will move up the bar even further. As for the technology, perhaps the greatest endorsement that FCoE received is that Brocade is planning to ship a Nexus 5000 rival solution, based on FCoE by year's end. Obviously the old "if you can't beat them, join them" battle cry of competition is still alive and well in the storage world.