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>