Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!van-bc!sl
From: sl@van-bc.UUCP (Stuart Lynne)
Newsgroups: comp.mail.uucp
Subject: Re: New UUCP Protocol (was: Re: Zmodem added to UUCP)
Message-ID: <25@van-bc.UUCP>
Date: 9 Oct 89 07:27:06 GMT
References: <1024@faatcrl.UUCP> <710@lakart.UUCP> <1029@faatcrl.UUCP> <688.252e37c2@simpact.com> <1032@faatcrl.UUCP>
Reply-To: sl@van-bc.UUCP (Stuart Lynne)
Organization: Wimsey Associates
Lines: 36

In article <1032@faatcrl.UUCP> jimb@faatcrl.UUCP (Jim Burwell) writes:
>
>jeh@simpact.com writes:
>
>gets his news feed over a packet network, and says it's HORRIBLY slow.  Zmodem
>was designed for networks.)  Also, I think we would see a big throughput
>increase with the many PEP modems out there in Unix land.  Even though Telebits
>do all that funky spoofing, it still adds overhead to the transmission.  With

Perhaps if you're talking to your PEP modem at 9600 bps. But not if you are
using 19.2. At that speed uucp with it's overhead should be able to supply
enough data to completely fill the bandwidth available for data between the
two modems (something like 14kbps before compression).

Remember that what two PEP's do to spoof uucp is to talk "g" packet protocol
between the modem and the computer. But simply assume an error free link
between themselves. 

Unless they spoof Zmodem you will probably see a slight drop in throughput
as the modem now has to transfer the Zmodem framing as data. They didn't
have to transfer the uucp framing char's.

On another note, other posters have suggested that the packet size be
increased. One serendipitous property of the current setup of 3 * 64 plus
framing is that all three will fit into the normal amount of room allocated
to a serial port for bufferring in CLIST's (256 bytes).

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.

-- 
Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)