Subject: Re: Very slow pipe/TCP connection in 1.6_BETA4
To: None <email@example.com>
From: Takahiro Kambe <firstname.lastname@example.org>
Date: 07/10/2002 08:54:43
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
o 1.6BETA4 client and server.
o DDS4 drive.
1.5.3 has no problem.
In message <email@example.com>
on Tue, 9 Jul 2002 12:49:46 -0700,
Kevin Lahey <firstname.lastname@example.org> 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 <email@example.com>