Re: Over one million IOPS using software iSCSI and 10 Gbit Ethernet, 1.25 million IOPS update

2010-06-15 Thread Vladislav Bolkhovitin

guy keren, on 06/15/2010 01:46 AM wrote:

Vladislav Bolkhovitin wrote:

Pasi Kärkkäinen, on 06/11/2010 11:26 AM wrote:

On Fri, Feb 05, 2010 at 02:10:32PM +0300, Vladislav Bolkhovitin wrote:

Pasi Kärkkäinen, on 01/28/2010 03:36 PM wrote:

Hello list,

Please check these news items:
http://blog.fosketts.net/2010/01/14/microsoft-intel-push-million-iscsi-iops/ 

http://communities.intel.com/community/openportit/server/blog/2010/01/19/100-iops-with-iscsi--thats-not-a-typo 

http://www.infostor.com/index/blogs_new/dave_simpson_storage/blogs/infostor/dave_simpon_storage/post987_37501094375591341.html 



1,030,000 IOPS over a single 10 Gb Ethernet link

Specifically, Intel and Microsoft clocked 1,030,000 IOPS (with 
512-byte blocks), and more than 2,250MBps with large block sizes 
(16KB to 256KB) using the Iometer benchmark


So.. who wants to beat that using Linux + open-iscsi? :)
I personally, don't like such tests and don't trust them at all. 
They  are pure marketing. The only goal of them is to create 
impression that X  (Microsoft and Windows in this case) is a 
super-puper ahead of the  world. I've seen on the Web a good article 
about usual tricks used by  vendors to cheat benchmarks to get good 
marketing material, but,  unfortunately, can't find link on it at the 
moment.


The problem is that you can't say from such tests if X will also 
ahead  of the world on real life usages, because such tests always 
heavily  optimized for particular used benchmarks and such 
optimizations almost  always hurt real life cases. And you hardly 
find descriptions of those  optimizations as well as a scientific 
description of the tests themself.  The results published practically 
only in marketing documents.


Anyway, as far as I can see Linux supports all the used hardware as 
well  as all advance performance modes of it, so if one repeats this 
test in  the same setup, he/she should get not worse results.


For me personally it was funny to see how MS presents in the WinHEC  
presentation  
(http://download.microsoft.com/download/5/E/6/5E66B27B-988B-4F50-AF3A-C2FF1E62180F/COR-T586_WH08.pptx) 
that they have 1.1GB/s from 4 connections. In the beginning of 2008 
I  saw a *single* dd pushing data on that rate over a *single* 
connection  from Linux initiator to iSCSI-SCST target using regular 
Myricom hardware  without any special acceleration. I didn't know how 
proud I must have  been for Linux :).



It seems they've described the setup here:
http://communities.intel.com/community/wired/blog/2010/04/20/1-million-iop-article-explained 



And today they seem to have a demo which produces 1.3 million IOPS!

1 Million IOPS? How about 1.25 Million!:
http://communities.intel.com/community/wired/blog/2010/04/22/1-million-iops-how-about-125-million 

I'm glad for them. The only thing surprises me that none of the Linux 
vendors, including Intel itself, interested to repeat this test for 
Linux and fix possible found problems, if any. Ten years ago similar 
test about Linux TCP scalability limitations comparing with Windows 
caused massive reaction and great TCP improvements.


The way how to do the test is quite straightforward, starting from 
making for Linux similarly effective test tool as IOMeter on Windows 
[1]. Maybe, the lack of such tool scares the vendors away?


Vlad

[1] None of the performance measurement tools for Linux I've seen so 
far, including disktest (although I've not looked at newer (1-1.5 years) 
versions) and fio satisfied me for various reasons.


there's iometer agent (dynamo) for linux (but the official version has 
some one fundamental flow, which should be fixed - it doesn't use AIO 
properly) - you just need a windows desktop to launch the test, and run 
the dynamo agent on a linux machine.


there is also vdbench from sun.


vdbench is Java-based, so not suitable for this particular case, where 
low CPU overhead is a key.



--guy



--
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.



Re: Problem diagnosing iscsi failure on the initiator

2010-06-15 Thread Mike Christie

On 06/14/2010 08:52 AM, Michal Suchanek wrote:

On 13 June 2010 21:01, Mike Christiemicha...@cs.wisc.edu  wrote:

On 06/12/2010 06:31 AM, Michal Suchanek wrote:


Hello

I tried to get an iscsi setup working so I installed iscsitarget and
open-iscsi and tried to export a file as an iSCSI lun.

After doing so I could log in with iscsiadm but I would not get any
disks on the initiator.

Later I discovered that I had a typo in the ietd.conf file and the lun
was simply not exported giving a target with no luns available for the
initiator.

While it is true that the error is logged in kernel logs on the target
machine I could not find any way to list the available luns on the


iscsiadm -m session -P 3


Thanks, this command does print the luns if there are any.

However, it is not obvious from the documentation that it should print
these nor is it obvious from the output that there some part missing
when no luns are available.


In the README I will add more info on how -P X works for session mode.




It also does not work when I just add -P 3 to the discovery and node
commands which I use to log into the target and there is no obvious
reason why it should not.



Discovery mode just finds targets and portals. It has nothing to do with 
LUN discovery normally. And the node mode commands that print out the 
node db info also just prints the target and portal info, because it is 
only concerned with the targets.


If for discovery and node mode, you are logging into the target (using 
the --login command) then I can print out the LUNs found if that is what 
you are asking for. But normally with the discovery and node mode 
commands that use the -P operator we are just working on the targets and 
portals and have not logged into the target so we do not know if there 
are LUNs.


--
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.