Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site allegra.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!allegra!mp
From: mp@allegra.UUCP (Mark Plotnick)
Newsgroups: net.bugs.uucp
Subject: Re: 4.2 uucp performance problems?
Message-ID: <3007@allegra.UUCP>
Date: Wed, 6-Feb-85 10:20:03 EST
Article-I.D.: allegra.3007
Posted: Wed Feb  6 10:20:03 1985
Date-Received: Thu, 7-Feb-85 04:02:22 EST
References: <1363@hao.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 25

Check if your neighbors are running the speedup hack in pkcget() that sleeps
for 1 second if the read() doesn't return the full number of characters
requested.  I'm told this scheme was intended to reduce the load on the cpu,
at the expense of a slower transfer rate.  We looked and saw that we were
getting a transfer rate of between 75 and 80 cps for many machines, and a
whopping 36cps when sending to machines like vortex.   Honeyman came up with
a fix so that instead of sleep()ing, uucico nap()s for a time equal to
(time it takes 1 char to come in at line's baud rate) x (# of chars left to be read in)

We now get transfer rates of 90 to 108 cps with most machines.  vortex is
up to 80cps.

Since uucp here typically spends over 20 hours a day on the phone,
cutting down on the transfer time (and our phone bill) was more
important than being nice to the cpu; besides, sendmail and uux each take more
cpu time just to queue a typical message than uucico takes to transmit it.

We still have a spurious problem when we call a 4.2bsd site, send some
files, and change roles; sometimes the transfer rate drops to 10 cps
(one time it was 3cps).  I have no idea what the fix would be, but from
looking at an audit the problem appeared to be a protocol botch
resulting in lots of retransmitted packets.

	Mark Plotnick
	allegra!mp