arul@sdsu.edu (Arul Ananthanarayanan) (03/03/90)
We are looking for a new machine to replace our departmental time sharer and one of the machines we are considering is a MIPS RC3260. (R3000 @25Mhz) I have had little or no experience with MIPS based products, so naturally I have some questions: 1. Performance: How well does the machine perform under a load? Of course this depends on what you consider a 'load', but assume general University environment with 20 or so concurrent users running TeX, large compiles, heavy number crunching etc. 2. Configuration: Would you recommend buying at least one disk drive from MIPS, or going completely third party? 3. Disk Drives: Have you had any trouble using third party SCSI & 8mm. drives such as Imprimis Wren V,VI, VII etc. or using Exabyte 8mm drives? 4. Maintenance: What type of service contract do you have? How would and Support: you rate field service, board replacement and phone support? 5. OS: Are you able to keep your BSD users happy under Risc/OS? Have you had any major trouble porting applications that assume a 4.3BSD environment while using systype bsd43. 6. Networking: Is Risc/OS a good citizen in that it is easy to get things like the latest versions of gated, sendmail and named up and running without too much effort? I realize that the above list is extensive, but past experience has shown that it pays to be well informed. I have been testing an RC3240 the last few days and I have been very pleased with the performance. Any information would be greatly appreciated. Please send replies by e-mail. I will send summaries to those that request them. Thanks, Arul -- INTERNET: arul@sdsu.edu work: (619) 594-7207 UUCP: sdsu!arul home: (619) 583-0439
hartzell@boulder.Colorado.EDU (George Hartzell) (03/05/90)
In article <1990Mar3.073759.10@sdsu.edu>, arul@sdsu (Arul Ananthanarayanan) writes: > >We are looking for a new machine to replace our departmental time sharer and >one of the machines we are considering is a MIPS RC3260. (R3000 @25Mhz) > This is one of the low-boy cabinet versions of the M-2000, right? We have an M-2000 as our main departmental machine. I should start by saying that I am *mostly* happy with the system. The hardware is *very* dependable. The local MIPS office is *very* helpful. The software (overall) is good, though it does have some problems (however, I don't think that it has any more problems that any other systems). >I have had little or no experience with MIPS based products, so naturally >I have some questions: > >1. Performance: How well does the machine perform under a load? > Of course this depends on what you consider a 'load', but > assume general University environment with 20 or so > concurrent users running TeX, large compiles, heavy > number crunching etc. > We use ours for general TeX and troff stuff, large compiles (MIPS cc and Gnu cc) and computationally intensive biological sequence analysis. Overall we are very happy!!! There are only two cases where I've seen performance suffer: 1) When a large number (e.g. 10+) of compute jobs get started up at once things can slow to a crawl for a minute or so. The common element of these jobs is that they allocate memory like crazy in the initial stages of their life. I think that any system might slow down a bit when faced with this (but am still checking it out). 2) When a program runs out of swap space the entire machine thrashes until it gets rebooted. I've done with with some of our own stuff, and by tickling a bug in MIPS make/ar. I realize that running out of swap space is a problem, but it doesn't seem like it should necessitate rebooting the machine. I think that both of these problems are related to the virtual memory system, and may be corrected/changed in newer releases. We'll see. >2. Configuration: Would you recommend buying at least one disk drive from > MIPS, or going completely third party? We bought one from MIPS and one from third party. MIPS isn't cheap, but it's nice to have them standing behind the main disk. We just bought another Interphase controller from them so that we can put two used Fujitsu Eagles (from our retired Pyramid) on line. Don't know how hard it's going to be. >3. Disk Drives: Have you had any trouble using third party SCSI > & 8mm. drives such as Imprimis Wren V,VI, VII etc. or > using Exabyte 8mm drives? We use SMD drives. Don't know about SCSI on MIPS systems. >4. Maintenance: What type of service contract do you have? How would > and Support: you rate field service, board replacement and phone > support? We have software support and board swap. Getting hardware fixed hasn't been a problem. We had to exchange a DOA ethernet board when we got the machine and haven't had any other problems. Software problems have been more problematical. We had one *serious* problem with NFS that got fixed before it became a critical problem (with a new kernel .o module). Most of our other problems have had to wait for patches or new releases. I've had some good conversations with knowledgeable tech people and some others with under-informed "specialists". Usually the problem is that parts of the support shop have a sysV background, and I tend to break the BSD stuff. >5. OS: Are you able to keep your BSD users happy under Risc/OS? > Have you had any major trouble porting applications that > assume a 4.3BSD environment while using systype bsd43. We are a BSD shop; the SysV base of RISC/os was one of our major concerns. General user programs compile with no problems. Even "systemy" programs, like tcsh (based on 4.3-tahoe csh), compile without too much trouble. I've gotten bash (FSF's sh replacement) and BLSS (a statistics program from Berkeley's math/stat's department [written in Fortran and C]) to compile by telling the config stuff that I was building for a BSD VAX [with some other small changes for BLSS]. Several areas are a pain in the ass though: 1) curses/termcap stuff for BSD is a mess. For example, its idea of an efficient redraw (for an example from a book on curses) is to repaint the entire screen. I punted and just ported the 4.3bsd libcurses and libtermlib. It's a pain 'cause I have to maintain both terminfo and termcap databases, but at least it works. 2) anything that depends on working with an executable file. Stuff that has to work with the files (e.g. undump a core file or dynamically load a .o) can be made to work, with a bit of work. Don't get your hopes up if you want to do any type of compiler work on the machine. Not only do they not use a.out or coff (and the associated debugging info), but they make it very difficult to work with their weird symbol tables. You can't use pseudo-ops in your assembler output (other than for lines and filenames). The only option that I've found (and I haven't tried it yet) is to create their special .T files myself. I wouldn't mind them using something new and different (especially if someone explained why it was better) if they didn't disenfranchise me in the process! 3) terminal (tty/termio) handling can get pretty weird. The common cases work, but sometimes things get trashed. >6. Networking: Is Risc/OS a good citizen in that it is easy to get things > like the latest versions of gated, sendmail and named > up and running without too much effort? We've had few problems with this. See my comments to 5) above. >Any information would be greatly appreciated. I think that my biggest complaint about MIPS is that they don't know the meaning or worth of an OPEN community. They try to control everything for their machines by keeping stuff proprietary that is (formally or informally) common knowledge for other systems (e.g. their object file/symbol table format and the lack of a server and/or client side support in X11R4). The result is that their systems are slightly outside the mainstream of the UNIX community, and don't directly benefit from the richness and experience that the community represents. >Please send replies by e-mail. I will send summaries to those that >request them. I'm posting this 'cause I would like to hear others' comments. Like I said, I am generally content with my system and haven't seen anything else on the market in it's class that I would rather have. Everything I mentioned above except the make/ar funniness has been run past MIPS customer support at one point or another, so there shouldn't be any rude surprises for them. Release 4.5 is reputed to fix/improve a large number of my complaints; I am looking forward to it with great anticipation! g. George Hartzell (303) 492-4535 MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 hartzell@Boulder.Colorado.EDU ..!ncar!boulder!hartzell
rogerk@mips.COM (Roger B.A. Klorese) (03/06/90)
I'd like to add some "informed" detail to some of George Hartzell's points. Obviously, I'm somewhat biased ;-) in Mips' favor... In article <17755@boulder.Colorado.EDU> hartzell@boulder.Colorado.EDU (George Hartzell) writes: > >3. Disk Drives: Have you had any trouble using third party SCSI > > & 8mm. drives such as Imprimis Wren V,VI, VII etc. or > > using Exabyte 8mm drives? > >We use SMD drives. Don't know about SCSI on MIPS systems. We use the Wren IV, Wren VI, and Exabyte ourselves. Check with us on the appropriate firmware revs. > 1) curses/termcap stuff for BSD is a mess. For example, its idea > of an efficient redraw (for an example from a book on > curses) is to repaint the entire screen. I punted and just > ported the 4.3bsd libcurses and libtermlib. It's a pain 'cause I > have to maintain both terminfo and termcap databases, but at > least it works. That's what we've done too. The 4.50 SysV environment uses SVR3.2 terminfo, and the BSD environment uses 4.3-Tahoe termcap. >I think that my biggest complaint about MIPS is that they don't know >the meaning or worth of an OPEN community. They try to control >everything for their machines by keeping stuff proprietary that is >(formally or informally) common knowledge for other systems (e.g. >their object file/symbol table format and the lack of a server and/or >client side support in X11R4). The result is that their systems are >slightly outside the mainstream of the UNIX community, and don't >directly benefit from the richness and experience that the community >represents. We are working on making more of this information available. The symbol table information is documented in the "MIPS Assembly Language Programmer's Guide," though the .T file is not. As for X11R4, we are working on making the mips.cf file for clients available; we should have word soon. On the server side, though, we have a case of "too much too soon": we are working on server enhancements for as-yet-unannounced systems, on X11R4 compatibility, and on performance optimization at the same time. Perhaps larger companies would ship this as a bunch of separate releases. Simply put, we just don't have the bandwidth through our QA/Test/Release group to do this, so we find ourselves "batching" things into larger packages than you (or I, as a user) might like. This will change with growth, I believe. -- ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939 MS 4-02 928 E. Arques Ave. Sunnyvale, CA 94086 rogerk@mips.COM {ames,decwrl,pyramid}!mips!rogerk "I'm the NLA" "Two guys, one cart, fresh pasta... *you* figure it out." -- Suzanne Sugarbaker