On Fri, 2007-10-19 at 09:48 +0200, BERTRAND Joël wrote: > Ross S. W. Walker wrote: > > BERTRAND Joël wrote: > >> BERTRAND Joël wrote: > >>> I can format serveral times (mkfs.ext3) a 1.5 TB volume > >> over iSCSI > >>> without any trouble. I can read and write on this virtual > >> disk without > >>> any trouble. > >>> > >>> Now, I have configured ietd with : > >>> > >>> Lun 0 Sectors=1464725758,Type=nullio > >>> > >>> and I run on initiator side : > >>> > >>> Root gershwin:[/dev] > dd if=/dev/zero of=/dev/sdj bs=8192 > >>> 479482+0 records in > >>> 479482+0 records out > >>> 3927916544 bytes (3.9 GB) copied, 153.222 seconds, 25.6 MB/s > >>> > >>> Root gershwin:[/dev] > dd if=/dev/zero of=/dev/sdj bs=8192 > >>> > >>> I'm waitinfor a crash. No one when I write these lines. > >> I suspect > >>> an interaction between raid and iscsi. > >> I simultanely run : > >> > >> Root gershwin:[/dev] > dd if=/dev/zero of=/dev/sdj bs=8192 > >> 8397210+0 records in > >> 8397210+0 records out > >> 68789944320 bytes (69 GB) copied, 2732.55 seconds, 25.2 MB/s > >> > >> and > >> > >> Root gershwin:[~] > dd if=/dev/sdj of=/dev/null bs=8192 > >> 739200+0 records in > >> 739199+0 records out > >> 6055518208 bytes (6.1 GB) copied, 447.178 seconds, 13.5 MB/s > >> > >> without any trouble. > > > > The speed can definitely be improved. Look at your network setup > > and use ping to try and get the network latency to a minimum. > > > > # ping -A -s 8192 172.16.24.140 > > .... > > --- 172.16.24.140 ping statistics --- > > 14058 packets transmitted, 14057 received, 0% packet loss, time 9988ms > > rtt min/avg/max/mdev = 0.234/0.268/2.084/0.041 ms, ipg/ewma 0.710/0.260 ms > > gershwin:[~] > ping -A -s 8192 192.168.0.2 > PING 192.168.0.2 (192.168.0.2) 8192(8220) bytes of data. > 8200 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.693 ms > 8200 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.595 ms > 8200 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=0.583 ms > 8200 bytes from 192.168.0.2: icmp_seq=4 ttl=64 time=0.589 ms > 8200 bytes from 192.168.0.2: icmp_seq=5 ttl=64 time=0.580 ms > 8200 bytes from 192.168.0.2: icmp_seq=6 ttl=64 time=0.594 ms > 8200 bytes from 192.168.0.2: icmp_seq=7 ttl=64 time=0.580 ms > 8200 bytes from 192.168.0.2: icmp_seq=8 ttl=64 time=0.592 ms > 8200 bytes from 192.168.0.2: icmp_seq=9 ttl=64 time=0.589 ms > 8200 bytes from 192.168.0.2: icmp_seq=10 ttl=64 time=0.571 ms > 8200 bytes from 192.168.0.2: icmp_seq=11 ttl=64 time=0.588 ms > 8200 bytes from 192.168.0.2: icmp_seq=12 ttl=64 time=0.580 ms > 8200 bytes from 192.168.0.2: icmp_seq=13 ttl=64 time=0.587 ms > > --- 192.168.0.2 ping statistics --- > 13 packets transmitted, 13 received, 0% packet loss, time 2400ms > rtt min/avg/max/mdev = 0.571/0.593/0.693/0.044 ms, ipg/ewma 200.022/0.607 ms > gershwin:[~] > > > Both initiator and target are alone on a gigabit NIC (Tigon3). On > target server, istd1 takes 100% of a CPU (and only one CPU, even my > T1000 can simultaneous run 32 threads). I think the limitation comes > from istd1. usually istdx will not take 100% cpu with 1G network, especially when using disk as back storage, some kind of profiling work might be helpful to tell what happened... forgot to ask, your sparc64 platform cpu spec. > > > You want your avg ping time for 8192 byte payloads to be 300us or less. > > > > 1000/.268 = 3731 IOPS @ 8k = 30 MB/s > > > > If you use apps that do overlapping asynchronous IO you can see better > > numbers. > > Regards, > > JKB -- Ming Zhang @#$%^ purging memory... (*!% http://blackmagic02881.wordpress.com/ http://www.linkedin.com/in/blackmagic02881 -------------------------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
