Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id h3I2nYU27358
	for ips-outgoing; Thu, 17 Apr 2003 22:49:34 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from leviathan.ele.uri.edu (leviathan.ele.uri.edu [131.128.51.64])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h3I2nU327353
	for <ips@ece.cmu.edu>; Thu, 17 Apr 2003 22:49:30 -0400 (EDT)
Received: from dragonfly (ip68-9-255-122.ri.ri.cox.net [68.9.255.122])
	by leviathan.ele.uri.edu (8.12.6/8.12.6) with ESMTP id h3I2nRf2015236;
	Thu, 17 Apr 2003 22:49:28 -0400 (EDT)
From: mingz <mingz@ele.uri.edu>
Reply-To: mingz@ele.uri.edu
To: David Woolf <djwoolf@io.iol.unh.edu>
Subject: Re: iSCSI read/write cost difference
Date: Thu, 17 Apr 2003 22:48:40 -0400
User-Agent: KMail/1.5
References: <200304171210.21223.mingz@ele.uri.edu> <Pine.LNX.4.53.0304171418001.8266@io.iol.unh.edu>
In-Reply-To: <Pine.LNX.4.53.0304171418001.8266@io.iol.unh.edu>
Cc: ips@ece.cmu.edu
MIME-Version: 1.0
Content-Type: text/plain;
  charset="gb2312"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200304172248.40859.mingz@ele.uri.edu>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

yes, i test these three situations and get the results as follows

1) for all InitialR2T =Y/N, ImmediateData = Y/N, the read results are all
 same.
2) initialr2t has no influence on write
3) immediatedata has influence on write.

IOPS: (scsi ram disk)
 		2k		4k		8k		16k		32k
read		1975	1781	1557	1081	767
write 	2877	2225	1588	812		533 (immediatedata =yes)
write	1971	1527	1199	880		566 (immediatedata =no)

when immediaredata=yes,  for small write, data go with the command, so should 
be faster, but why with large data size, like 16k and 32k, the write is 
slower? and why write is always slower than read with large data size?

btw, can u answer this question,  'Also, does the target piggyback SCSI 
Response in the Final Datain pdu?' since this code is from your unh iol, 
hehe. thx.


On Thursday 17 April 2003 14:19, you wrote:
> Hello,
> Have you done these experiments with InitialR2T=Yes and Immediatedata=No,
> InitialR2T=Yes and Immediatedata=Yes, and InitialR2T=No and
> ImmediateData=Yes? I'd be interested to see how the results change.
>
> thanks,
>
> David Woolf
> ************************************************
> University of New Hampshire Interoperability Lab
> iSCSI and Fibre Channel Consortiums
> Durham, NH 03824
> (603) 862 0701
> ************************************************
>
> On Thu, 17 Apr 2003, mingz wrote:
> > I recently did some experiments on iSCSI benchmarking. I used the UNH
> > iSCSi ref18_03 implementation and use a ram based scsi device for iscsi
> > target use. so there is no any disk overhead.
> >
> > I used a linux kernel module to send fixed size read/write requests to
> > iscsi initiator, which eventually will be filled by iscsi target. i use
> > interl pro1000 gigabit nic and intel 470 gigabit switch. and both
> > initiator and target use same type piii 866 pc with 1g ram.
> >
> > now the IOPS result shows that
> >
> > 		2k		4k		8k		16k		32k
> > read		1975	1781	1557	1081	767
> > write 	2877	2225	1588	812		533
> >
> > for small reuqests, read is slower than write, while for large requests,
> > read is faster than write. i redo the experiments on another enviroment,
> > also get similar results.
> >
> > can anybody explain why this happens?
> >
> > thanks a lot.
> >
> >
> > ming

-- 
 --------------------------------------------------
| Ming Zhang, PhD. Student                                     
| Dept. of Electrical & Computer Engineering       
| College of Engineering                           
| University of Rhode Island                       
| Kingston RI. 02881                                  
| e-mail: mingz@ele.uri.edu                        
| Tel. (401) 874-2293 Fax  (401) 782-6422          
| http://www.ele.uri.edu/~mingz                     
 --------------------------------------------------
