Hi.

I feel 1.6BETA4 is slow for remote dump, too.  For me, about 700KB/s
over 100BASE-TX though locally dump(8) to the tape rates about
2000KB/S.

o 1.6BETA4 client and server.
o DDS4 drive.

1.5.3 has no problem.

In message <20020709124946.50b822b6.kml@mobiquitous.net>
	on Tue, 9 Jul 2002 12:49:46 -0700,
	Kevin Lahey <kml@mobiquitous.net> wrote:
> 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:
Dump(8) itself set SO_SNDBUF/SO_RCVBUF corresponding to block size (-b
option).  Since If someone use "-b 64", socket buffer should be
already greater than 16KB.

It seems that rmggetconn() set maximum 62K for SO_SNDBUF/SO_RCVBUF,
but I don't check exactly size of sockte buffer really set.

-- 
Takahiro Kambe <taca@sky.yamashina.kyoto.jp>