I’ve been thinking about this video since I watched it earlier today, the discovery that you had your old machine had made me think about the hardware I have in my collection that I took with me from my first job. I’m my case it’s a Toshiba Libretto 70 and a Tadpole SPARCbook 3GX. I haven’t fired either up in years, maybe I should.
The only time I ever saw those there were post-its on them with the text "My other laptop is an SGI", which in and of itself was funny, because SGI never made laptops.
@@damouze apart from the mockups SGI specifically did with the set designers on the TWiSTER movie. If these machines weren’t that precious, I‘d take one to replicate the fake SGI laptops, just because!
Ian here. :D In typical YT fashion, I didn't come across your video when it was first uploaded (or the channel), not until just now when (of all things) searching for a source of CDROM front covers for O2 (I'm looking for a few, will check your video about 3D printing; I'm prepping an O2 system for an autistic kid in the US, but I've run out of CDROM covers). Yes indeed the L2 is vital, so much so that IMO the R5000PC/180 SKU for O2 should never have existed (likewise the R5000PC/150 for Indy, or the rare but possibly even worse R4000PC/100). If it had been up to me, the minimum O2 would have been the R5K/200, providing at least some performance gain over the previous best possible Indy. So I admire your patience trying to do anything with a 180PC, I think I'd rather watch paint peel. :D I don't know why SGI chose R5K CPU SKUs for O2 that crossed over so much into the performance stack for Indy, but then the whole history of CPUs for O2 was a bit weird, eg. SGI never originally intended the R10K to be used in O2, but under pressure from important clients they tested it anyway and found that, despite the limitations imposed by needing an extra cache interface chip (it can hinder fp performance quite a lot), the results were impressive vs. the R5000 (as much as 2x faster at the same clock), including for 3D tasks (though R5K-type systems do have some performance consistency advantages if working with video). I was told that, as a result, key customers basically just demanded R10K O2s instead because they were so much faster. However, the proper L2 interface ASIC wasn't ready in time for launch, so SGI had to use a temporary chip instead which was very expensive. Thus, the original R10K/150 and R10K/175 systems were priced rather high. SGI resolved the ASIC supply issue in time for the R10K/195 release, hence the significant price drop vs. prior R10K systems (IIRC pricing for R10K units dropped by about 3500). The sad part is, diverting resources to the R10K line meant O2 never received the proper attention it deserved for R5K-type SKUs, and then of course the hw bug present in the R7K/350 was effectively exploited as an excuse to kill the O2 line entirely (though one could argue the O2+ launch pretty much nailed that coffin lid firmly shut anyway). It's such a shame we never got to see a proper O2 followon using something like Cobalt (same architecture) and a revised ICE. It would be interesting to mod a 180SC to have 1MB instead, and likewise mod a 200 and other SKUs to have 2MB. I may investigate this next year. I also want to once more look into possible R7K/600 mods, though I've no idea if doing it would be viable in terms of cost (I sourced some modules long ago but it was a fiscal disaster, I ended up making a large loss on it, but perhaps general costs have become more favourable by now). If the cost has become less prohibitive, maybe an R7K/600 with 2MB might even be possible. Alas anything beyond that still needs critical updates to the PROM, and without the PROM source that's always going to be very difficult (pity, as otherwise the dual-core R9000 1GHz ought to be compatible). There are of course diminishing returns with ever faster CPUs for O2 (memory bandwidth and latency), but even so it's remarkable just how much faster O2 is with better CPUs; even for 3D tasks, the results suggest that the main bottleneck is still the CPU, despite the much lower available shaded & texture fill rates vs. other SGIs, and it definitely helps for working with ICE. O2 can present some fascinating performance behaviour, partly because of cache issues, but also due to the way ICE connects to the rest of the system. I will be adding an article about DV processing to my site soon, it shows some interesting things, eg. for DV export, a good O2 outperforms an R16K/1GHz Tezro due to having ICE acceleration, and O2 is the only SGI that can playback native DV without framedrop. Going up the CPU stack, R5K/300 is a reasonable middleground for R5K-type systems, while the most sensible option for R10K-type systems is the CPU-mod R12K/300, assuming one can find a donor original R10K/225 (or 250) and an R12K/300 module for Octane (move the core from the Octane module into the O2 module, change the resistor settings to adjust the clock, but be very careful about static, and test that the intermediate R12K/225 or 250 is working ok before changing the resistor positions). This does mean the end result is an R12K/300 with 1MB L2 instead of 2MB (I'm sure I once had an original R2K/300 with 2MB, though most original 300s just had 1MB), but even so it performs very well. FYI SGI's later inhouse O2 dev systems had 4MB L2 (I was told), but sadly they were all junked. Alas R10K-type systems lose a disk bay, but for R5K owners, the R7K/350 is also pretty good if you can find one. Btw, I played and finished Quake2 on an R5K/200 O2, IIRC using 800x600, but I did this with the screen set to native 800x600. I was lucky that the first O2 I obtained back in 1998 (still my main system) was an R5K/200, with 256MB, AV, etc., now of course running with an R7K/600, 1GB, etc. Also note, O2's memory bandwidth increases if the display resolution and/or frame buffer depth are reduced, but I've not yet tested whether this translates into useful performance gains for real-world tasks such as rendering or code compilation. If the display subsystem could be disabled entirely (coms via serial console only), such that no memory bandwidth is being used at all, then perhaps main CPU/RAM tasks might benefit quite a lot, but I don't know if this is possible. And a cautionary tale about the installed OS version, even if it's the final 6.5.30. If you do a native install on an R5K O2 and then later upgrade to an R10K or R12K, there's a good chance the same disk will work ok with any SKU up to an R12K/300, but it may not work with the final R12K/400 (I discovered this recently during some extensive mbd testing). I know that a native R10K/R12K install does select different performance counters vs. R5K, but it seems unlikely this would affect the ability of the system to boot at all (it will reach the PROM ok, but then may fail to get past the "Starting up the system" phase, leaving a stuck grey screen). All O2s use a 32bit kernel, but there must be some sort of kernel lib nuance which means a native R5K inst cannot be used with 100% confidence with an R10K/R12K system, in which case, if doing such an upgrade, it's probably wise to do a miniroot inst to reinstall anything it deems necessary from the base CDs and relevant patch updates. Either that or just do a clean install on the R10K/R12K system. Lastly, I've just begun the process of doing a site revamp (long overdue, my main site hasn't changed much in years, never had the time due to almost continual family matters), so expect some new performance stuff next year. 8) PS: YT has a rotten habit of deleting long form posts like this. Thus, please like & pin if you deem it worthy. 8)
You have made me curious how the O2 would stack up against the equivalent Sun Microsystems hardware from the era, do you have any Sun boxes in your collection?
@JohnKiniston Hmm, I'm rather short on Suns actually. I do have a SunFire 1U server, two Cobalt RaQs (though they wouldn't count as original Sun systems), and one Sun Ray (terminal/thin client). But no actual workstations. Sold off everything years ago, and thus far didn't come by yet to reacquire Sun workstations. Close matches to the O2, at least from the timeline perspective, would be Ultra 2 (late 1995), Ultra 5/10/20 (early 1998). I used to have an Ultra 2 and Ultra 5, though I never bothered to compare against the SGIs. Though it's always dangerous to compare CPU architectures, like MIPS vs SPARC, and Sun vs SGI, as they were built for different purposes. But who knows, maybe a worthwile topic to dive into one day? ;)
@@THEPHINTAGECOLLECTOR I did the same with my sun gear, all I have left is my Tadpole and a pair of Qubes that I think predate the acquisition by Sun (2700, and 2)
@@THEPHINTAGECOLLECTOR I did the same with my sun gear, all I have left is my Tadpole and a pair of Qubes that I think predate the acquisition by Sun (2700, and 2)
Congratulations you recovered your sgi o2. That's great news!!.
@asanjuas Thanks, I'm happy as well :)
reunited at last, congrats! :-D
@autingo6583 Thanks, a totally unexpected surprise.
Cool video of these ancient retro machines from back in the day when there was more variety in architectures compared to today.
I not see in person a SGI computer, but I'm so fascinated with this machine, I'm very glad for watching yours videos!
I’ve been thinking about this video since I watched it earlier today, the discovery that you had your old machine had made me think about the hardware I have in my collection that I took with me from my first job.
I’m my case it’s a Toshiba Libretto 70 and a Tadpole SPARCbook 3GX. I haven’t fired either up in years, maybe I should.
Oh my… you have a SparcBook!? I‘ve only ever read about those. Awesome. You‘re making me only a bit jealous now! ;)
The only time I ever saw those there were post-its on them with the text "My other laptop is an SGI", which in and of itself was funny, because SGI never made laptops.
@@damouze apart from the mockups SGI specifically did with the set designers on the TWiSTER movie.
If these machines weren’t that precious, I‘d take one to replicate the fake SGI laptops, just because!
@@THEPHINTAGECOLLECTOR Me too! It was just my (failed?) attempt at humor.
Ian here. :D In typical YT fashion, I didn't come across your video when it was first uploaded (or the channel), not until just now when (of all things) searching for a source of CDROM front covers for O2 (I'm looking for a few, will check your video about 3D printing; I'm prepping an O2 system for an autistic kid in the US, but I've run out of CDROM covers). Yes indeed the L2 is vital, so much so that IMO the R5000PC/180 SKU for O2 should never have existed (likewise the R5000PC/150 for Indy, or the rare but possibly even worse R4000PC/100). If it had been up to me, the minimum O2 would have been the R5K/200, providing at least some performance gain over the previous best possible Indy. So I admire your patience trying to do anything with a 180PC, I think I'd rather watch paint peel. :D
I don't know why SGI chose R5K CPU SKUs for O2 that crossed over so much into the performance stack for Indy, but then the whole history of CPUs for O2 was a bit weird, eg. SGI never originally intended the R10K to be used in O2, but under pressure from important clients they tested it anyway and found that, despite the limitations imposed by needing an extra cache interface chip (it can hinder fp performance quite a lot), the results were impressive vs. the R5000 (as much as 2x faster at the same clock), including for 3D tasks (though R5K-type systems do have some performance consistency advantages if working with video). I was told that, as a result, key customers basically just demanded R10K O2s instead because they were so much faster. However, the proper L2 interface ASIC wasn't ready in time for launch, so SGI had to use a temporary chip instead which was very expensive. Thus, the original R10K/150 and R10K/175 systems were priced rather high. SGI resolved the ASIC supply issue in time for the R10K/195 release, hence the significant price drop vs. prior R10K systems (IIRC pricing for R10K units dropped by about 3500). The sad part is, diverting resources to the R10K line meant O2 never received the proper attention it deserved for R5K-type SKUs, and then of course the hw bug present in the R7K/350 was effectively exploited as an excuse to kill the O2 line entirely (though one could argue the O2+ launch pretty much nailed that coffin lid firmly shut anyway). It's such a shame we never got to see a proper O2 followon using something like Cobalt (same architecture) and a revised ICE.
It would be interesting to mod a 180SC to have 1MB instead, and likewise mod a 200 and other SKUs to have 2MB. I may investigate this next year. I also want to once more look into possible R7K/600 mods, though I've no idea if doing it would be viable in terms of cost (I sourced some modules long ago but it was a fiscal disaster, I ended up making a large loss on it, but perhaps general costs have become more favourable by now). If the cost has become less prohibitive, maybe an R7K/600 with 2MB might even be possible. Alas anything beyond that still needs critical updates to the PROM, and without the PROM source that's always going to be very difficult (pity, as otherwise the dual-core R9000 1GHz ought to be compatible). There are of course diminishing returns with ever faster CPUs for O2 (memory bandwidth and latency), but even so it's remarkable just how much faster O2 is with better CPUs; even for 3D tasks, the results suggest that the main bottleneck is still the CPU, despite the much lower available shaded & texture fill rates vs. other SGIs, and it definitely helps for working with ICE.
O2 can present some fascinating performance behaviour, partly because of cache issues, but also due to the way ICE connects to the rest of the system. I will be adding an article about DV processing to my site soon, it shows some interesting things, eg. for DV export, a good O2 outperforms an R16K/1GHz Tezro due to having ICE acceleration, and O2 is the only SGI that can playback native DV without framedrop.
Going up the CPU stack, R5K/300 is a reasonable middleground for R5K-type systems, while the most sensible option for R10K-type systems is the CPU-mod R12K/300, assuming one can find a donor original R10K/225 (or 250) and an R12K/300 module for Octane (move the core from the Octane module into the O2 module, change the resistor settings to adjust the clock, but be very careful about static, and test that the intermediate R12K/225 or 250 is working ok before changing the resistor positions). This does mean the end result is an R12K/300 with 1MB L2 instead of 2MB (I'm sure I once had an original R2K/300 with 2MB, though most original 300s just had 1MB), but even so it performs very well. FYI SGI's later inhouse O2 dev systems had 4MB L2 (I was told), but sadly they were all junked. Alas R10K-type systems lose a disk bay, but for R5K owners, the R7K/350 is also pretty good if you can find one.
Btw, I played and finished Quake2 on an R5K/200 O2, IIRC using 800x600, but I did this with the screen set to native 800x600. I was lucky that the first O2 I obtained back in 1998 (still my main system) was an R5K/200, with 256MB, AV, etc., now of course running with an R7K/600, 1GB, etc.
Also note, O2's memory bandwidth increases if the display resolution and/or frame buffer depth are reduced, but I've not yet tested whether this translates into useful performance gains for real-world tasks such as rendering or code compilation. If the display subsystem could be disabled entirely (coms via serial console only), such that no memory bandwidth is being used at all, then perhaps main CPU/RAM tasks might benefit quite a lot, but I don't know if this is possible.
And a cautionary tale about the installed OS version, even if it's the final 6.5.30. If you do a native install on an R5K O2 and then later upgrade to an R10K or R12K, there's a good chance the same disk will work ok with any SKU up to an R12K/300, but it may not work with the final R12K/400 (I discovered this recently during some extensive mbd testing). I know that a native R10K/R12K install does select different performance counters vs. R5K, but it seems unlikely this would affect the ability of the system to boot at all (it will reach the PROM ok, but then may fail to get past the "Starting up the system" phase, leaving a stuck grey screen). All O2s use a 32bit kernel, but there must be some sort of kernel lib nuance which means a native R5K inst cannot be used with 100% confidence with an R10K/R12K system, in which case, if doing such an upgrade, it's probably wise to do a miniroot inst to reinstall anything it deems necessary from the base CDs and relevant patch updates. Either that or just do a clean install on the R10K/R12K system.
Lastly, I've just begun the process of doing a site revamp (long overdue, my main site hasn't changed much in years, never had the time due to almost continual family matters), so expect some new performance stuff next year. 8)
PS: YT has a rotten habit of deleting long form posts like this. Thus, please like & pin if you deem it worthy. 8)
Nice one !
You have made me curious how the O2 would stack up against the equivalent Sun Microsystems hardware from the era, do you have any Sun boxes in your collection?
@JohnKiniston Hmm, I'm rather short on Suns actually. I do have a SunFire 1U server, two Cobalt RaQs (though they wouldn't count as original Sun systems), and one Sun Ray (terminal/thin client). But no actual workstations. Sold off everything years ago, and thus far didn't come by yet to reacquire Sun workstations.
Close matches to the O2, at least from the timeline perspective, would be Ultra 2 (late 1995), Ultra 5/10/20 (early 1998). I used to have an Ultra 2 and Ultra 5, though I never bothered to compare against the SGIs. Though it's always dangerous to compare CPU architectures, like MIPS vs SPARC, and Sun vs SGI, as they were built for different purposes.
But who knows, maybe a worthwile topic to dive into one day? ;)
@@THEPHINTAGECOLLECTOR I did the same with my sun gear, all I have left is my Tadpole and a pair of Qubes that I think predate the acquisition by Sun (2700, and 2)
@@THEPHINTAGECOLLECTOR I did the same with my sun gear, all I have left is my Tadpole and a pair of Qubes that I think predate the acquisition by Sun (2700, and 2)