jimb@faatcrl.UUCP (Jim Burwell) (08/09/89)
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...