Origin200, R10000SC 180MHz (1MB L2) CPU, 256MB RAM, 9GB The system disk is a 9GB 10000 rpm Seagate Cheetah. 1 180 MHZ IP27 Processor CPU: MIPS R10000 Processor Chip Revision: 2.6 FPU: MIPS R10010 Floating Point Chip Revision: 2.6 Main memory size: 256 Mbytes Instruction cache size: 32 Kbytes Data cache size: 32 Kbytes Secondary unified instruction/data cache size: 1 Mbyte Integral SCSI controller 0: Version QL1040B (rev. 2), single ended Disk drive: unit 1 on SCSI controller 0 Integral SCSI controller 1: Version QL1040B (rev. 2), single ended CDROM: unit 3 on SCSI controller 1 Integral SCSI controller 2: Version QL1040B (rev. 2), differential IOC3 serial port: tty1 IOC3 serial port: tty2 IOC3 parallel port: plp1 Integral Fast Ethernet: ef0, version 1, module 1, slot MotherBoard, pci 2 Origin 200 base I/O, module 1 slot 1 IOC3 external interrupts: 1 I connect to my Origin200 via a 100Mbit link from an O2 using rlogin, etc. The connection is via a Bay Netgear 16-port autosensing 10/100 switch (model FS116), full-duplex 200Mbit connection (this is an excellent switch for home use due to it's very low price: just 178 UKP). A ttcp test gives 11MB/sec both ways simultaneously, so the connection is ideal for running rlogin GUI-based tasks across a network link - by comparison, tasks such as GIMP can run significantly slower if the link is only 10Mbit (eg. Indy, Indigo2, etc.), probably because the Origin200 can't send visual X updates fast enough, such as redrawing the image currently being worked on. For example, have a look at the Filters/Distorts/Ripple test for this system on my performance page: http://sgi-tech.unixology.com/perfcomp.html#IMG1 The result is 2min 31secs, but when I ran the same test originally across just a 10Mbit link (from an Indigo2) the result was 3mins 6secs! That's about 20% slower, which is enough to wipe out the benefit of using an Origin200 in the first place, ie. sometimes GIMP can't continue processing until the image has been redrawn. Thus, having a remote crunching system like Origin200 is a great idea, but if there is any GUI action involved then it's best to access the system using a 100Mbit link. Realistically, this means using something like an O2 for the graphics head in terms of available 2nd-hand SGI hardware (it's much harder to find an Indy or Indigo2 with 100Mbit option card). However, if the task is just a command line action then it doesn't matter, eg. rendering commands, dmconvert commands, image processing scripts using Graphics Library Image tools, etc. Cheers! :) Ian. 18/Jan/2001 SGI/NT Admin, Centre for Virtual Environments, University of Salford, Salford. mapesdhs@yahoo.com | Tel: +44 (0)161 295 2926, Fax: +44 (0)161 295 2925. M5 4WT ** Any comments, views or opinions expressed here do not necessarily reflect ** ** those of the Centre for Virtual Environments (CVE), or Salford University ** ****** My sites, their contents and my comments are the result of my own ****** ***** projects and not official sites from SGI, CVE or Salford University ***** Doom Help Service (DHS): http://doomgate.gamers.org/dhs/ SGI/Future Technology/N64: http://www.futuretech.vuurwerk.nl/ BSc Dissertation (Doom): http://doomgate.gamers.org/dhs/diss/