Nicholas A. Bellinger, on 06/15/2010 04:46 AM wrote:
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..?
I wonder, have you read my article or just blindly refusing it, because
you have put to much effort in MC/S to accept it? If you read, you will
find in it links to the measurements.
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/[email protected]/msg02225.html
Your measurements did not prove anything, because you didn't find the
exact cause of the effect you seen. There could have been too many of
the causes, starting from a deeper queue depth with more connections and
ending to your initiator implementation problem(s) making it perform
worse with a single connection, with none of them directly relating to
MC/S vs MPIO. It's just a sane engineering practice to find out the
exact cause before making any conclusions and declarations. Otherwise,
such results are good only to help selling your stuff.
Actually, your are illustrating why the decision to forbid any driver
level multipath in the kernel is so wise. It's too easy for driver level
multipath developers to claim that the common MPIO is fundamentally
flawed instead of improving it.
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.
Dictating? So far it have only been analyzing the current state of
affairs. You don't have to agree.
[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.
Would you mind to point me out to _exact_ chapters in SAM describing
facilities to: (1) reassign tasks between different I_T nexuses and (2)
maintain order of commands over different I_T nexuses?
Vlad
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
