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?

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.

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

	# sysctl -w net.inet.tcp.sendspace=131072
	# sysctl -w net.inet.tcp.recvspace=131072

I have to admit I was a little curious about why you were doing TCP
between processes on the same host -- you probably wouldn't have had
this problem if you were sending to another host over the net.
(I don't know anything about amrestore (or restore, for that matter)
so I apologize if I'm missing something obvious...

Another way to fix it would be to come up with a way to ensure that
gzip writes in blocks of about 8KB.

Hope this helps, and I'm sorry I didn't answer in time to save you
the trouble of redoing the job,

Kevin
kml@mobiquitous.net