🚀 go-pugleaf

In article <1k1930INN2nl@ftp.UU.NET> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:

	[ ... remaining preceeding discussion deleted ... ]

>It's been my experience, though, that most of the throughput problems
>encountered by UUCP users stem from the awful parameters used by most
>UUCP implementations, not from compression problems.  64-byte packets
>are fine if you're sending data at 1200bps or even 2400bps, but at
>V.32bis and PEP speeds it really creates a problem.  The latency of
>fast modem links is such that the ACKs can't get back to the sending
>computer before it runs out of data in the window, and thus the it
>winds up sitting around for the ACK to travel over the wire back to
>your computer.  In addition, using small packets means that UUCP has
>to do numerous small individual writes, generating a lot of overhead
>and context switches.
>
>What you want to do is get a version of UUCP on both ends that can use
>big -- 512-byte or 1024-byte -- packets.  By using larger packets, you
>eliminate the latency problems, and also increase efficiency by
>allowing uucico to make fewer write(2) system calls.
>
>Unfortunately, most stock versions of UUCP don't support big packets.
>To my knowledge, the only stock version that *does* is the HDB UUCP
>distributed with SVR4.  If you don't have SVR4, you'll have to get
>Taylor UUCP and build it for your OS.  Of course, there are lots of
>other reasons to get Taylor UUCP; I replaced the SVR4 UUCP on my
>system even though it *could* handle big packets.

	This advice may be good for general use, but not in this individual
case.  Remember that the original poster was asking about the case of a
Sun-3 as his news machine.  There have been many debates in various
comp.sys.sun.* newsgroups about the serial ports and the drivers in the
Suns. If you go to a uucp that allows 7 windows and 1K packets (and are
running 19200 baud), you are probably going experience a *drop* in
throughput.  The problem is that the combination of chip and drivers does
not properly handle the case of the CPU needing to tell the modem that it is
about to overflow its buffers.  You will get lots of "silo overflow"
messages, and lots of retries.  I forget the actual packet size, but in one
of the discussions, it was shown that a large enough packet size at 19200
will ensure that there is a 0% effective throughput, becuase it will
overflow the internal buffers every time.  (Well, very small files will get
through, but anything using the full buffer will just waste connect time.)

	This is made worse by compression on files that acutally work,
especially with higher port speeds, because while the modem is moving only a
certain number of bytes/second, if it is uncompressing those bytes, and then
spitting them at the CPU, the load is even worse.

	If you really need reliable uucp transfers at high speeds, it seems
that the choices are to use some of the SCSI-interfaced serial ports, or an
ethernet terminal server, both of which bypass the internal serial drivers
and chips.  (It is not sure whether a better driver is worth the trouble
with the existing chips, and the chips are part of the design of the CPU
card, rather than being a plug-in card.  (Apparently, even the s-bus cards
for the SPARC machines are not that much of an improvement.)

	( As I am also using a Sun-3 as a news server at home, I may be in
the market for a SCSI serial board or a ethernet terminal server when I see
the first full month's bill from uunet. :-)

	Good Luck
		DoN.
-- 
 Email:   <dnichols@d-and-d.com>  |  ...!uunet!ceilidh!dnichols 
		 <dnichols@ceilidh.beartrack.com>
 Donald Nichols (DoN.)  |   Voice (Days): (703) 704-2280 (Eves): (703) 938-4564
	--- Black Holes are where God is dividing by zero ---