On Wed, Oct 06, 1999 at 08:51:34AM -0600, Ron Lawrence wrote:
> Hello,
> I am trying an experiment with a client connected to a server via a
> software VPN on a dialup connection to see how usable coda will be over
> severely reduced bandwidth connections. My effective speed on the
> connection is approximately 28000 bps, and I cant seem to get coda to
> resynchronize successfully on a particular directory (i.e. lots of
> timeouts, and messages like "connection::bandwidth xxxxxx 520 815 1882 (
> 08:23:22 )" from codacon). I have tried "cfs strong", "cfs wr",
> disconnect/reconnect. Is there some setting/command/configuration to
> make low bandwidth connections work more reliably? I'm using version
> 5.3.1 linux on server and client. Here are some (maybe relevant)
> messages from

Low bandwidth connections still tend to give me headaches sometimes. I
discovered that PPP by default has a very short outgoing queue, and
therefore tends to drop some packets. Also rpc2/sftp are sometimes too
impatient, pite the exponential backoff they sometimes retransmit too
quickly, aggrevating slowness of the link. Another problem that occurs
is that rpc2 times out, but sftp keeps on transferring the rest of the
file. A new rpc2/sftp call will then get interference from the still
ongoing transfer.

In the bandwidth message, the middle number is the estimated average
speed of the link in bytes/second, and on a 28000bps connected I would
normally expect something in the order of 2500-2800.

There are some things that you could try.

venus commandline options (defaults):

 -ws <n>	(32)		Maximum number of outstanding 1kB blocks
				during an sftp transfer.

 -sa <n>	(8)		Number of 1kB blocks sftp pushes into
				the network after receiving an acknowledgement.

 -timeout <n> 	(15 seconds) 	When a reply hasn't been received after this
			       	time, rpc2 considers the server dead.

By reducing the amount of data sftp pushes into the slow link, the rpc2
replies are less likely to get dropped. And by increasing the rpc2
timeout the retransmissions are spread further apart. I believe
multiples of two are preferred (required?) by the sftp protocol, so
something like the following should help.

 venus -ws 16 -sa 4 -timeout 30

Another option is to increase the queue of the ppp device, which I
believe defaults to 10 (packets?).

 ifconfig ppp0 txqueuelen 20

Jan