SGI: Hardware

Octane 2 Hardware schematics and assembly drawings sought I a Searching for Octane2 Hardware schematicsandassembly dra

Octane 2 Hardware schematics and assembly drawings
hi All,
I am searching for Octane 2 Hardware schematics and assembly drawings but finding nothing so far on the web or Wikie. My first question is has this stuff ever been released.? If yes; a pointer to source please.

I need any information how the Octane 2 is put together. How the frame (main enclosure) electronics is hooked up details of any wiring loom, wiring diagrams, connector pin outs etc. The sort of thing required to trace signals with a DVM pin to pin (cold system) or with a scope or logic analyzer, classic hardware support gen.

I also need full hardware board gen such as any schematics, technical description etc of the IP30 processor tray (motherboard?) and the Vpro V10 and V12 graphics trays, not forgetting the SCSI back plane and X-Bow (version 1.4) (have I missed out anything from the list?)

Appreciate any help on this as still feeling my way into this Octane 2 box.

OBB :) :)
OldBlueBear wrote: I am searching for Octane 2 Hardware schematics
but finding nothing so far on the web


And don't you guess why?

OldBlueBear wrote: The sort of thing required to trace signals with a DVM pin to pin (cold system) or with a scope or logic analyzer, classic hardware support gen.


What is the purpose, btw?
Head Full of Snow. Lemon Scented You
OCTANE 3 4
-----------------------------------------------------------------------
Hey Ho! Pip & Dandy!
:Octane2: :O2: :Indigo: :Indy:
-----------------------------------------------------------------------
uunix wrote: OCTANE 3 4


LOL :lol:

Which is supposed to be based on the last i9 by intel? (fresh news, it's now available)

Image

In the meanwhile I am observing how damn complex (a professional EDA cad like) Altium goes when you design a motherboard. From my point of view, everything runs of out control as soon as you need more than six layers.

SGI-mobos have twelve levels.

So, even reverse engineering is not a piece of cake, and it is very time consuming. It's one of the reasons why we don't have hardware schematics and detailed documentation.
Head Full of Snow. Lemon Scented You
Are you kidding? Even most OSHW doesn't include all that.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
Include what? :D

I emailed a couple of guys who works for Apple-USA (found their email-addresses included within linux sources), asking them for a few hardware and firmware details on a more than *fifteen years old* laptop. Copyright usually expires after ten years, so my question was formally viable, indeed they replied ... that ... they can't reply on this kind of question, so you are all alone, flesh and bones, with what is included within (linux? open-)sources, and this is the only gift you will get from Apple.

SGI guys have never replied to my emails, I am still confident ... some day ... I will find something close to my door, like a message in the bottle, ground shipped to escape internal badass-cops controls.

So, back to Apple-story, I spent a couple of weeks, an hour per day, back from my job, to reverse the keyboard's map, the pad-chip and its protocol.

At the end, I throw my whole laptop away, as reversing such a things is destructive, but it's fine for me since I wanted to develop my own adapter.

Image
Preliminary

Just to say - how long -, and - how much - effort you have to invest even in simple things :D
Head Full of Snow. Lemon Scented You
OK I asked and the reply is about what I expected - not out there. Thanks anyway for the feedback.
Why I would want it: well SGI stopped production in June 2004 of the Octane 2. So if you look at normal MTBF for it's sub-assemblies and their component parts. Bits are going to have started to fail after 14+ years even for the newest machine, last off the line. To keep it running over time you need this sort of information or you consign a perfectly good system to the scrap yard when the supply of replacement sub-assemblies dries up. With the right gen it should be possible but not easy to fault find to the component level with good documentation.
That was the reason I asked . The alternative is to run two identical systems and use the "good" machine as a part replacement for in depth documentation when the second machine goes down. OBB.
OldBlueBear wrote: if you look at normal MTBF


The 'Mean time between failures' is usually referred to continuous working condition, so the probability that 'machine which has been working for a certain amount of time 24h/24 might have a failure' is assumed to be quantity X is a 'time-to-failure' described by the Weibull distribution which gives a distribution for which the failure rate is proportional to a power of time, and such a probability is virtually equal to 1.0 (certain event, a failure is going to happen soon, if it hasn't already happened) if the process time has elapsed the Tao constant by a confidence factor.

X: failure
p(X) = probability of failure
if process-time > K * Tao then p(X) =1, X: is a certain event

K is confidence factor, which depends on your experience about the process. You can calculate Tao, as well as the equivalent Tao of a capacitor discharge, which is also equal to the first law of Newton which describes how a body becomes cold (first approximation of the differential Heat equation).

They have all in common the characteristic of being an exponential function.

So you can invert the equation with a logarithm, and this gives you the predicted failure time.

So what?

Can you replace the hardware? Yes.
Do you need any detailed documentation (schematic) to do so? No, you just a good soul who sells you the part for a decent price.

Can you redesign the hardware with modern components? No, unless you are a company like SGI, or an hardware guru.

Can you simulate the whole SGI machine on a PC? Well ... might be ... a project like this is currently on the way, aiming for the emulation of a (simpler than Octane) IP22-Indy. Still not completed. Fingers crossed.
Head Full of Snow. Lemon Scented You
Probability of Failure (POF) equates to (FF + SRFF) - (QHM + KPE)

FF = FSCK FACTOR. (How inconvenient it is if it fails now.. that is, was you planning on doing something more interesting than fault finding)
SRFF = SOME RANDOM FSCKING FACTOR. (The seed of this number is possibly based on how much sun light is left in your day - The less sunlight the higher the number).
QHM = Quantity of Hail Mary's you perform before you turn on ignition.
KPE = Karma Points Earned (letting people out at junctions (more points for buses) during the day).

The secret of starting a Silicon Graphics Machine.
-----------------------------------------------------------------------
Hey Ho! Pip & Dandy!
:Octane2: :O2: :Indigo: :Indy:
-----------------------------------------------------------------------
The FSCK factor can never be wrong, as we can talk as long as we want, the the Entropy grows up anyway :D

Fellows on Google believe in 'Saint Weibull' and they take it seriouly as it was a prediction from their own personal oracle! They have mastered the confidence factor, so when the K * Tay says it's time to replace a machine, they do so, even if the machine is still (apparently?) in working condition.

I say 'apparently' because it's a mathematical model of the state of things as they actually exist, as opposed to an idealistic or notional idea of where p(X) is always zero, as the assumption that things never go broken. So, from the point of view of Saint Weibull, when K * Tao has passed then ... it's like talking about a dead iron walking on the tiptoes on the border of the collapse. The Google business model is based on this, and it assumes it's a good description, so they replace their hardware according to the predicted failure-time before a real failure happens, and they are happy as this means 'zero stop time' for their servers.
Head Full of Snow. Lemon Scented You
What I am starting to worry about with the age of the SGI gear are things like PROMs decaying, whether single (E)PROM chips or inside other things like PLDs. Supposedly they have a ~20 yr lifetime from when written.
:Indy: :Indy: :Indy: :Indigo2: :Indigo2IMP: :O2: :O2: :Octane: :Octane: :Fuel: :Tezro:
:Indy: [x19] :Indigo: [x7] :O2: [x4]
Elf wrote: What I am starting to worry about with the age of the SGI gear are things like PROMs decaying, whether single (E)PROM chips or inside other things like PLDs. Supposedly they have a ~20 yr lifetime from when written.

That's why I've made backup copies of them. That includes GE boards of GTX or VGX graphics. I already had an EPROM burner, the other day I received an UV eraser as well :)
:PI: :Indigo: :Indigo: :Indy: :Indy: :Indy: :Indigo2: :Indigo2: :Indigo2IMP: :Octane: :Octane2: :O2: :O2+: Image :Fuel: :Tezro: :4D70G: :Skywriter: :PWRSeries: :Crimson: :ChallengeL: :Onyx: :O200: :Onyx2: :O3x02L:
To accentuate the special identity of the IRIS 4D/70, Silicon Graphics' designers selected a new color palette. The machine's coating blends dark grey, raspberry and beige colors into a pleasing harmony. ( IRIS 4D/70 Superworkstation Technical Report )
jan-jaap wrote: That's why I've made backup copies of them. That includes GE boards of GTX or VGX graphics. I already had an EPROM burner, the other day I received an UV eraser as well :)


