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 >problem (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 be 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). Regards, Ulrich
-- 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.
