Thanks for reading. AoE was not part of our exploratory testing parameters.

   0 likes

   0 likes

In other words I think it’s like trying to measure millimeter distances using a yard stick…

Erik

   0 likes

If you are comparing three protocols that are each capable of utilizing lossless forwarding in the network, providing that same service to all three protocols would certainly put you in a better position to set the ‘all things being equal’ premise.

It would also help to have the iSCSI, FC, and FCoE storage arrays using similar speed drives. In the Demartek test, the FCoE array utilized 15K rpm drives, while the FC and iSCSI arrays were equipped with 10K rpm drives. That alone discredits the “FCoE tests had lower latency than iSCSI” conclusion. No?

Looking forward to seeing the results and setup of your more comprehensive tests.

Cheers,
Brad

   1 like

First, this was not lossless iSCSI, but regular TCP/IP iSCSI with full TCP offload. Second, since that offload was done on the CNA, and not on the CPU, it seemed logical that ‘all things were equal’ from the hardware perspective.

You do raise some good points, though, and as this was an exploratory test (and not supposed to be definitive), I have some ideas and plans for what a more comprehensive tests that I want to run. Thanks for reminding me about some of the variables.

J

   0 likes

I’m surprised you wouldn’t seek out these details before coming to your conclusion. You don’t think such things matter?

Also, I find it interesting that you would make a conclusion under the premise of “all things being equal”, when in fact the FCoE host was using a faster processor than the FC and iSCSI hosts.

Cheers,
Brad

   0 likes

   0 likes

“Generally speaking, the latency for 10GbE switches is measured in microseconds, while storage latencies are generally measured in milliseconds.”

In other words, the reason why the latency was virtually identical over the set of topologies tested was because the amount of latency introduced by the network was practically a rounding error when compared to the latency introduced by either the host or storage array.

I said either host or storage array because I don’t know enough about the application/end points to know exactly how much latency will be introduced by each component. That having been said, I suspect the VAST majority of the total latency was due to the storage array. Although I work for EMC and would love the chance to tweak my colleagues at NetApp, the simple fact is that (as of today) the response time from the storage array (any array including ours) will always be at least one or two orders of magnitude greater than the latency introduced by the Network.

With this in mind, since Demartek was kind enough to run these tests over a set of different topologies, I suspect I now know much more about NetApp’s average response time when using different protocols than about anything else. BTW, I’ll point out that the average response times from the arrays were much longer that I would have expected. I would recommend that they re-run the test using something other than SQLIO since that application seems specifically designed to stress the storage array.

“SQLIO is a utility application provided by Microsoft that sends database I/O workloads to a storage system for the purpose of stress testing a storage system.”

If they were to use something that generated large block sequential reads and writes, they may get much more reasonable response times, but again the network latency would probably fall into the “background noise” category since we’d still probably be talking about milliseconds versus microseconds.

Regards, Erik

   0 likes

Will we need at the end a special storage network protocol at all ?

Mid of july the major vendors at SNIA founded a working group to standardize the direct access from processors to nonvolatile memory (NAND-Flash, RRAM).
Maybe in the future we will see more distributed processors with hundreds of Terabytes of nonvolatile memory included, just connected via highspeed Ethernets, like the Nutanix cluster.
If that happens, FCoE may have the same destiny like Token Ring – for some time quite successful, but at the end of no practical use because of a technology break.

   0 likes

   0 likes