Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cbmvax!vu-vlsi!dsinc!syd
From: syd@DSI.COM (Syd Weinstein)
Newsgroups: comp.mail.uucp
Subject: Re: New UUCP Protocol (was: Re: Zmodem added to UUCP)
Message-ID: <1989Oct11.020410.27273@DSI.COM>
Date: 11 Oct 89 02:04:10 GMT
References: <1024@faatcrl.UUCP> <710@lakart.UUCP> <1029@faatcrl.UUCP> <688.252e37c2@simpact.com> <1032@faatcrl.UUCP> <25@van-bc.UUCP> <1035@faatcrl.UUCP>
Reply-To: syd@DSI.COM
Organization: Datacomp Systems, Inc.  Huntingdon Valley, PA
Lines: 64

jimb@faatcrl.UUCP (Jim Burwell) writes:
>sl@van-bc.UUCP (Stuart Lynne) writes:
>>This means that if the receiving uucico has been swapped to disk and there's
>>no one there to pull the data out you won't get an overrun. Everything just
>>sits there until uucico swap's back in and acks the received packets. If you
>>run a window size greater than 3 or increase the packet size the tty driver
>>will overrun it's CLIST buffers and dump everything. Then we usually will
>>see a 10 second wait until the sender resends.

>Yike..  !  That sounds like a Unix problem to me though.  I wonder if you can
>code uucico to forbid the OS from swapping uucico (or buffers, or whatever a 
>CLIST is :-) ?  That's scary!  I hope Unix doesn't swap device drivers too! :-).
Ok, now we get to some real stuff, End to End, Zmodem/UUCP-G/UUCP-F are
all fine in abstract, but remember uucp-g was designed for the limitations
of unix.

In the DOS world, the computer is listening all the time and dedicated
to that job at the interrupt level, so running out of buffer space is
not as much of a problem.  In Unix, the uucico program is just that a
user program.  It posts a read, and Unix sets up buffers for that
read, those buffers are called CLISTs or Character Lists.  It just
so happens that Unix was designed to allow a serial port to get
about 256 characters ahead before deciding that the an input overflow
has occurred and then it throws away the entire input queue, remember
Unix is designed for human typists at terminals, so it does output an
overflow message.

Any multitasking O/S has an input queue length that can be exceeded if
the user task is preempted for too long and the input keeps arriving.
Unix choose 256 bytes, it could be tuned, and sometimes intelligent
I/O boards add extra buffering in addition to that 256 bytes.

UUCP g protocol ties in to that 256 byte limit, and in fact the
parameters for g were designed with that in mind.

Its not that the device driver gets locked out, but that the device
driver must store the characters somewhere and it runs out of room
to store them in the buffer (CLIST) preallocated for the read.

Thus on a busy system, ZMODEM is bound to have problems if the
zmodem task (user level task) is preempted for longer than 256
character times.  On a lightly loaded system, its unlikely to stay
prempted for that long.

Also, please remember that end to end times matter, not just CPS.
Much of the time in uucp is dead time deciding which file to transfer
and acquiring permission for that transfer.  With most mail files
being rather short, this is substantial.  A better gain could be
in using BSMTP for mail instead of rmail.  Measure the length of the
phone call for the bytes transferred, and you will see that the 8%
cps improvement might turn out to only be a 1% call time improvement,
and not worth all the extra effort.  Again, long compressed batches
of news skew some numbers, but also remember that many links are limited
by the speed of the computer.  Most sites running at 19200 cannot really
exchange data at that rate, but really at 1100 or 1200 cps, each character
being sent at 19200, but delays between bursts of characters slow it down.
Thus the spoofing of a Telebit actually ends up waiting for the computer
much of the time.

-- 
=====================================================================
Sydney S. Weinstein, CDP, CCP                   Elm Coordinator
Datacomp Systems, Inc.				Voice: (215) 947-9900
syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd	        FAX:   (215) 938-0235