You are the future saviour of the SGI fans around the world, then. =)
Image Image
Elf wrote: Supposedly they have a ~20 yr lifetime from when written.


Bah, when I worked with Beckman (a German company) they sent me on a far oil-platform because one of their equipment was offline. Once there, I found a metallic tube whose thickness make you think it can survive an atomic bomb (10Kg of metal with a battery). It took a quarter of hour to unmount it, just to access the electronic, and once done, I found an old MC68HC11-A in DIP48 package attached to a latch attached to 32Kbyte of static-ram and 32Kbyte of UV-ROM. Typical '80-90s design. There were of course other circuits around, including a RS485 module on the bottom of the tube, in current loop.

The real reason I was there: to replace the equipment with a new modern one, based on ARM-chip. So, I removed everything, and I installed the new equipment. Then I repeated the procedure for all other equipment-points, at the end of the week everything got updated. So I went back home.

You say ~20 yr lifetime from when written, I say the apparently-dead-node has pumped a lot of oil in its life. The label on the EPROM says "Beckman, 1989".

2016 - 1989 = 27 years old equipment. I replaced twenty one nodes, only one of twenty one was defective in a windows of 27 years! Awesome! The MTBF prediction was wrong by seven years.

I took all the old PCBs back with me, and I had a chance to investigate the defective one once I got to my hotel. Well do you guess where was the failure?

I thought the PSU. Checked, It was not
I thought the UV-ROM. Checked, It was not
I thought the RAM. Checked, It was not
I thought the CPU. Checked, It was not

At the end the node was offline because a capacitor on the RS485 module had decided to die (thanks god without releasing acid on the pcb). So everything was alive, but unable to communicate.
Head Full of Snow. Lemon Scented You
jan-jaap wrote: That's why I've made backup copies of them. That includes GE boards of GTX or VGX graphics. I already had an EPROM burner, the other day I received an UV eraser as well :)

Thank you :)

Y888099 wrote: You say ~20 yr lifetime from when written, I say the apparently-dead-node has pumped a lot of oil in its life. The label on the EPROM says "Beckman, 1989".

With the large cell size certainly the old EPROMs have stood up well. But even so it seems like their eventual failure is inevitable, as the charge slowly leaks out. In any case I expect they will do better than modern flash.
:Indy: :Indy: :Indy: :Indigo2: :Indigo2IMP: :O2: :O2: :Octane: :Octane: :Fuel: :Tezro:
:Indy: [x19] :Indigo: [x7] :O2: [x4]