The Onyx Desk-side system, much larger than I ever expected!!!???
#21
RE: The Onyx Desk-side system, much larger than I ever expected!!!???
(03-11-2021, 02:43 PM)saq Wrote:  I never seriously looked at R8k because in the Indigo2 it is reputed to be significantly less reliable than any of the other options. Did that hold over to Onyx/CHALLENGE as well or does the increased air flow and lack of flex connectors remedy that?

Closest I have ever gotten is my Indigo2 Extreme. At one point it was a R8k/75 until it was some-sort-of-graded to a R4k/200 by SGI (little sticker on the back showing new configuration). Not sure if that is an upgrade, downgrade or crossgrade. Guess it depends on what you were doing with the machine.


The caches for these systems are extremely sensitive to static, more so than usual components are. (This could render them somewhat unreliable, if you mess around with them without the correct anti-static gear, as well as not wearing an anti-static strap.)
(This post was last modified: 03-11-2021, 03:38 PM by Irinikus.)
Irinikus
Hardware Connoisseur

Trade Count: (0)
Posts: 3,475
Threads: 319
Joined: Dec 2017
Location: South Africa
Website Find Reply
03-11-2021, 03:26 PM
#22
RE: The Onyx Desk-side system, much larger than I ever expected!!!???
Performance issues aside, reputed by whom? Based on what data? I've seen so many beliefs like this over the years about SGI parts, systems and sw issues, but they mostly seem to be self reinforcing over time rather than based on hard data. That doesn't mean they're not true of course. Biggrin  But many beliefs have become out of date as components age, etc. I know of one example which was my fault, the belief that 6.5.15m was better for the dmedia libs, it spun off from a comment I made yonks ago about bugs in 6.5.16 (but they were fixed in a later release, so the notion about 6.5.15 quickly became null).



If anything I've had more problems with R10K boards than R8K boards for Onyx/Challenge, but is that because of pure chance, random bias in sample size, the fact that fewer people ask about R8Ks so I put them in systems less often so they're not stressed as much? All sorts of possibilities. It's a mess of selection bias; often something that may have at least a grain of truth becomes exagerated, such as the commercial belief that 1327 mbds for O2 are "better" for serial port I/O (I've heard this from numerous medical and industrial corps, but none can provide a justification or data proving it, none have actually tried a 1227 to compare because they're not allowed to).



So in the end it's hard to answer the first question there because none of us have much to go on beyond the anecdotal and personal experience, neither of which are a sound rationale. Maybe it's a batch issue, perhaps some R8K modules for Indigo2 had issues and those are the ones which gave them a bad rep, whereas most might be as equally solid as an R10K. It would be great to have SGI's old warranty/repair claims data for all this, but I guess that'll never happen (probably been lost by now anyway). My hunch is R8K likely is less reliable in Indigo2 than R10K, but by what degree I couldn't say, nor how it might compare to R8Ks in Challenge/Onyx. For some performance background, see:

http://www.sgidepot.co.uk/sgidepot/r8kcomments.txt



Re the switch to an R4K/200, that in just about every way possible which matters would be an upgrade. 8)  The only thing for which the R8K would be better is highly optimised FP64 of a kind that's properly suited to R8K (see above link), but even then in Indigo2 the halved L2 size limited the gains compared to how R8K behaves in Challenge/Onyx, with perhaps the lower memory bandwidth being a factor aswell. The SPEC results for R8K showed the widest variance for any CPU I examined, it's all over the place, while for general integer performance (which matters for 3D aswell re table lookups and pointer chasing) it's rather poor. For unoptimised FP32 it's less than half the speed of an R5000SC/180 for the Blender test (I suppose one could say that's not too bad given the low clock speed, but remember the cost involved with R8K), sitting last in my table atm (an R10K/150 O2 is more than 3x faster):



http://www.sgidepot.co.uk/perfcomp_RENDER1_blender.html



Without code optimisation the R8K was not a good fit for Indigo2, but I expect some places did the relevant work and got good use out of it, especially those that had already done the work with the big iron (I know Chevron in Nigeria had an R8K Onyx rack, but by the time I talked to them they were already using Octanes for desktops which they thought were awesome).



Ian.
mapesdhs
Octane

Trade Count: (0)
Posts: 89
Threads: 10
Joined: May 2018
Find Reply
03-11-2021, 03:31 PM
#23
RE: The Onyx Desk-side system, much larger than I ever expected!!!???
(03-11-2021, 03:31 PM)mapesdhs Wrote:  Maybe it's a batch issue, perhaps some R8K modules for Indigo2 had issues and those are the ones which gave them a bad rep

Not that I'm aware of, but IIRC the initial PROM version for the PowerIndigo2 had a bug that made it fail the power-on diagnostics once the CPU was warm.

Otherwise, the R8000 is not a chip, it's many parts on a PCB. More parts, more soldering connection -> more likely to fail. Not that this happened to me. I've owned three over the years, one in my collection, one spare, one sold. I think there's even a spare CPU stashed away somewhere -- I've seen the rumors about it too.

No problems so far except a dead PSU, but I can't blame the R8000 for that.
jan-jaap
SGI Collector

Trade Count: (0)
Posts: 1,048
Threads: 37
Joined: Jun 2018
Location: Netherlands
Website Find Reply
03-11-2021, 04:36 PM
#24
RE: The Onyx Desk-side system, much larger than I ever expected!!!???
Ian, can't speak on the R8000 systems since I've never owned one but on the subject of reliability people can view trends over time and also just using basic engineering principles we can see when a design is bad. I've never laid eyes on an R8k so I can't know much though.

I'm the system admin of this site. Private security technician, licensed locksmith, hack of a c developer and vintage computer enthusiast. 

https://contrib.irixnet.org/raion/ -- contributions and pieces that I'm working on currently. 

https://codeberg.org/SolusRaion -- Code repos I control

Technical problems should be sent my way.
Raion
Chief IRIX Officer

Trade Count: (9)
Posts: 4,240
Threads: 533
Joined: Nov 2017
Location: Eastern Virginia
Website Find Reply
03-11-2021, 07:36 PM


Forum Jump:


Users browsing this thread: 1 Guest(s)