On Mon, 2010-06-14 at 23:44 +0400, Vladislav Bolkhovitin wrote: > Raj, on 06/12/2010 03:17 AM wrote: > > Nicholas A. Bellinger <n...@...> writes: > > > >> Btw, just for those following along, here is what MC/S and ERL=2 when > >> used in combination (yes, they are complementary) really do: > >> > >> http://linux-iscsi.org/builds/user/nab/Inter.vs.OuterNexus.Multiplexing.pdf > >> > >> Also, I should mention in all fairness that my team was the first to > >> implement both a Target and Initiator capable of MC/S and > >> ErrorRecoveryLevel=2 running on Linux, and the first target capable of > >> running MC/S from multiple initiator implementations. > >> > > > > But the end result is what? open-iSCSI still doesn't have the MC/S even > > though > > it is useful? > > The end result is that any driver level multipath, including MC/S, is > forbidden in Linux to encourage developers and vendors to improve MPIO > and not to try to workaround problems in it by their homebrewed > multipath solutions [1].
This is such pre multi-core pre FSB year 2005 agruement.. > As the result of this very smart policy, Linux > MPIO is in a very good shape now. Particularly, it scales with more > links quite well. In contrast, according to Microsoft's data linked in > this list recently, Windows MPIO scales quite badly, but Linux MPIO > scales similarly as Windows MC/S does [2]. (BTW, this is a good evidence > that MC/S doesn't have any inherent performance advantage over MPIO.) > Then why can't you produce any numbers for Linux or MSFT, hmmm..? Just as a matter of record, back in 2005 it was proved that Linux/iSCSI running with both MC/S *and* MPIO where complementary and improved throughput by ~1 Gb/sec using the 1st generation (single core) AMD Operton x86_64 chips on PCI-X 133 Mhz 10 Gb/sec with stateless TCP offload: http://www.mail-archive.com/linux-s...@vger.kernel.org/msg02225.html > But we are on the Linux list, so we don't care about Windows' problems. > Everybody are encouraged to use MPIO and, if have any problem with it, > report it in the appropriate mailing lists. > You are completely missing the point and ignoring the 'bigger picture' of what is going on in the iSCSI ecosystem. Also, if you think that arguing against the transparency of the upstream Linux/iSCSI fabric for complete RFC-3720 support with some unproven conjecture is going to win you something here, you are complete wrong. Just because you have not done the work yourself to implement the interesting RFC-3720 features does not mean you get to dictate (or dictate to others on this list) what the future of Linux/iSCSI will be. > Vlad > > [1] Yes, MC/S is just a workaround apparently introduced by IETF > committee to eliminate multipath problems they see in SCSI inside their > _own_ protocol instead of to push T10 committee to make the necessary > changes in SAM. Or, because a lack of acceptance of those problem from > T10 committee. But I'm not familiar with so deep history, so can only > speculate about it. Complete and utterly wrong. You might want to check your copy of SAM, because a SCSI fabric is allowed to have multipath communication paths and ports as long as the ordering is enforced for the I_T Nexus at the Target port. Again, you can speculate however you want without any MC/S implementation experience, but if you are ready to get serious with your unproven conjecture, please take it to the IETF IPS list and we will see what the fathers of iSCSI have to say about it. > > [2] The Windows MPIO limitations can well explain why Microsoft is the > only OS vendor pushing MC/S: for them it's simpler to implement MC/S > than to fix those MPIO scalability problems. Additionally, it could have > a future marketing value for them: the improved MPIO scalability would > be a big point to push customers to migrate to the new Windows version. > But this is again just a vague speculation ground. We will see in the > future. > Yeah sure, Intel, MSFT and Netapp claiming 1.25 million IOPs with MC/S on 5500 series chipsets with 5600 32nm chips and demonstrating it pubically all over the place for the last quarter is *really* a vague speculation. --nab -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
