Path: utzoo!attcan!uunet!samsung!usc!wuarchive!bcm!lib!thesis1.hsch.utexas.edu
From: jmaynard@thesis1.hsch.utexas.edu (Jay Maynard)
Newsgroups: comp.sys.ncr
Subject: Re: Does uucp have to be slow?
Message-ID: <4230@lib.tmc.edu>
Date: 24 Oct 90 15:52:57 GMT
References: <4221@lib.tmc.edu> <110@raysnec.UUCP>
Sender: usenet@lib.tmc.edu
Organization: University of Texas Medical School at Houston
Lines: 30
Nntp-Posting-Host: thesis1.hsch.utexas.edu


An update:
Craig McBride (where's rmit.oz.au, anyway? :-) suggested that I try using
the other processor port, /dev/ttya, as it would handle faster speeds. That
That didn't work, unfortunately...I got the same results.

I then installed the HDB upgrade to the Tower, so both systems are now running
HDB UUCP. That didn't fix it either.

Finally, in an attempt to nail down some more info, I launched Uutry on the
AT with -x9 specified instead of the default -x5. The test was at 2400 BPS,
talking to /dev/ttya on the Tower. -x5 failed within a few seconds with the
'alarm 1' message...but -x9 ran for quite a while before stopping. I could
see on a breakout box inserted in the line that there was a slight pause
between transmitted packets. I restarted it and drove off to work; I don't
know what I'll find when I get home. This result leads me to believe that the
problem is a character overrun on the Tower.

I have patched the Microport system for a ulimit of 16 MB, though I don't know
what the default ulimit on the Tower is. The transfer is failing well before
a megabyte has been sent, though. The 30 MB is in a number of files, but only
one is over a meg (it's about 5 meg).

Anyone have any more ideas? I've run the AT successfully for a couple of years
doing fairly heavy UUCP at 2400, so I don't suspect it. I hope I don't get
stuck slowing the links down to 1200...
-- 
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jmaynard@thesis1.hsch.utexas.edu  | adequately be explained by stupidity.
         "With design like this, who needs bugs?" - Boyd Roberts