[comp.sys.ncr] Does uucp have to be slow?

jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (10/23/90)

In the process of getting my shiny new Tower XP running, I need to transfer
about 30 meg of data from my current PC/AT system. My options are 360K PC-DOS
disks (yuk!) or uucp over a serial cable. Of those two, I'd much rather do
uucp. I'm running SysV 3.02.01, without the HDB enhancement (I have it, but
haven't installed it), and an octal I/O board (not the HPSIO :-( ).

I was able to get the two machines talking. There are two problems: 1) It
won't run over 1200 BPS, and 2) it won't run for more than a few hours. In
both cases, the failure mode is the same: The AT (running Microport System
V/AT 2.4, with HDB) eventually hangs, and, if I used Uutry to start the
connection, reports an "alarm 1". The Tower simply gives up, leaving the
status "CONVERSATION" in the STST.* file. I have to reboot the AT to clear
out the uucico process.

I have the AT set up to initiate the connection, and the Tower has the port
defined to be a dial-in port (it's /dev/tty00, if that matters). I haven't
tried running it the other way yet.

Any suggestions out there? Should I have the Tower call the AT? Should I jump
through the hoops required to get HDB on the Tower (I don't expect the
installation to be difficult, but getting the file to the Tower may be)?
Do I need to scrounge an HPSIO? Who killed Laura Palmer? :-)

Thanks in advance...
BTW, if anyone has doubts about the value of Usenet, just ask a technical
question. You'll see the value in no time! :-)
-- 
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jmaynard@thesis1.hsch.utexas.edu  | adequately be explained by stupidity.
"It's a hardware bug!" "It's a    +---------------------------------------
software bug!" "It's two...two...two bugs in one!" - _Engineer's Rap_

shwake@raysnec.UUCP (Ray Shwake) (10/23/90)

jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes:

>I was able to get the two machines talking. There are two problems: 1) It
>won't run over 1200 BPS, and 2) it won't run for more than a few hours. In
>both cases, the failure mode is the same: The AT (running Microport System
>V/AT 2.4, with HDB) eventually hangs, and, if I used Uutry to start the
>connection, reports an "alarm 1". The Tower simply gives up, leaving the
>status "CONVERSATION" in the STST.* file. I have to reboot the AT to clear
>out the uucico process.

	Question: Are we talking about multiple files totalling ~30 MB
or one large file? Both the NCR and Microport may have a ulimit set down
in the 2 MB range (uPort's old default). I'd run my old uPort 2.3 with
HDB regularly at 2400 baud, passing many megabytes without problem provided
I didn't exceed the ulimit. "alarm" messages can have many causes, any of
which can represent failure to send or receive a packet. Connect the two
boxes serially if you can; if that works, push the speed higher.

>Any suggestions out there? Should I have the Tower call the AT? Should I jump
>through the hoops required to get HDB on the Tower (I don't expect the
>installation to be difficult, but getting the file to the Tower may be)?

	HDB UUCP is a wonderful enhancement to the standard version.
Install it unless you are aware of problems with NCR's implementation.

greg@tcnz2.tcnz.co.nz (Greg Calkin) (10/24/90)

In article jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes:
>I have the AT set up to initiate the connection, and the Tower has the port
>defined to be a dial-in port (it's /dev/tty00, if that matters). I haven't
>tried running it the other way yet.
>
>Any suggestions out there? Should I have the Tower call the AT? Should I jump
>through the hoops required to get HDB on the Tower (I don't expect the
>installation to be difficult, but getting the file to the Tower may be)?
>Do I need to scrounge an HPSIO? Who killed Laura Palmer? :-)

Best bet - Try using /dev/ttya. It is higher up the interrupt chain and gets
better servicing. Keep the Tower as Dial-in for ttya (it will work ok as dial
up).

Try batching the data slightly to give the port a short rest periodically.

If the tower has more than one octal port, balance the load between them.
I know this affects performance for HPSIO's. I think it was relevant for
Octals too.

Trying changing the number of bits / stop bits / parity bits.

Try changing protocols between hardware handshaking and software handshaking.

"I'm but an Aviator now, Atlas take me in your arms and fly" Ricky Lee
-- 
Greg Calkin, Systems Engineer and Dreamer                    (greg@tcnz.co.nz)
Thomas Cook N.Z. Limited, PO Box 24, Auckland CPO, New Zealand, Ph (09)-793920
Disclaimer : Would you buy a used car from someone with these opinions ?

Vernon@holos0.ogi.edu (10/24/90)

> 
> In the process of getting my shiny new Tower XP running, I need to transfer
> about 30 meg of data from my current PC/AT system. My options are 360K PC-DOS
> disks (yuk!) or uucp over a serial cable. Of those two, I'd much rather do
> uucp. I'm running SysV 3.02.01, without the HDB enhancement (I have it, but
> haven't installed it), and an octal I/O board (not the HPSIO :-( ).
> 
> Any suggestions out there? Should I have the Tower call the AT? Should I jump
> through the hoops required to get HDB on the Tower (I don't expect the
> installation to be difficult, but getting the file to the Tower may be)?
> Do I need to scrounge an HPSIO? Who killed Laura Palmer? :-)
> 
> 
> 
Having no experience with this specific problem I will just confirm
a few of your suggestions.  With what little experience I have had
with an octal board, I believe this is your biggest problem.  If you
can scrounge up a HPSIO you will be able to run at 19200 Baud as
as well as possibly eliminating your hang up problem.

jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (10/24/90)

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

vause@cs-col.Columbia.NCR.COM (Sam Vause) (10/25/90)

In article <4221@lib.tmc.edu> jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes:
>In the process of getting my shiny new Tower XP running, I need to transfer
>about 30 meg of data from my current PC/AT system. My options are 360K PC-DOS
>disks (yuk!) or uucp over a serial cable. Of those two, I'd much rather do
>uucp. I'm running SysV 3.02.01, without the HDB enhancement (I have it, but
>haven't installed it), and an octal I/O board (not the HPSIO :-( ).
>
>I was able to get the two machines talking. There are two problems: 1) It
>won't run over 1200 BPS, and 2) it won't run for more than a few hours. In
>both cases, the failure mode is the same: The AT (running Microport System
>V/AT 2.4, with HDB) eventually hangs, and, if I used Uutry to start the
>connection, reports an "alarm 1". The Tower simply gives up, leaving the
>status "CONVERSATION" in the STST.* file. I have to reboot the AT to clear
>out the uucico process.
>
>I have the AT set up to initiate the connection, and the Tower has the port
>defined to be a dial-in port (it's /dev/tty00, if that matters). I haven't
>tried running it the other way yet.
>
>Any suggestions out there? Should I have the Tower call the AT? Should I jump
>through the hoops required to get HDB on the Tower (I don't expect the
>installation to be difficult, but getting the file to the Tower may be)?
>Do I need to scrounge an HPSIO? Who killed Laura Palmer? :-)
>
>Thanks in advance...
>BTW, if anyone has doubts about the value of Usenet, just ask a technical
>question. You'll see the value in no time! :-)

Trust me, you *WANT* to get an HPSIO board into that system.

Verify whether your system has a 9-pin RS-232 connector(s), or whether it
has 15-pin.  The only difference for the HPSIO upgrade is that if you 
already have the 15-pin ones, you are spared the hassle ordering the 
TTY bulkhead plate itself.  In any case, you get the joy of ordering 
and installing the HPSIO-to-Bulkhead cables.  Lotsa' little screws!

The HPSIO will allow you to speak at least 9.6K baud to the AT...
+---------------------------------------------------------------+
|Sam Vause, NCR Corporation, Customer Services - TOWER Support  |
|3325 Platt Springs Road, West Columbia, SC 29169 (803) 791-6953|
|                                vause@cs-col.Columbia.NCR.COM  |
|                         ...!uunet!ncrlnk!ncrcae!cs-col!vause  |
|                ...!ucbvax!sdcsvax!ncr-sd!ncrcae!cs-col!vause  |
+---------------------------------------------------------------+

jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (10/27/90)

Further update: I got 25 of 30 meg transferred via the serial link, but
couldn't get the last big file. Finally I gave up, uuencoded it (it was a
compressed cpio archive), split it into 345K chunks, and used PC disks to
move it (*sigh*). It's now all there. Now all I have to do is figure out how
to not have to run my modem link at 1200...Craig Macbride (did I get it right
this time? :-) suggested that I need all 7 signal lines when talking fast to
the PMC ports, but I did away with the need before trying that. (The cable I
had been using was only 4 wires plus ground.) That won't help with the modem,
though, since it's a (relatively) dumb US Robotics Courier 2400, and has no
buffering. I suppose I could build up a little buffer box with 8K of RAM or
so...wonder how that would work on a uucp link?

In article <1990Oct25.002637.2437@cs-col.Columbia.NCR.COM> vause@cs-col.Columbia.NCR.COM (Sam Vause) writes:
>Trust me, you *WANT* to get an HPSIO board into that system.

No doubt...it would have made all this a *LOT* easier. Still, laying hands on
one is bound to be non-trivial...

>Verify whether your system has a 9-pin RS-232 connector(s), or whether it
>has 15-pin.  The only difference for the HPSIO upgrade is that if you 
>already have the 15-pin ones, you are spared the hassle ordering the 
>TTY bulkhead plate itself.  In any case, you get the joy of ordering 
>and installing the HPSIO-to-Bulkhead cables.  Lotsa' little screws!

Oh well...guess I have an early frame, then, since it has the 9-pin connectors
and the version 1 (tall...reaches right up to the LIM rack) power supply.
More fun.
-- 
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