"Andy Gelme, an Australian software developer who once worked for Cray. He too had a disk pack [containing the OS]."
"For the greater part of the last year, [Tantos, a Microsoft electrical engineer] arduously reverse engineered the OS from the [corrupted / incomplete] image. Despite a few remaining bugs, the Cray OS now works."
I ported parts of a TCP stack to the Cray X-MP in the 1980s. It was so fast that at first I thought it was broken. Hit <return> on the compile command line and the prompt would come right back almost immediately.
All of the early Cray mainframes (even the Cray-1 discussed here, although maybe only the somewhat later Cray-1/S) supported a "Solid State Disk" peripheral, which was basically a refrigerator full of RAM that was accessible via DMA channel. The intent was to be used to swap in and out large data sets from memory - I think even the early ones went up to a gigabyte in size.
Yes, the Cray Solid State Storage Device (SSD) was a standalone unit that looked like a quarter of a Cray, complete with bench. It held up to 2 gigabytes of data in MOS memory and was accessed via an I/O channel at 100 megabytes to 1.25 gigabytes per second. It was used for "temporary storage of datasets" and could "significantly increase data transfer rates." The SSD was separate from the Cray's main memory.
It's my understanding that it wasn't a flash memory based SSD like we would see today, but just a huge amount of RAM (for its era) that could be used as storage. The facilities that typically hosted a Cray could be counted upon to have very reliable power, so the power failure risk of keeping stuff directly in RAM was low.
SGI machines had capacitor banks in the power supplies large enough to power the machine long enough for the kernel interrupt handler to park all of the hard drive write heads. It turns out that the voltage required to keep the write head writing is often less than the voltage required to keep RAM from corrupting. At least for a time, XFS journaling correctness relied on the kernel being able to prevent garbage writes on loss of power.
There used to be big caveats to using XFS on non-SGI hardware. Though, I think those caveats were roughly "XFS guarantees aren't much better than ext3/ext4 guarantees on power loss, on non-SGI hardware".
This isn't about a Cray, but it's roughly contemporaneous. According to https://trs.jpl.nasa.gov/handle/2014/26062, the Cassini space probe had an "SSD," and the contract to build it was awarded in 1992. It sounds like it was pretty much a RAM disk made from DRAM.
I'd imagine it would be practical to build and use something similar for a multi-million dollar supercomputer where cost is secondary to performance.
I have also seen mention of this in spacecraft design discussion. The concept being that for things which are powered from a radioisotope thermoelectric generator, it's safe to treat the RAM as storage.
Because there's absolutely no scenario after launch, in which the constant trickle of wattage flow from the RTG to the onboard DC distribution buses and computers would ever be interrupted.
If the power from the RTG were to ever be cut off it would be a catastrophic mission failure anyways, entirely aside from the power to the onboard computing systems being interrupted.
> I have also seen mention of this in spacecraft design discussion. The concept being that for things which are powered from a radioisotope thermoelectric generator, it's safe to treat the RAM as storage.
I don't buy it. They specifically design these systems with duplication in nature in case RAM gets corrupted by radiation in space. So you can't treat it as storage, but for very different reasons.
Presumably the OS would be in some nonvolatile medium and the SSD would only be used for stuff like storing sensor data anyway. In the event of corruption or a system restart you would lose all of your working data but could bootstrap the system again.
While it would make sense to have recovery routines in some nonvolatile memory to handle a system corruption use case, I'm not sure it if would be necessary for a system restart. IIRC, core-based systems had nonvolatile RAM, and I think at least some of them would continue to execute the same memory image after reset. I think the point of the GP was that one of these DRAM based recorders is basically nonvolatile for all intents in purposes in this application.
It was at the NSCEE (National Supercomputing Center for Energy and the Environment) installation at UNLV for Yucca mountain. There were two vector processors and an amazing 5GB SSD. The OS was UNICOS, a successor of System V and COS (Cray OS), and a user was actually fully swapped out on context switches.
The SSD wasn't new by any means. A decade earlier the Cray-1M optionally could have had an SSD.
I don't think it was battery backed by anything in the Cray, though I could be wrong. The general idea being that the Cray would be installed in a facility that should have massive whole AC circuit, true online type UPS, and generators backing that up.
I think they're talking about the (not battery backed) SRAM, that would have been referred to as solid state storage to differentiate it from core memory technology.
The gigabytes of SRAM used as main RAM you could stick on a Cray was a key differentiator for the platform (and would be still today).
There are many software tools to give you a RAM disk these days on pretty much all major operating systems - even ones that give you a disk based off of GPU memory!
On some distros, /tmp is a tmpfs (ramdisk) anyways. Which of course I discovered when building a package that was bigger than my installed memory (really big package on Arch Linux, which both mounts tmpfs there and then uses it as the default makepkg location).
I really hate this hack. It feels like an attempt by distro maintainers to make their distro feel and/or benchmark quicker than others. I don't know if that's the original reason it was done, but I do know that it's a big pain to work around for a program author. If I'm writing to /tmp, I expect that the file might be swapped to disk, and indeed that it will be paged to disk before the OOM killer comes for me. If what I wanted was named shared memory, I'd put it in /dev/shm.
The message is always heading in the same direction. The relevant variable is the movement between the machine and you. You should probably hope it’s red because if the machine is fast enough that the blue shift is perceivable to the human eye, it might be the last thing you see.
Doom can record game sessions to LMP file format, which is a recording of the inputs on every frame. That's usually how people share runs in the Doom speedrun community. So yeah a LMP-to-video converter could be legitimately useful to some people.
“LMP-to-video converter” is any Doom port which output you can record by common (or less common) means. PrBoom+ has a built-in demo playback recording (if you consider running the console encoders and feeding them sound and image data “built-in”).
CAL was the most programmable (and readable) assembly language I ever got to use, and the machine encoding of the instruction sets of the Cray-1 and Cray-2/-3 were so clean that one could read code straight from an octal dump. I think that something important has been lost since those days.
My favorite anecdote of 25 years on those machines is what we put into the 64-bit word at address 0 on the Cray-2. In ASCII, it read ~Z~E~R~O. If you jumped to it, it worked as four no-op ("PASS") instructions, and at word 1 was a jump to the library's routine that dumped registers and said "hey you jumped to a null function pointer". If you ever saw ~Z~E~R~O in a dump, you knew that a load from null had taken place.
I still wish a modern ISA would implement real vectors; SIMD is still a distant second-best.
Could you elaborate on what you mean by real vectors? It's not immediately obvious looking at the Cray specs what differentiates it from the kind of SIMD we have today.
The Cray vector processors had a set of 8 64-element x 64-bit 'vector' (V) registers, as well as 8 64-bit 'scalar' (S) and 8 24-bit 'address' (A) registers - so it would sort of be similar to 4096-bit wide SIMD. When you did an operation like a vector add, you could do "V0 V1+V2", and it would automatically do 64 consecutive adds, and it would be done in 64 + a few cycles (since the hardware was still only doing 1 add per cycle). As someone else mentioned, it also supported "Vector chaining", so if your next instruction was "V2=V0*V3", it could take the result from the adder and pipe it into the multiplier so now your addition and multiplication are nearly fully overlapped (and you're cruising along at 160 MFLOPS in 1976!). I think it might have supported 3 chains, so you could very briefly peak at 240 MFLOPS, but you couldn't sustain it because of the startup latencies involved.
As a 'practical' example, I was able to write an N-body simulator of Jupiter and 63 of its moons (using the vector registers) orbiting one another in only 127 total instructions!
Another key feature of these architectures is they had a vector length register. This allowed you to write strip mined loops that would move through arbitrary size vectors in units of the hardware vector lane width, without knowing that width until runtime. This means unlike MMX/SSE, the same binary works on machines with different numbers of lanes.
This idea has been resurrected recently with RISC-V and ARM's scalable vector instructions. There the general idea is an instruction that assigns the minimum of an argument value and the hardware vector register length to a register, and sets the masking appropriately if the argument is smaller. This makes for a very straightforward strip mined loop without a branch to check for and handle the remainder in the last iteration.
A few things: Vector operations were controlled by a VL (vector length) register, so the length (simd "width") was dynamic. On the Cray-2/-3, you could set the length to zero, and turn vector operations into no-ops. So vectorization of a loop with an unknown length generated a "strip-mined" loop in which each iteration performed 1-64 (later 128) iterations, and there was no epilogue problem as with SIMD. The last proprietary vector ISA from Cray had a "compute VL" instruction that attempted to smooth out the lengths of the final iterations.
The Cray-1 line could "chain" the results of one vector operation into operand(s) of another without waiting for the first to complete. (On the Cray-1, the later operation had to issue at the exact "chain slot" cycle at which the first result element appeared, so scheduling was fun; on the X-MP and later, "flexible chaining" was possible). Scheduling vector code involved grouping operations into "chimes" that would run as parallel chained operations, and so long as you could pack more vector instructions into a chime without causing synchronization due to register use or blocking on a functional unit busy, you won. Getting a 3-chime loop down to 2 chimes was fun puzzle solving, and if the loop used (say) the floating adder twice, you knew you could stop optimizing.
The Cray-2 didn't chain, but the Cray-3 had "tailgating", which was kind of the opposite -- a new vector result could start writing to a vector register that was in use as an operand without having to wait for that operand use to complete.
It helps to think about these vector machines as being pipelined (which they were). A single chime sequence was basically flowing data from memory to functional units and back to memory without really needing to use the vector registers per se for anything unless an interrupt arrived in the middle of the sequence.
I've seen these in at least two museums (Computer History Museum in Mountain View, CA and the Smithsonian Air & Space Museum in DC). They definitely make for good museum pieces, and you could probably pull enough parts together to get at least one working if you really wanted to pull this off.
Incidentally, a Cray-1 uses 115 kW of power when running. Would that be a new power consumption record for a device that's just running Doom?
I gather it was used to regulate the temperature of the liquid coolant - but instead of just some pipes or whatever, the designers turned it into a nice "waterfall" feature. I think it even lit up.
The first one ever (I believe) is about a block up the street from here. Before Coronavirus, I would stop in and say hello to it, every couple of months.
A museum piece now. Would be great to see it running again. Not likely.
Was there ever a GUI for Crays? I don’t bet on it but think there’s no image to run Doom on GCP or AWS for the same reason, a keyboard is not but a graphical array display is among requirements for void portDoomWithoutReason(); to be called from OnFoundCapableComputerDoomPlayable(machine Box)
One of the purposes of X was to run the work on a super computer and display it back to your desktop. Generally it was expected that time on the super computer was too expensive for interactive use, but you might display back a running simulation to see status.
Ah that seems so obvious now that you mention it - a sort of "thin client" model - but I was genuinely confused finding an X11 binary on a company AS400 the other day. Granted, that machine is older than I am. At least that binary makes sense now.
There is an often cited quote from Seymour Cray when asked about Apple using Cray computers to design the next Apple: "That's interesting, because I'm designing the next Cray with an Apple!"
Some people take this seriously, not realizing that Seymour was being sarcastic. He used pencil and paper to design his computers, not even an Apple II.
Interestingly enough, Jean-Louis Gassée briefly mentions something about using a Cray to develop what was to be an Apple-designed processor decades before it was fully realized https://mondaynote.com/joining-apple-40-years-ago-805114536a... (See a little more than halfway through the article)
It actually has a 150kW 208v 3-phase generator set that provides power to the power distribution cabinet which then uses variacs to transform the voltage to 5v. The genset has a theoretical current output of 415A, pretty serious power!
Ohm's Law says 5.2V @ 770A is only 4.004kW. With one of these on each of the three phases, that's a total of 12,012kW.
So where did the rest of the power go, into cooling? Perhaps it was a linear power supply instead of a switcher? That would make for lots of inefficiency.
The Cray-1 has 36 power supplies: 20 that supply -5.2 volts, and 16 that supply -2.0 volts. (The weird negative voltages are for ECL, the fast logic family used in the Cray.) The bench around the Cray holds the power supplies.
Interestingly, the power supplies themselves are unregulated; regulation is done by the motor-generator unit.
He's also seriously hardcore (or maybe I feel out of depth because I'm a software guy):
> I built a robot that would manually move the head forward 1/5200th of an inch at a time (there are 400 data tracks per inch, so this gives me a whopping 13 steps per data track!), while a high-speed analog-to-digital converter would take the analog signal straight from the drive’s read amplifier and buffer it into an FPGA at a blistering 80 million samples-per-second (like I said earlier, the theme here was overkill…the data was only changing at ~10 MHz or so)
Lol - the 'overkill' approach was mostly one of expediency, since I had spent most of the summer I had to work on this project just trying to get my hands on the disk drive and then powering it on without blowing a fuse. I only had 2-3 weeks to throw everything together, so the 'robot' was basically the Z-stage of a Makerbot 3D printer with some acrylic widgets to push the read-head, then the signal was fed into an analog comparator chip and then into a shift register in my FPGA board. The craziest part is that it worked, and I was able to recover the data!
The FPGA thing isn't that inaccessible to normies like us (i.e. some FPGA Dev boards will easily cost thousands and thousands), but the ecosystem is a complete clusterfuck so getting started is the hard bit. Obviously you need to know electronics too but 80MSPS will let you get away with a lot (The term is signal integrity) of bad circuitry (as I can attest to...).
Verilog isn't too bad as long as you treat it as a description of a circuit (in a language from the past, not even mentioning VHDL...)
When I was in high school we had a PDP System 10 and PDP 11 where I took a programming course on PDP-11 assembly language. It makes me feel old knowing these weren't antiquated at the time.
No but something nearly as bad was typing on punch cards and having to feed them into a card reader to get the code into the computer. And all but one of the terminals was a TTY at 110baud and printed on paper. There was a single Dec VT100/102 terminal you had to get in early to use.
Not my area of expertise but if I had a literally priceless old supercomputer, I wouldn't necessarily want to risk running it outside of its intended operating conditions (especially after 40 years)
Wouldn't that make Doom much harder? In-game adversaries would take advantage and execute vectorized attack patterns supported by cached-ammunition flow. Would Doomguy be able to survive at all?
You should be okay with your Reciprocal BFG as a force multiplier.
EDIT for those who may not have understood my comment. You would be hard-pressed to find a Cray that performed division and would instead need to perform a reciprocal multiplication in constant time.
The Computer Museum in Mountain View has a Cray-I. The last time I saw it, it was at the left side of the lobby, unmarked, and some caterers were using its padded bench seats on the power supplies to stack their stuff.
Has anyone been able to emulate Tandem systems and their OS? That was a interesting high-reliability system, still worth attention. The hardware just cost too much back when it was a product.
There are two in the Computer Museum - one on the left side, you can sit on this one :-). And then one in the actual museum area, this one is opened to show the insides.
> Has anyone been able to emulate Tandem systems and their OS? That was a interesting high-reliability system, still worth attention. The hardware just cost too much back when it was a product.
HPE still sells the Tandem OS, NonStop, and they have ported it to run on x86. Unfortunately, unlike OpenVMS, they’ve never (to the best of my knowledge) run a hobbyist program for it.
I remember porting my text editor to UNICOS (someone loaned me an account on a Y-MP I think): it really only had 64-bit word pointers. The byte offset in such pointers were stuffed in to the upper unused three bits. This meant that address arithmetic had better be done with pointers, and not casted to integers.
Also I'm pretty sure ints were 64-bits.. it's possible that shorts were also 64-bits, but I don't remember.
i remember finding one board of it in a drawer at my university. it instantly felt like a special piece of electronic history, even before i realized it was a cray! (i ran to the old cray in display in the hall and indeed was a board for it :)
I remember a story (perhaps apocryphal) about Seymour Cray showing off the Cray-1 and a hardware bug was discovered during the demo. While the attendees ate lunch, Cray redid the wire-wrap to fix the bug.
.jpg){kind=link}
A guy is making a replica. He had some issues finding the operating system and systems software but he overcame it
Persistence pays off.
I am sure it would be fun to part doom to it. Easier too since the new versions draws Considerable less power.
https://gigaom.com/2014/01/14/the-search-for-the-lost-cray-s...