Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!sdd.hp.com!samsung!uunet!comp.vuw.ac.nz!am.dsir.govt.nz!dsiramd!marcamd!tcnz2!greg
From: greg@tcnz2.tcnz.co.nz (Greg Calkin)
Newsgroups: comp.sys.ncr
Subject: Re: Does uucp have to be slow?
Message-ID: <465@tcnz2.tcnz.co.nz>
Date: 23 Oct 90 20:34:35 GMT
References: <4221@lib.tmc.edu>
Reply-To: greg@tcnz.co.nz (Greg Calkin)
Organization: Thomas Cook NZ Head Office, Auckland, NZ
Lines: 29

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 ?