larry@nstar.rn.com (Larry Snyder) (12/23/90)
cpcahil@virtech.uucp (Conor P. Cahill) writes: >In article <2710@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: >> I would go with Xenix. It's not remotely state of the art, but it is >>well tested and very reliable. I'm painfully aware that more modern >>systems, and most versions of V.3.2, are not quite as reliable. It >>supports multiport serial very well, it supports TCP if you don't need >>NFS, and is generally a good solution to your particular problem. >I have found System V R3.2.2 (ie latest releases from the respective >vendors) to be very reliable. The only panic's we have had in the past >year have been due to memory problems. The only reboots we have had to >do have been because of a hung archive tape drive (that's archive's problem >not the OS). We bang the hell out of our system and have had it up for >months at a time with no problems. I agree with Conor - I can't image anyone with the hardware resources these days wanting to go with Xenix. If he has 10 grand (I believe that was the amount) to work with - he could put together a screamer Unix based system with FAST SCSI drives. The Xenix file system is so very slow - and the chance that continued development for third party applications is grim. >>| 3. disk controller? Adaptec 1740? >> >> Garder variety ESDI. Use two drives to improve performance. I will >Two drives does not get you that much performance improvement on ESDI. However >it does get you much more with a SCSI system. I would recommend SCSI (perhaps >adaptec 1542, or bustek equivalent) especially if the OS you choose is >ISC (because ISC has highly optimized SCSI performance). Again, I agree with Conor - a pair of SCSI drives that support SYNC transfers will scream past all the ESDI systems I've seen (including the 15m variety).. >The additional benefit of SCSI is that the tape drive can use the same >controller (thereby saving costs of the controller and saving precious >slots and interrupts). Plus - DAT and optics - and lots of devices without the need to add another controller.. >>| 4. 16 port serial card? >> >> Two 8's. You might find performance a hair better one way or the >>other, but redundancy says use two, and there's no drawback I can see. >>*Smart* cards, please. >I would recommend a single card. (Slots are precious commodities, don't >waste them). The card I like best (and of course this is just personal >opinion) is the Megaport-24. I don't have enough experience with this to comment.. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar.rn.com, uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
larry@nstar.rn.com (Larry Snyder) (01/03/91)
bill@unixland.uucp (Bill Heiser) writes: >In article <1990Dec23.113905.4278@nstar.rn.com> larry@nstar.rn.com (Larry Snyder) writes: >> >>The last thing I heard about arnet boards is that they had >>problems supporting bidirectional communications for a bank >>of modems locked at 38,400 bps using only hardware flow control >>under Interactive Unix. >> >Speaking of hardware flow control ... My new AST 4-port board has an >option for setting enabling hardware flow control. When initasy is >run (on Esix), that's one of the questions that is asked. There's >also something about a "flow control register." Neither of these >is documented well (if at all) in the AST board documentation. What's >your recommendation on this? Use hardware flow control (if it works). Try turning it on in the modem, and in the driver (FAS?). Then try downloading then uploading a file using zmodem at both a high speed and a 2400 baud connection - with the DTE locked at either 19200 or 38400. If you get a flawless transfer (no errors) then you should be all set - however - if flow control isn't working - you will sure enough see errors.. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {..!uunet!mailrus!iuvax!ndcheg!nstar!larry, larry%nstar@ndcheg.cheg.nd.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)