![[SGI Indy]](indy/pcwindy.jpg)
Epilogue
Epilogue
I've decided to update this page partly because of questions I've received and advice I've given to people since March 1999, but also because the realities of the 2nd-hand SGI market at the moment definitely requires some comment in order to ensure people don't waste their money. More on these issues later.
Change Log:
Historical Performance Legacy
If you've read the 1993 PCW review, it's important to note that their review system was a very early model of Indy which had a small disk (384MB), very little memory (16MB) and what is now an extremely old CPU (R4000). It is possible that you could come across such an early machine, but they're very rare. I've never seen a 2nd-hand advert for Indy with such a low configuration. Thus, if you should find such an Indy for sale, then assume that, should you buy it, you will need to greatly increase its memory size, disk capacity and (more than likely) get a better processor if you want acceptable performance (of course, the definition of 'acceptable' is a personal concept). Sometimes, this schema can work to a buyer's advantage, ie. a low-spec system may be on offer for a very low price , so you could buy it and then replace or add key components to improve its power. Components such as RAM and disks are now massively cheaper than they were when Indy first came out, although memory prices have actually been increasing in recent years (and SCSI disks with 50-pin interfaces are harder to find now). In fact, many items available now, such as 4.5GB and 9.1GB SCSI disks, didn't exist back in 1993. Memory is about $1.50/MB these days, whereas in 1993 it was well over $100/MB.
Then there's the choice of operating system. Most people interested in an Indy today would want at least IRIX 6.2 on the system, but such later OS releases like 6.2, and definitely 6.5, require a good main CPU in order to give the user an acceptable level of daily-task performance. When Indy was first released, no doubt things were simpler and a user's demands lower (IRIX 5.3 and earlier), but in general I would recommend that - if you don't intend to upgrade a system once purchased - you should go for nothing less than a 150MHz R4400SC CPU, no less than 64MB, and a disk no smaller than 1GB. The R4600SC 133MHz CPU (512K L2 cache) is also a suitable CPU (stronger integer performance than R4400SC/150) - see the results on my SGI General Performance Comparisons page for further details. I do know that the R4600PC 133MHz is too slow for my liking (I should know - I used to run a lab of 18 such systems), though it's ok until an upgraded can be afforded (the lack of L2 cache hurts general application performance).
Any CPU for Indy will run any version of IRIX (that's suitable for Indy), but there are huge differences in relative performance depending on CPU type and OS revision. It's important before buying to settle in your own mind whether the system you're going to buy - without immediate changes - would be good enough for your intended tasks, or whether you may need to upgrade the system after the initial purchase to bring it up to a level you'd find acceptable. Additional components are not expensive now, but the cost of upgrading a very low spec Indy could quickly mount up. When thinking about such matters, you may discover that today's 2nd-hand Indigo2s are a better deal, with (this inconceivable 18 months ago) R10K/195 SolidIMPACT Indigo2s (128MB/4GB) selling for as little as $595. The choice isn't as simple as this though; other facts such as as-standard video inputs in Indy with digital camera, but not Indigo2, complicate matters.
It's up to you to work out whether buying a low-spec system and upgrading is better or worse than buying a good system in the first instance. You may need to make some enquiries as to RAM and disk prices, and perhaps CPU upgrades. If you live in the USA, then you're lucky since US prices for components are good (the 2nd-hand SGI market is strong in the US). Those in Europe or elsewhere will have to pay more, perhaps much more if the only source for an item is by import from the US. Having said that, Europe's 2nd-hand SGI market has improved alot since early 199, with companies such as RTP offering R10000 Indigo2s at good prices (see my adverts page for the latest news).
Monitors, RAM, video and disk space.
There are many differences. Firstly, as stated earlier, I have never encountered an Indy with as little as 16MB RAM, or the minimum 15" (1024x768) monitor. Every Indy I have ever seen or read about has had at least 32MB RAM and a 17" (1280x1024) monitor. However, 2nd-hand Indys will quite often have the 8bit XL graphics card, as opposed to the 24bit XL system. It isn't quite true 8bit (256 colour) video though - it's actually better; SGI uses a technology called Virtual24 which employs clever dithering and hardware lookup tables to allow multiple colour maps for on-screen applications, preventing the colour-map swapping commonly seen on other systems such as Sun4s when many applications are running at once. Think of it as being somewhere inbetween 8bit and 24bit. However, if one does any double-buffered 3D graphics, or displays an incoming video picture, then the 8-bit dithering is definitely noticable because such tasks employ so many more colours at once.
My advice is always get a 24bit system if possible since it improves so many things: video work, imaging, much less dithering for 3D graphics, etc. Thankfully though, years on from the Indy's launch, 2nd-hand 24bit XL cards are now reasonably cheap and can be purchased from reseller companies for around $100, sometimes much less when a company has a large number available. Thus, be aware that it might be cheaper to buy an 8bit system in the first instance and then purchase the 24bit upgrade later (the single card is simply swapped for the upgrade card; the 24bit version has an extra 8 frame buffer memory chips on the board, 4 on each side). You could always then sell the original 8bit card to make up for the upgrade purchase, though many would probably opt to keep the original board as a backup.
Just as with RAM and monitor type, I have never come across an Indy with a disk as small as 340MB. I suppose there must be some out there, but they're very rare. The vast majority of Indys will have 1GB disks, while some will have 549MB disks and others 2GB disks. Indys will happily take modern 4.5GB disks, and 9.1GB too as long as the heat output is not excessive, though don't expect to find a 2nd-hand Indy with a disk larger than 2GB. Of course, since an external SCSI-2 port comes as standard, one can always attatch external option drives.
And whatever internal disk an Indy has by default, you could always switch to using a larger external unit as a root device (ie. system disk). One Indy I used to run had an external 2GB root disk, the unit in question being an original SGI 2GB Seagate enclosure. Or, you could just buy an Indy with a small disk and sell/swap the small disk for a larger size (must be half-height profile). I did this in 1998 in a deal with University in England, exchanging two 549MB disks and one 1GB disk for a single 2GB disk.
Disks, disks, disks... who cares? Well, take careful note, because this is important: an Indy will not be able to install the very latest version of IRIX (currently 6.5.x) on a disk as small as 549MB. A minimal installation of IRIX 6.2 will install ok, but there will be very little room left for anything else. I strongly recommend that, if you buy an Indy, you plan in the long term to have at least 2GB of disk space on the root disk. If there is no choice and the root disk is 1GB, then a temporary solution if you run short of space is to house all the data in /usr/share on a separate disk and just mount it on bootup - this can save as much as half a GB of data if lots of software is installed (/usr/share contains all online books, manual pages, example images, movies, models and source code; it is quite common for network environments to have /usr/share NFS-mounted off a server to save space, although it does mean man page searches and online-book access runs much slower with only a 10MBit network). A typical solution, if you bought an Indy with a 549MB root disk, would be to replace it with a 2GB root disk and place /usr/share on the old disk. Note, however, that having two internal disks would mean there would be no space for an internal floptical drive, so maybe the /usr/share disk would have to be placed externally. Whatever. External enclosures are cheap these days anyway. As you can see, there are many possibilities and trade-offs.
Processors
The PCW reviewer could not have imagined how quickly Indy would progress. By 1994, Indys were available with the R4400 CPU (much better than R4000), with speeds of up to 175MHz. Then came the 200MHz version, and finally a new CPU generation called R5000, a CPU specifically designed to accelerate the MADD-style single-precision floating-point operations that are typically used in 3D graphics for geometry and lighting calculations (eg. a 200MHz R5000 is 2.3X faster than a Pentium200 for doing 32bit fp geometry and lighting calculations) - see the Byte article on the R5000 for more details.
Here is a summary of the various processors which you might see in an Indy (PC after a CPU type means 'Primary Cache', ie. the CPU has no L2 cache. 'SC' means the CPU does have L2 cache):
CPU Clock L2 Cache Type Speed (if any) R4000PC 100MHz - (*) R4000SC 100MHz 1MB (*) R4600PC 100MHz - R4600PC 133MHz - (#) R4600SC 133MHz 512K R4400SC 100MHz 1MB (*) R4400SC 150MHz 1MB R4400SC 175MHz 1MB (*) R4400SC 200MHz 1MB R5000PC 150MHz - R5000SC 150MHz 512K R5000SC 180MHz 512K (*) quite rare to find (#) probably the most common type found in 2nd-hand systems
Understanding the capabilties of the different processors is important in making a good 2nd-hand buying decision. The R4000 without L2 cache was too slow, so SGI quickly moved to 1MB L2. The R4400 was designed to be a very well balanced CPU for both int and fp processing. The R4600 was aimed more at integer processing. The R5000 was aimed very much at single-precision fp processing for 3D graphics, with integer processing much the same as any other CPU of its day at a similar clock speed. The particular CPU an Indy has directly affects its capabilties, especially in XL systems (ie. systems which have no hardware Z buffer or geometry/lighting acceleration). I have put alot of time and effort into providing a great deal of practical, real-world, performance information about the relative strengths and weaknesses of different CPUs in Indy. I've performed a wide variety of tests, some quite unique but very relevant; the results, along with test data for many other systems such as Indigo2, O2, Octane, Onyx2, etc., are available on my SGI General Performance Comparisons page. If you can, I recommend printing the page for later reading because the amount of information on the page is quite considerable.
An Example Performance Consideration: Video Processing.
An R4600PC/133 Indy which does not have the CosmoCompress option cannot reliably capture half-size (320x240) video from the IndyCam, or from the video inputs, at 15fps. The R4600PC/133 is too slow, ie. the processing required is beyond its capabilities. Thus, if you want an Indy for Internet-quality video work, don't get an R4600PC/133 model (an R4600SC/133 model should be ok though). However, an R4400SC/200 Indy will capture half-size video at 15fps just fine, so it would be a good machine for any small business which wanted to capture video from VHS or the IndyCam camera for making web movies, etc. On the other hand, if an Indy happens to have the CosmoCompress option card, then all video capture JPEG processing is done in hardware, so the power of the main CPU is less relevant.
Of course, if one is lucky enough to have a RAID array attached, then any model Indy will be able to capture half-size uncompressed PAL or NTSC video at full-frame-rate straight to disk (one needs 8MB/sec for half-size PAL, and 6.7MB/sec for half-size NTSC). Since Indy does not have an UltraSCSI controller, uncompressed capture of full-size full-frame-rate video is not possible using the single as-standard Fast SCSI-2 channel, though one could always obtain the optional SCSI card (provides an extra two SCSI channels) to bypass that problem: either write custom software to spread the load across more than 1 SCSI channel, or use the XLV system to use the multiple channels, or purchase a commercial software package. Normally though, one would use IndyVideo and CosmoCompress in combination for full-size full-frame-rate MPJEG video capture. Note that simply displaying a PAL or NTSC (or IndyCam) video stream on the screen is always possible with any model Indy, because the video data is DMA'd directly into main memory, minimising the load on the main CPU.
Actually, there is one way to capture full-size, full-frame-rate PAL or NTSC video without a RAID array, but only in short bursts: capture straight to memory and then, when one runs out of memory, save the data to disk. 256MB RAM is enough to capture 8 seconds of PAL video (assume 7 seconds due to RAM used by other apps) or 9.5 seconds of NTSC video (assume 8.5 secs, etc.) This isn't much, but sometimes video editing consists of combining small pieces so it may be appropriate for some. Obviously, capturing straight to memory is a more usable option on a system with a larger maximum RAM, eg. R4K-series Indigo2 (384MB), R8K/R10K-series Indigo2 (768MB), O2 (1GB), R10K-series Octane (2GB), R12K-series Octane (4GB) and so on up to tens of GB for Onyx, etc. I once knew a lady in the US who used an Onyx with 2GB RAM - she would capture video straight to main memory for uncompressed video editing. 2GB RAM is enough to capture over a minute of uncompressed PAL video.
2nd Example: General Application Performance.
Suppose you intended to use Netscape alot, and you were happy with using IRIX 6.2. Now ask yourself: how long am I prepared to wait for Netscape to run up when I activate the application? 5 seconds? 7? 10? Suppose you decide no slower than 7 seconds. Well, examine Table 7b on the results page and you'll see that you should therefore not get an Indy as slow as R4600PC/133 (9.5 seconds); but if you decided to move to IRIX 6.5, that choice would change to needing something faster than R4400SC/200 (8 seconds). The information I've made available allows you to construct practical questions as to what levels of performance (relative and absolute) you would find acceptable in daily use, for a wide variety of application areas.
Another simple example: R4400/200 will run SGI Doom at 640x400 just fine - very smooth and playable (remember it's 2D pixel filling that is important in Doom since Doom uses raycasting, not texture mapping). An R4600PC/133 will not run SGI Doom at 640x400 at anything like a playable frame rate. Going up the scale, R4400/200 can't offer a good frame rate at 3X scaling (960x600), though one should bare in mind that - at 960x600 - Indy is blatting 19 times more pixels per second than a PC is when running Doom! An R5000/180 Indy should handle the maximum 4X scaling (1280x800) perfectly though.
Graphics
NB: no Indy configuration supports hardware texture mapping or 32bit colour. If features such as these are important to you, then you should be considering Indigo2 (HighIMPACT or MaxIMPACT) or O2 instead of Indy, or perhaps older high-end systems such as Crimson or Onyx.
When the PCW review article was written back in 1993, XL graphics was the only graphics option available for Indy (8bit or 24bit). The PCW reviewers didn't know that the 4 Geometry Engine version of the Indigo2 XZ graphics system (otherwise known as GR3-Elan) would be redesigned and made available for Indy just a little while later. So, Indy can have the following options:
Type Features
8bit XL Fast 2D performance, dithered colour, all 3D graphics
processing done by main CPU. Does not have a hardware
Z buffer for 3D hidden surface removal.
24bit XL Gives full 24bit colour at 1280x1024; 2D performance
and the handling of 3D graphics is the same as 8bit XL.
XZ 24bit colour just as 24bit XL, but includes a hardware
Z buffer and 128MFLOPs of hardware geometry/lighting
acceleration for 3D graphics. Slower 2D performance
and screen refresh than XL though. XZ is meant for 3D.
When SGI released the R5000 CPU for Indy, the intention was that people would use the main CPU instead of the XZ accelerator board for 3D graphics because the R5000 has a higher MFLOPS performance rating than the 4 GEs on the XZ board set. A comparison is:
Item MFLOPS XZ Hardware 128 R5000 150MHz 300 R5000 180MHz 360
SGI never released comparable performance information for R4xxx Indy XZ vs. R5000 Indy XZ vs. R5000 Indy XL, etc., but my performance page now has useable comparisons and the results are clear: if your main task is non-textured 3D modeling, and the Indy in question is an XZ, then there is simply no need to have a fast CPU since its power is largely irrelevant to the rendering process. For example, looking at the spacestation model results, R5000SC/180 XZ gets 6.05 fps, while an R4600PC/133 XZ gets 6.04! Essentially an identical result given the nature of the tests. This shows that the CPU isn't important for this type of task. Worse, however, is that my tests finally showed SGI's 'XGE' concept to be flawed. I regard the spacestation as a pretty typical model in terms of acceptable complexity level for a platform like Indy, yet R5000SC/180 24bit XL only gets 2.14 fps for the max-window test. Clearly, the more important Z buffering effects have already taken over, limiting how fast an R5000 XL configuration can perform. Similar behaviour can be seen with the stars4 model, stars3, the smaller landscape models, angus, etc. Things only seem to change when the Z buffering is made less important, ie. a small window size, or when the main CPU calculations become intense (very large landscape model). Examine the small-window (SW) results for the angus model: this time R5000SC/180 XL beats R5000SC/180 XZ (and R4600PC/133 XZ). But this situation is unusual since most users would wish for large window sizes when doing 3D modeling.
With hindsight, Indy's graphics options should have been more like Indigo's, ie. more modular and easier to change without having to replace the base board set. With Indigo, one can add a Z buffer daughtercard to an XS24 configuration, or add video memory modules to go from XS8 to XS24. This isn't possible with Indy.
Note that my earlier comment about how an XL system can outperform an XZ system refers to situations with small polygon counts and multiple light sources. For a more detailed discussion, see my HolliDance Benchmark page, which shows a typical example of how an XL Indy can outperform an XZ system (in this case, my own Indigo2 XZ machine) when multiple lights are involved (with three lights on, my 250MHz 4GE-XZ Indigo2 is slower than even an R4600PC 100MHz Indy XL; but with the lights off, the Indigo2 XZ is 158% faster than R4600PC/100 Indy XL).
For these reasons and others, I strongly advise you to consult all available information on how different Indy models perform before deciding whether a particular model is right for you. Be clear in your own mind what you want in terms of performance and features, and then identify the appropriate system configuration which would give you those features. You might even find from such a process that Indy isn't the right machine for you and maybe Indigo2 is a better choice, or O2. In general, people looking for a 2nd-hand system do not have a large budget, eg. students, so it's important to make the right choice.
So now for the annoying part: after having said all the above, it's highly likely that, if your intended task is non-textured 3D modeling, then an Indigo2 SolidIMPACT is going to be a much better buy. Prices for R10K SolidIMPACT systems have crashed since 1999, so now it's common to find such systems cheaper than Indy configurations. SolidIMPACT is four times faster than Indy XZ (or Indigo2 GR3-Elan), so if you find a SolidIMPACT selling for only a $100 or so more than an Indy, then obviously the latter is the better choice. This assumes the 3D power is more important to you than Indy's built-in video, ISDN, etc.
As I write this, a Canadian company is offering R10K/195 SolidIMPACT systems for $595 on comp.sys.sgi.marketplace. This is clearly a much better buy than any Indy for 3D modeling (also massively better for CPU power, maximum RAM limit, expansion possibilities, etc.) and in fact is much cheaper than most Indys that are available (Mashek has R4400SC/200 24bit XL for $600; an R5000SC/180 XZ would be about $800).
These price drops have also impacted on low-end Indigo2 systems: many companies don't sell low-end Indigo2s anymore because there's little or no profit to be made (XL, 2GE or 4GE XZ; CPUs less than R4400SC/200). It's common to see Indigo2 configurations starting at Extreme graphics (2X faster than 4GE-XZ). So, for the time being at least, if your main task is 3D modeling, then Indigo2 IMPACT is likely a better buy. Indys are probably better for those who are budget limited, or who are more interested in entry-level video, compact size, etc.
Software and Operating System
SGI changed the way it handled development software during the mid-1990s so that, now, one can obtain basic development files (header files, etc.) and use the freely available fully-compiled GCC compilers to compile programs. If you want to use SGI's own more-advanced MIPS Pro compilers, you'll need a license (although they do seem to work anyway for some reason - error messages are given, but the compilation still proceeds). Of course, you might be lucky enough to find an Indy which already has a MIPS Pro compiler license installed, perhaps even a Permanent license. If so, well done! But just remember that it is illegal for a seller to charge for software and licenses - such licenses (especially for commercial software like Maya) are not transferable by sale, eg. someone could charge a hefty amount for an Indigo2 that had Maya installed, but they can't say they're charging for the Maya software itself. This is definitely the situation in the USA, but I'm less certain of the rules in other parts of the world.
As an overall environment, SGIs come with a vast array of as-standard free software such as the Digital Media Tools (image/video/audio/3D graphics) and there is now a plethora of free 3rd-party software available, such as the animation and rendering program called Blender and the excellent imaging program called GIMP. One of the main reasons why 2nd-hand SGIs are such attractive systems for students is because of the excellent quantity of freely available software, much of which can be downloaded from SGI's web site, as can most software patches and updates. The same freeware is available for Linux PCs, but SGIs are much easier to deal with in terms of installation, maintenance, hardware issues, etc. and the OS is much more advanced.
However, some applications do still require licenses. This used to include CosmoWorlds and CosmoCode, but now free licenses are available for these two applications (excellent!). The Cinepak and MPEG encoders for IRIX 6.2 used to need licenses, but now one can obtain free licenses from SGI's software downloads page. The main items which do still require licenses are SGI's professional CASE tools environment (Workshop Pro), IRIS Annotator, and the Impressario Postcript renderer (just get a printer which understands Postcript anyway, eg. HP Laserjet, and use applications like XV, Netscape, etc. to create Postcript documents, thus bypassing the need for Impressario). SGI's web site has a summary of which software applications need licenses.
Some features are only available in later OS releases, eg. the excellent real-time-feedback image-manipulation features in imgview are only present by default in IRIX 6.5, though the latest update to IRIX 6.2 will give the same features to 6.2's imgview. SGI always adds new features each time their IRIX OS undergoes a major release: aside from the huge number of more important changes made to the collated parts of 6.2, 6.3 and 6.4, IRIX 6.5 added extra features to imaging programs, useful demos such as 'snoop', and more MIDI/synth software. I'm the kind of user who finds these types of enhancements very useful. Serious developers will benefit from enhanced libraries and fewer bugs when using later OS releases, and especially the fact that 6.5-developed programs will be directly compatible with SGI's entire current product line, right up to Onyx3000 and Origin3000, but also much older systems such as Indigo and Onyx. An exception is Crimson, which cannot go beyond IRIX 6.2, but one can still update Crimson's 6.2 with the various update patches to give it many of the features which 6.5 has, eg. the better version of imgview. Some aspects of 6.2 will always remain, eg. the old objectserver system and name service methods.
Low-end Indys will run IRIX 5.3 just fine, and IRIX 6.2 as well, though I recommend at least 64MB RAM when using 6.2 (it will run ok with 32MB, but there isn't much left over for applications). IRIX 6.5 definitely needs at least 64MB (128MB recommended). Happily, a surprising number of 2nd-hand Indys do actually have 64MB or 128MB RAM, probably because their owners upgraded them at some point (always ask whether an Indy has just 1 or both memory banks used!). My general performance comparisons page includes a table showing how much memory is grabbed by the OS given differing base RAM resources, for both 6.2 and 6.5. The table includes results for Indy and Indigo2, with 6.3 vs. 6.5 results for O2.
Options
Other options not mentioned by the review article include:
Dream Systems
So what is a good Indy? Well, first, here is a not-so-good Indy (in my opinion anyway):
R4600PC 133MHz 32MB RAM 8bit XL graphics 549MB disk
From here on, I assume that you would obtain an external CDROM and
perhaps a DAT drive too for backup if you purchased any 2nd-hand
SGI. Both the Toshiba 32X CDROM (XM-6201B) and Sony SDT9000 DDS3 DAT
drive will work immediately with IRIX 6.2 or later, without having to
change any setup files, etc. though I do assume here that you would
have the latest relevant OS patches installed (available from SGI's
web site). I bought myself the Toshiba XM-6201B CDROM for my Indigo2
and it works perfectly. I had my department buy the DDS3 Sony for our
Challenge S and it works fine too (both these items successfully
tested with Indigo2, O2 and Indy). I'm not sure about DDS4 DAT though
- I think that requires IRIX 6.5.7 or later.
What would be a reasonable Indy? Not brilliant, but definitely ok for
general work? The configuration I used to have when working at the
University of Central Lancashire (UCLAN) [in Preston] is a good
example:
R4400SC 200MHz CPU (1MB L2) 64MB RAM 24bit XL graphics 2GB disk Floptical drive
And so to the dream machines. The following is what I would be blissfully happy to have if I were hunting for an Indy for student or small business work in the areas specified:
R5000SC 180MHz CPU (512K L2) 128MB RAM 24bit XL graphics IndyVideo CosmoCompress 4.5GB disk Floptical drive
R5000SC 180MHz 128MB RAM XZ graphics IndyVideo 4.5GB disk Floptical drive
For the first example, having both IndyVideo and CosmoCompress means one can capture, edit and playback high-quality video from the video inputs, digital camera, or the screen, as well as send the current on-screen graphics to video-out, from a PAL, NTSC or nearly full-screen area. Even so, for reliable performance, I would make sure the root disk (or whatever disk is being used to store video data) was an UltraSCSI type (a modern 4.5GB Seagate falls into this category; I run several Indys with 4.5GB UltraSCSI Seagate disks, though today the newer 9GB disks are better value).
While on the subject of disks, never buy a Micropolis disk! The company itself no longer exists, and Micropolis disks are renowned for firmware problems with SGIs. Actually, some early models of Seagate MedalistPro disks had firmware problems with SGIs, but they're easily fixable. Thus, here's a tip: stick with up-to-date UltraSCSI Seagate or IBM disks that are 4.5GB or better. There certainly are other models of SCSI disk which are sometimes better value for money in terms of $-per-MB, but I prefer to focus on reliability. Note that after being unimpressed with the noise output of Seagate's 4.5GB Medalist disk, I've switched to IBM now for most of my disks (I have several 9GB disks and a single 18GB). Much quiter than Seagate Medalists, faster access, larger cache, and cheaper. However, the world of disks can change quickly. Just keep an eye on the latest prices (cheap UK suppliers include www.dabs.com).
Finally, a note on IndyVideo and CosmoCompress: wonderful though they may be, you are highly unlikely to come across a 2nd-hand Indy containing both these options. If either is to be found, it's more likely to be IndyVideo. This rarity is mainly because the cards were quite expensive when Indy was still 'current' technology. Plus, some sellers might hike up the price of an Indy with these options to far too high a level, ie. to such an extent that an O2 - with its built-in video/image compression/decompression engine and more advanced features/performance/CPUs/etc. - becomes a much better choice. Don't go spending a fortune on a 'high-end' 2nd-hand Indy when, for not much more, you can get an O2 instead which is far, far better. Because of the release of the Visual Workstation systems and newer R12K (or later) CPUs, 2nd-hand O2 prices are decreasing.
Of course, one can always hunt for option cards separately from resellers, etc. Prices vary enormously though.
What About Missing Parts?
This could be more important than you might first realise. 2nd-hand systems by their very nature have probably been heavily used before being sold, so it's important to check that the system comes with all the appropriate parts. If items are missing, that should imply a lower sale value. Things to watch out for include:
Are all the screws present on all the boards? Is the grab-handle on the SCSI cable still intact? If there is only one SCSI device present (root disk), does the system still have the 2nd SCSI tray? If the top tray is still there, does it have the side plate to block the floppy drive opening? Are both banks of memory used, or only one? (a system may only have 64MB RAM, but that could be because it has 32MB in both banks which means any upgrade you wanted to do would leave you with at least one unused 32MB memory kit, ie. four 8MB SIMMs).
What is the general state of the machine? Has the owner bothered to keep it in good condition and free of dust? A poorly kept machine is more likely to fail from internal corrosion, especially if it was originally used in a hostile environment. Check for corrosion on the metal chassis.
Is the blue fixing substance still in place on the CPU securing screws? If not, then it's likely the CPU daughterboard has been removed at some stage - ask if that is the case and, if true, what was the reason for the removal (CPU upgraded/replaced? Or just for cleaning maintenance?).
Conclusion
I hope the information given here will be helpful to you if you are thinking of purchasing a 2nd-hand Indy. At the very least I hope you will have a better appreciation for what Indy can and cannot do, and how it compares to other systems. Over time, I shall added further comparison pages, discussing Indy vs. O2, Indy vs. Indigo2, and seperate advice pages like this for O2 and Indigo2.
Happy hunting! :)