From: km@mathcs.emory.edu (Ken Mandelberg)
Newsgroups: comp.mail.uucp,comp.sys.sun.misc,comp.unix.internals,comp.dcom.modems
Subject: UUCICO is system intensive
Date: 8 Apr 92 14:35:48 GMT
Article-I.D.: emory.8669
Reply-To: km@mathcs.emory.edu
Followup-To: comp.mail.uucp
Organization: Emory University, Dept of Math and CS

I've been surprised to see that UUCICO uses quite a bit of system time,
and have done some traces to see why. We are running "g" protocol with
a window size of 3 and 64 byte packets.

What I see is this. Once the window is full for each 64 bytes of data
transferred there is of course a minimum of two system calls, a 70 byte
write (64+header) and a 6 byte read (the ACK). For reasons that may or
may not be special to us, the 6 byte read typically breaks up into two
reads a 1 byte read and a 5 byte read. Each "read" is surrounded with
an "alarm" for timeout. These days alarm is a library routine that
yields a total of 8 system calls per read (setitimer, sigblock,
sigstack, sigblock, sigvec, sigvec, sigsetmask, setitimer) for each
read.

If you count it up, for each 64 bytes written there are 19 system
calls.  Even if the 6 byte read was done in one shot, this would be 10
system calls for every 64 bytes of data.

I have traced both 4.3BSD and HDB (the SunOS version, roughly SVR3)
UUCICO, and see roughly the same trace pattern. The BSD uucico seems to
yield sys time at about 14% of real time for long transfers.
Surprisingly, although the trace pattern looks the same to me, HDB
gives me sys time as 2% of real time. In either case user time is under
1% of real time. For logistical reasons, I cannot run the BSD and HDB
tests on the same system so this comparision may be flawed. Both
systems are Sun 6XX machines with 4 processors, but the HDB tests are
on a quiet system while the BSD tests are on a busy one.

The high system load in UUCICO is a problem for us. SunOS still runs an
asymmetric kernel, so system cycles are scarce even on a 4 processor
machine. Half a dozen simultaneous UUCICO's put a big load on a 690.

The three questions in my mind are:

1) Could UUCICO be better optimized? The alarms being set/unset for
each read are several seconds long. At PEP modem speeds, 10's of
packets should be sent a second. Setting and unsetting a 4 second alarm
once (or twice) a packet seems too expensive. I would think the thing
to do is use the System V termio VMIN/VTIME for short timeouts, with a
longer no-activity "alarm" not set per packet. (VMIN/VTIME does not
handle really handle the no activity case).

2) Does HDB really use less system time than BSD UUCICO? My timing
seems to show a significant difference, though I can't account for it
from the trace.  My timings may be flawed.

3) Is the break up of the 6 byte read into 1+5 normal? It always reads
the \10 by itself.

By the way, we run UUCP out over ethernet to an Annex terminal server
that handles a bank of Telebit T2500s running PEP. We are stuck running
protocol "g" with 64 byte packets because thats what PEP will spoof.
Larger packets would help a lot. However, even if we didn't run PEP the
target systems probably couldn't handle large packets anyway. I sure
wish the Telebits would spoof large packets on one side and 64 byte
ones on the other. Its internal transfer protocol has large packets
anyway.



---
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {rutgers,gatech}!emory!km    UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: Voice (404) 727-7963, FAX 727-5611
Newsgroups: comp.mail.uucp