From owner-freebsd-current  Sun Jun 25 14:00:37 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id OAA07002
          for current-outgoing; Sun, 25 Jun 1995 14:00:37 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA06996
          ; Sun, 25 Jun 1995 14:00:25 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id GAA06791; Mon, 26 Jun 1995 06:56:52 +1000
Date: Mon, 26 Jun 1995 06:56:52 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199506252056.GAA06791@godzilla.zeta.org.au>
To: bde@zeta.org.au, phk@freefall.cdrom.com
Subject: Re: cvs commit: src/sys/i386/isa sio.c
Cc: bde@freefall.cdrom.com, current@freebsd.org, pete@puffin.pelican.com
Sender: current-owner@freebsd.org
Precedence: bulk

[for slip (and ppp)]
>> 	time rcp machine1:/kernel machine2:/tmp/kernel & \
>> 	time rcp machine2:/kernel machine1:/tmp/kernel &
>> 
>> This takes about twice as long as would separate rcp's because acks get
>> queued behind large amounts of data and arrive too late to keep the data
>> streaming.

>Have you tried making your tcp-windows bigger ?

I tried a smaller tcp_sendspace/tcp_recvspace but that made the problem
worse.

The slowdown is (now) not nearly a factor of 2.  It is from 95 seconds
for rcp'ing in one direction only to 125 and 125-136 seconds (the
slowdown is sometimes asymmetrical).  With a tcp_sendspace/tcp_recspace
of 32K instead of 16K, the slowdown is less (to 110 and 128 seconds).
With large windows, transmission works OK for a while, then both sides
sometimes stop sending for a second or two, then each side takes turns
transmitting, then transmission works OK...  With small windows, this
cycle repeats more often.

The problem is more obvious at lower line speeds.

Bruce