Re: Network very very slow... was iSCSI and jumbo frames

[BERTRAND Joël <joel.bertrand%systella.fr@localhost>]

Michael van Elst a écrit :
> On Fri, Feb 05, 2021 at 12:44:26PM +0100, BERTRAND Joël wrote:
> 
>> 	With or without -c, I haven't understood how this initiator works. It
>> always aborts with error (but only returns to shell prompt after a ^C).
> 
> It's based on demo-code and lacks lots of features. It works somewhat
> with the iscsi-target (from the same demo-code). It's the same code
> that also exists in pkgsrc.
> 
> The in-kernel iscsi initiator together with istgt is a much better
> combination.
> 
> Please try this again, with istgt serving the raw device, not the block
> device. That's how everyone else is using it without problems and good
> performance.

	I have created a 100Go partition on ccd0 (I don't have other available
device, ccd0 is built with wd2 and wd3). This partition is exported by
istgt (/dev/rdk6). I don't know why I cannot export this device on
loopback, it is exported on agr0 address.

[ 59192.990116] dk6 at ccd0: "test", 209715200 blocks at 287309864,
type: ffs
[ 60737.494885] scsibus1 at iscsi0: 1 target, 16 luns per target
[ 60737.494885] sd1 at scsibus1 target 0 lun 0: <NetBSD, iSCSI DISK,
0001> disk fixed
[ 60737.494885] sd1: fabricating a geometry
[ 60737.494885] sd1: 100 GB, 102400 cyl, 64 head, 32 sec, 512 bytes/sect
x 209715200 sectors
[ 60737.494885] sd1: fabricating a geometry
[ 60738.195145] sd1: async, 8-bit transfers, tagged queueing

estd is disabled and launched from terminal to set CPUfreq.

First test : CPUfreq=3400 MHz
legendre# dd if=/dev/zero of=/dev/sd1 bs=1m count=10000
10000+0 records in
10000+0 records out
10485760000 bytes transferred in 71.937 secs (145763098 bytes/sec)

Second one : estd is kept with its standard configuration.
CPUfreq seems to stay at 800 MHz.
legendre# dd if=/dev/zero of=/dev/sd1 bs=1m count=10000
10000+0 records in
10000+0 records out
10485760000 bytes transferred in 79.456 secs (131969391 bytes/sec)

	Throughput is a little bit lower but remains decent.

> If that works, we can look why there is a problem together with the
> qnap target.

	JKB