On 4 Jan 2010 at 6:54, Jack Z wrote:

> Hi all,
> I was testing the performance of open-iscsi initiator with IET target
> over a 100Mbps Ethernet link with emulated rtt.  What I did was to do
> raw disk sequential write by
> $ dd if=/dev/zero of=/dev/sdb bs=1024 count=1048576
> , in which /dev/sdb is the iSCSI device. I also measured TCP
> throughput using iperf with the default setup except "-n 1024M". And I
> got the following data on iSCSI throughput and TCP throughput v.s. rtt
> rtt (ms)        iSCSI throughput by dd (MB/s)   TCP throughput by
> iperf (Mbit/s)
> 0.2               11.3
> 94.3
> 4                  11.1
> 94.3
> 8                  10.2
> 94.3
> 12                8.6
> 94.2
> 16                7.2
> 94.2
> 20                6.0
> 94.1
> local disk throughput by dd was 26.7 MB/s.
> As shown in the table above, iSCSI throughput declined rapidly with
> rtt increased from 0.2ms to 20ms. TCP throughput, however, only
> dropped less than 1 percent.

>From what I know the (estimated) RTT (Round Trip Time) increases if a link 
(i.e. lost packets) was detected (if other parameters are unchanged).

> Then I used Wireshark to grab the traces of iSCSI and iperf and I
> found lots of iSCSI PDUs were divided into TCP segments of 1448 bytes
> but with iperf TCP segments could be as large as 65000+ bytes.

How would you transport such a segmen unfragmented?

> I first thought this was because of the small default value (8192) for
> MaxRecvDataSegmentLength. So I increased that value to 262144. But in
> a later test with 16ms rtt, I found the iSCSI throughput was only
> improved by 0.7 MB/s and a lot of iSCSI PDUs were still divided into
> 1448 byte long TCP segments... So I think MaxRecvDataSegmentLength may
> not be the reason.

I think the question is how big the TCP receive window will be.

> I also skimmed through the iSCSI specification, but it seemed no luck
> there either...
> I know the Ethernet MTU is 1500 byte long and that might be the reason
> of the 1448 byte TCP segments, but iperf did get to send much larger
> TCP segments of 65000+ bytes...

over which layer 2?

> So does anyone have any idea about this: why iSCSI is not fully
> utilizing the bandwidth on long rtt links by increasing the TCP
> segment size?

Sorry, but I think utilizing a high-delay conncetion works via increasing the 
window size (i.e. number of packets), not the size of the segments. Both would 
valid, but due to layer 2 and layer 3 restrictions (ISO OSI talk), only sending 
more packets while waiting for an answer will be a valid assumption (unless you 
have a dedicated single-hop line).


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 
For more options, visit this group at 

Reply via email to