On Tue, 9 Jul 2002, Kevin Lahey wrote:

> On Mon, 8 Jul 2002 11:02:41 -0400 (EDT)
> Andreas Wrede <andreas@planix.com> wrote:
>
> > I am running a Amanda amrecover for a single file on a i386/1.6_BETA4
> > system and the througput through /dev/nrst0 >> amrestore >pipe> gzip
> > -d >TCP> /sbin/restore manages less than 10Kbytes/sec.
> >
> > A tcpdump shows that the ACK is sent 0.2 seconds after the packet it
> > acknowledges:
> >
> > 10:08:06.805509 localhost.amidxtape > localhost.748: P 81920:98304(16384) ack
> > 1 win 16384 <nop,nop,timestamp 99618 1> 10:08:07.005142 localhost.748 >
> > localhost.amidxtape: . ack 98304 win 65535 <nop,nop,timestamp 99619 99618>
> > 10:08:12.005763 localhost.amidxtape > localhost.748: P 98304:114688(16384) ack
> >[...]
> > Does anyone have an idea what is holding things up here?

I'm seeing the same thing with an iscsi target test suite I'm working
with. When the tests get to writing 4k reply packets, this .2 second delay
kicks in.

There are two tests that are illustrative. In both, the tester sends a NOP
PDU (48 bytes) with 4k of attached data. In one case, the target only
sends a reply (48 bytes). In the other, it sends a reply and a copy of the
4k of data. The first test flies along at line speed. The second one gets
hit by the .2 second delay.

> Yup, this is a problem with delayed ACKs.  TCP tries to avoid sending
> an ACK for every packet, so it waits 0.2 seconds to see if another packet
> will be coming in.  Usually this is a win, 'cause lots of packets are
> flowing.  In this case, the problem is that the window size is (probably)
> only 16KB, and after the one packet is sent, nothing more can be done
> until the packet is ACKed, freeing up the window.

At least for what I'm seeing, that sounds stupid. I have a 16k window. I
send 48 bytes. I then can't send 4096 bytes until the 48 are
acknowledged?? I could see that if I wanted to write 16k, I have to wait
(and I have a stupid window size).

But with a 16k window of which 48 bytes are filled, why can't I send 4k?
Sounds like a bug somewhere...

> You could probably work around this by setting the window size to
> greater than 16KB -- I'd go for 128KB at least:

Haven't tried this. But I'd have expected a 16k window is fine for 4k
writes.

Take care,

Bill