T2500 Flow control, kernel errors, multivolume tar (long)

[Jim Burwell]

Lots of fun questions here! 


Info:  We're running a Sun 3/160, under SunOS 3.5, BSD4.2..


   (1) We have a Telebit T2500 hooked up to the system, which is used for
	    both UUCP Dialin/Dialout, and user Dialin/Dialout.  I have the 
		 inteface speed locked at 19.2K baud between the system and the modem.
		 I think I have everything set up propperly with the modem... UUCP "G"
		 spoofing is on, PEP compression is off, etc, etc.  Everything seems	
		 to be working fine, except our UUCP PEP connection receive rates are 
		 abyssymal!  We're getting about 560-600 CPS.  Part of the problem is 
		 the phone line.  The receive bits per channel register dump averages 
		 about 2 bits/ch.  on our LD line.  But even good lines only get
		 about 1300 CPS, so there's also another problem.  Transmitting on either
		 line gets much better throughput, about 1200-1300 cps, but that's still
		 not that great.  Most people tell me they usually average 1500 cps all
		 around.  While receiving files under the UUCP "G", the RD/SD lights stop        after every 8-10 blocks, then the transfer continues.  Something is 
		 causing the tranfer to momentarily stop.  I have a feeling it is some 
		 kind of flow control being sent from the computer to the modem.  During
		 UUCP connection, I have flow controll turned OFF on the modem.  S58, and
		 S68 are both set to 0.  This should be fine, since the "G" protocol 
		 should take care of flow control, according the Telebit.  The modem will
		 simply stop acking blocks until it catches up.  The modem to computer
		 flow may be another story.  If the UART gets a buffer overflow, then
		 I assume UUCP will NAK (or whatever) the block, which would surely cause
		 the transfer to hiccup for a second or two.  But should that every
		 happen?  19.2Kb isn't that fast for a good UART, esp. if it has a 
		 good size buffer (I have no idea how the serial port on this machine
		 is set up).  Does the Sun's serial port use DMA to get data out of the
		 serial port, or does it rely on the 68020 to pull it out?  Either way,
		 I don't see how we should have a problem with a buffer overflow on the
		 DTE side.  Am I wrong?  
		 At any rate, I'd like to find out how to set up CTS/RTS flow control on
		 the DTE end.  The cables are fine, and the modem can be easily set.  But
		 I have no idea how to set the cuas and ttys to use CTS/RTS, esp. under
		 UUCP.  Setting flow control on most machines I've worked with is 
		 application specific.  Is there a way to permanently set up the port for
		 CTS/RTS under Unix, so all programs use it?


   (2) I periodically get kernal errors on my console which mystify me.  Does
		 anyone know what "text:  table is full" is trying to tell me?  It's
		 not very clear.  It could be applied to anything!  Does it mean the
		 process table is full?  There is no reference to it in any of the
		 man pages, and I couldn't find anything in the couple of manuals I
		 peeked in (I didn't look through EVERYTHING :-).


   (3) I'm looking for a utility which will facilitate a complete system
		 backup over multiple volumes.  We have a 1/4" SCSI tape drive on
		 our system, which, I am told, holds 30 MB (that value seems VERY
		 low for such a large cartridge.. There are tiny cartidges commonly
		 used on PCs which hold 80MB under the right encoding scheme!).  To
		 back up our system, it commonly takes about 5 tapes.  But I don't
		 like Sun's Dump command, because it doesn't seem to give you easy
		 access to individual files.  I'd like to use a more common format,
		 like tar to do our complete dump.  I found a utility called PAX
		 which is documented to do USTAR, cpio, or tar dumps over multiple
		 volumes.  But when I tried to use this, it would get to the end
		 of the tape, and ask me to insert the next one.  When I typed
		 "go", it would prompt me again and again, never proceeding with
		 the backup.  A little while ago, a patch for tar came over the net
		 which supposedly fixed, amoung others, this bug.  But when I tried
		 it with the patch, I eventually got a kernal error
		 "Too many open files", and a core dump.  The patch wasn't a cause
		 of this problem, since I tried the dump with the original unpatched
		 tar, and it did the same thing!  BTW, a bunch of new files and
		 directories (about 18MB worth) had been added to the system in a new
		 partition when I tried the dump w/ and w/o the patch.  This new
		 partition didn't exist before, and we never got that error. 


Well, I hope someone can help me with some of these questions!
Please respond via E-mail, and I'll post a summary if there is "suitable
interest"..

Thank you...