mike@bu-cs.UUCP (03/05/87)
Please let me know what you know about the reliability of the Iris Silicon Graphics workstations. I heard that the system reliability is very low via rumor posted on INFO - IRIS. Please let me know as reliability is an issue and we may purchase shortly.
brunner@sri-spam.UUCP (03/05/87)
In article <4916@bu-cs.BU.EDU> mike@bucasb.UUCP (Michael Cohen) writes: >Please let me know what you know about the reliability >of the Iris Silicon Graphics workstations. I heard that >the system reliability is very low via rumor posted on >INFO - IRIS. Please let me know as reliability is an >issue and we may purchase shortly. I don't read INFO - IRIS, sorry I can't scan your rumor. When I worked at SGI the 3030 model (68020 w/ large disks) in my office failed _very_ frequently, like twice a day - here failure is defined as a _very_ reliable hardware _freak_ event, thought to be due to design errors in the power subsystem, no, bogus disk controllers, no,... there was no known answer before I left the company. Most of the 10 or so new machines in the same area of the company (kernel group) were equally eventfull. We all sighed and rebooted, hardware was not our dept... Please note that this was the view of a neo-dozen production machines of the 3030 model, all with a similar date of production, summer 1986, and all kept with in a small portion of the 2nd floor of the engineering bldg of the Stierlin Road site. Maybe they got fixed, maybe you are referring to some other model. I would look elsewhere, of course, my reasons are not necessarily the same as yours. I take into consideration the system software because that seems to me as important as the window manager and the pixel painting primitives Due to the SGI-only XNS dependency, and the TCP-on-a card of the 1986 IRIS, it is a very hard machine to use in a distributed workstation environment, where some of the workstations just happen to be very sharp color graphics boxes. I think that is what is important in my site's long term, and in just about any hetrogeneous, open site, so I don't think about the IRIS seriously. I'm making that point to the Navy - who wish to use it for a _very_ snazy mailer system - they saw the SGI demos, not the network nor the "useability". -- how about a great big spidery "X"?
msc@ramoth.SGI.COM (Mark Callow) (03/07/87)
The following views are my own. I am not an official voice of SGI. In article <9914@sri-spam.istc.sri.com>, brunner@sri-spam.istc.sri.com (Thomas Eric Brunner) writes: > When I worked at SGI the 3030 model (68020 w/ large disks) in my office > failed _very_ frequently, like twice a day - here failure is defined as a > _very_ reliable hardware _freak_ event, thought to be due to design errors > in the power subsystem, no, bogus disk controllers, no,... there was no > known answer before I left the company. > Please note that this was the view of a neo-dozen production machines of the > 3030 model, all with a similar date of production, summer 1986, and all kept I have a production 3030 delivered to me in November '86 shortly after I started working here. I have had 2 hardware problems: a bad memory board a week after delivery and a problem with the cartridge tape drive. I have had no hardware related crashes except those caused by parity errors in the bad memory board prior to its replacement. Here is the uptime(1) output for my Iris. 2:51pm up 11 days, 4:09, 7 users, load average: 0.19, 0.24, 0.20 The last rebooted was for a new kernel. > Due to the SGI-only XNS dependency, and the TCP-on-a card of the 1986 IRIS, > it is a very hard machine to use in a distributed workstation environment, > > I think that is what is important in my site's long term, and in just about > any hetrogeneous, open site, so I don't think about the IRIS seriously. > I'm making that point to the Navy - who wish to use it for a _very_ snazy > mailer system - they saw the SGI demos, not the network nor the "useability". > -- My 3030 (Ramoth) has 4.3bsd's tcp code in its kernel and all of the 4.3 network utilities available. I have no knowledge of the above mentioned tcp on a card. Ramoth is connected to a large network of Irises, Suns and Vaxes. and is also running nfs. I'm using it to read news right now. I see no problem with interoperability. Our famous network dogfight program has even been converted to use tcp. Enough said? The bottom line is find out the facts before making decisions. Do not rely on rumors and out of date memories and hearsay. -- From the TARDIS of Mark Callow msc@sgi.sgi.com, sgi!msc@decwrl.dec.com ...{decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its contents.
dave@onfcanim.UUCP (03/10/87)
In article <9914@sri-spam.istc.sri.com> brunner@sri-spam.UUCP (Thomas Eric Brunner) writes: > >Due to the SGI-only XNS dependency, and the TCP-on-a card of the 1986 IRIS, >it is a very hard machine to use in a distributed workstation environment, >where some of the workstations just happen to be very sharp color graphics >boxes. Until the current (3.5) release, TCP was done via some code that was downloaded into the Ethernet controller. It was a dog - we were pushing a lot of data through the ethernet, and the controller (or just a current TCP connection) would hang quite regularly. We actually had to have a background process that would detect a hung connection and reboot the machine in order to get it back. It was slow too - about half the throughput of XNS. We eventually switched back to XNS, even though getting SGI's binary distribution of their 4.2BSD XNS driver to work with our modified 4.2 kernel was a lot of work. The current version of TCP is in the UNIX kernel, not the Excelan one. Also, SGI has switched to TCP as their standard protocol, making XNS an option.