wtm@uhura.neoucom.EDU (Bill Mayhew) (03/10/90)
My 3b1 has been on a standby power system since late in 1987. The transfer timeof my standby system is about 7 mS, so it doesn't qualify as truly uniterruptible. I do believe the 3b1 power pack has enough ride-through to handle that much of a gap, though. Despite being properly grounded and powered, my 3.51m did lock up once while doing a cpio operation. Looking at /usr/adm/unix.log didn't show any error messges and a subsequent surface scan of the hard disk didn't reveal any bad sectors. Cosmic rays maybe?... The kernel panic printed over top of what was already on the screen, including the meter maid display, so it was rather difficult to get any information from the dump. Another thing I noticed about 3.51m is that it takes 3.51 longer to notice an in-band flow control from the tty000 port. I believe I mentioned that here before. I use a trailblazer plus, but have to support dial-ins at various baud rates (especially myself from my portable peecee at 2400 baud) as well as PEP mode for uucp. Yes Mom, I use hardware flow control from the tb+ to the computer. That works great when the tb+ decides things need to slow down. The problem is when a remote sloth like my peecee clone portable wants to do an in-band flow control. Obviously the modem can't do something brash like convert the xoff to an out-of-band hardware flow control, or binary transfers would be seriously mangled. Now the moral of the story is that things worked correctly with the 3.51 kernel, but 3.51m loses characters when the remote does in-band flow control. Perhaps the incoming queue is longer with 3.51m, thus increasing latency of servicing in-band flow control?... If so, is the queue length adjustible? Apologies if my question is dumb, but I am not an inveterate kernel hacker. Bill -- Bill Mayhew Northeastern Ohio Universities College of Medicine Rootstown, OH 44272-9995 USA 216-325-2511 wtm@uhura.neoucom.edu ....!uunet!aablue!neoucom!wtm