FS: Cray j932se 3 cabinet configuration

[Ethan]

Hello all,

I have for sale a J932se Cray system.

Left cabinet contains 6 disk boxes (each holds 4 full height drives),
1 IOS subsystem. Right cabinet contains 1 IOS subsystem, and I have
the
SWS system there. The middle chassis contains the cpu cards, which
contain some HIPPI ports.

No disks, it was a classified system (DOE) so the disks were removed.

Some surface blemishes, the nameplate is 100% intact.

I have pictures of it, just drop me an email if interested. I can
take new ones as well (I have pictures of it, but they are lost in the
maze of files on my webservers).

The system is located in Virginia Beach, Virginia. 4 hours from DC, 4
hours from Raleigh. If you plan to move it by truck, a truck with a
lift gate capable of 2000 pounds is required. The middle cabinet is
the one with the weight, and it is a 6' deep cabinet.

Power is standard "Dryer outlet" 220 single phase 30 amps.

OS not included. Unicos requires a license transfer, so technically
every system has to have the OS relicensed. The SWS workstation also
lacks a disk. At this point I am not aware of any hobbyist programs
like Decus for Cray, but I have a feeling they are getting more and
more requests :-)

Asking $6500 for the system.

Note - I CAN'T EXPORT IT. She is stuck in the US! If you think you
can, arrange for people to handle it and have them contact me.

If your local or want to talk geek, feel free to drop me an email as
well.

Thanks!

-- Ethan / ethan (at sign) 757.org

[John Smith]

Post by Ethan
Hello all,
I have for sale a J932se Cray system.

Have you cross posted this in rec.boat.anchors?

[Cray Guy]

these machines are still quite viable and will blow
any wintel crap away in the benchmarks - even
clustered ... so obviously you've never owned or
used one. The 9323se is a rack cabinet, air cooled
machine with 400Mflop per cpu, typ. 8 Gigs RAM
and high speed interconnect. Unicos is rock solid with
uptimes of half a year to a year. winblows reboots hourly...:)
h

Post by John Smith

Post by Ethan
Hello all,
I have for sale a J932se Cray system.

Have you cross posted this in rec.boat.anchors?

[John Smith]

Post by Cray Guy
these machines are still quite viable and will blow
any wintel crap away in the benchmarks - even
clustered ... so obviously you've never owned or
used one. The 9323se is a rack cabinet, air cooled
machine with 400Mflop per cpu, typ. 8 Gigs RAM
and high speed interconnect. Unicos is rock solid with
uptimes of half a year to a year. winblows reboots hourly...:)
h

And not much bandwidth as vector machines go. a trusty system that
chugs along admirably and hardly ever breaks, and caused Cray Research
no end of financial heartache since nobody wanted maintenance contracts
they were so reliable. Unicos was the gold standard, excepting it is a 32
bit OS written in cal, and hence belongs with the Dead Supercomputer
Society. Hence the X1 uses an Irix based OS, and I believe the X1e (or
X2?) will be a linux port? Even the Crayons move on.

Actually I run a reasonably large center with multiple supercomputers, not
including (among the supercomputer count) an old J we are just shutting down
after roughly a decade. The J is being replaced by an Altix box (also not a
supercomputer), which I am told is also built in Chippewa ;-)) Life simply
moves on.

Your sensitivity is possibly bred by being on the receiveing side of lots of
jokes about your pride and joy, intolerance of linpack ranking, and screaming
but no one hears? (or increasingly they hear but do not understand?)

BTW, what was your J replaced with or are you a used computer broker?

Post by Cray Guy

Post by John Smith

Post by Ethan
Hello all,
I have for sale a J932se Cray system.

Have you cross posted this in rec.boat.anchors?

[a***@spam.acm.org.not]

Post by John Smith
they were so reliable. Unicos was the gold standard, excepting it is a 32
bit OS written in cal, and hence belongs with the Dead Supercomputer
Society. Hence the X1 uses an Irix based OS, and I believe the X1e (or
X2?) will be a linux port? Even the Crayons move on.

Er, no, UNICOS is written in C with the usual smattering of assembly
language. Is it a 32-bit OS? Depends on your definition.

sizeof(void *) = sizeof(off_t) = sizeof(long) = 8; i.e., 64 bits.
(Also note sizeof(int) = sizeof(short) = 8.)

But the largest usable address is something like 35 bits.

The major drawback to putting UNICOS on the X1 is lack of paged VM
support, needed for Posix compliance. And the nonstandard int and short
sizes make it harder to port open source software to UNICOS.

-Andrew Hastings

[John Smith]

Post by a***@spam.acm.org.not
Er, no, UNICOS is written in C with the usual smattering of assembly
language. Is it a 32-bit OS? Depends on your definition.
sizeof(void *) = sizeof(off_t) = sizeof(long) = 8; i.e., 64 bits.
(Also note sizeof(int) = sizeof(short) = 8.)
But the largest usable address is something like 35 bits.
The major drawback to putting UNICOS on the X1 is lack of paged VM
support, needed for Posix compliance. And the nonstandard int and short
sizes make it harder to port open source software to UNICOS.
-Andrew Hastings

Thanks for that - I had though the file system (bless its good heart) had lots
of cal, among other of the good UNICOS features Cray Research developed,
while the UNIX base was c. CRI did much good work there.

My understanding was that UNICOS was not viable to convert to a 64 bit
address system, hence it was left behind. Also understood the SV1 had small
main+SSD only because UNICOS could not handle more than 32 bits of
addressing and that was a relatively graceful way forward at the time. Otherwise
there would have been large main memory. One can also have a 64 bit user
world atop a 32 bit kernel which can work OK. BTW was a pointer 32 or 64 bits?
It has been some years since I delved into the internals of most anything.

I admit to driving spreadsheets and word processors these days, not doing techie
work. Not sure if that is :-)) or :-OO or :-(( but it is a bit more $-)

[Keith Thompson]

"John Smith" <***@microsoft.com> writes:
[...]

Post by John Smith
My understanding was that UNICOS was not viable to convert to a 64
bit address system, hence it was left behind. Also understood the
SV1 had small main+SSD only because UNICOS could not handle more
than 32 bits of addressing and that was a relatively graceful way
forward at the time. Otherwise there would have been large main
memory. One can also have a 64 bit user world atop a 32 bit kernel
which can work OK. BTW was a pointer 32 or 64 bits? It has been
some years since I delved into the internals of most anything.

I've worked on a T90 and an SV1. On both systems, pointers are 64
bits (in C terms, CHAR_BIT is 8, sizeof(FOO*) is 8 for any type FOO),
but presumably not all the bits are used. A pointer to int is just a
raw address. A byte pointer (char*) is a raw address with a byte
offset shoved into the high-order 3 bits of the 64-bit word. Pointer
arithmetic is well-defined in C, and works correctly (the compiler
takes care of the ugliness), but code that tries to manipulate byte
pointers as if they were integers fails badly, though it may work on
just about every other Unix-like system in the world.

[Andrew Hastings]

Post by John Smith
Thanks for that - I had though the file system (bless its good heart) had lots
of cal, among other of the good UNICOS features Cray Research developed,
while the UNIX base was c.

I can imagine that low-level routines altering and searching bit and
byte arrays would be hand-vectorized CAL for performance, but it's
unlikely the remaining filesystem code would be anything but C.

Perhaps you're thinking of UNICOS's predecessor, COS (Cray Operating System,
not to be confused with the current-day Cray Open Source product)? Cray's
original COS (late 1970s) was written in CAL.

Post by John Smith
My understanding was that UNICOS was not viable to convert to a 64 bit
address system, hence it was left behind. Also understood the SV1 had small
main+SSD only because UNICOS could not handle more than 32 bits of
addressing and that was a relatively graceful way forward at the time.

I don't think 64-bit addressing would have been a big problem porting
UNICOS to the X1. As I mentioned, sizeof(void *)=8 so UNICOS is already
using a 64-bit pointer.

One has to differentiate the storage space needed for a data type from
the number of usable bits. The programming environment on the Cray PVP
machines uses 64 bits of storage for all scalar data types (including
pointers) except char.

The number of usable bits, however, depends on the type and the hardware.
Floats, doubles, ints, and longs all use all 64 bits. I believe
arithmetic on shorts uses the A registers, so the bits of precision
depends on the machine (ranging from 24 bits on the XMP to 32 on the SV1).

The hardware requires pointer dereferencing to also use the A registers --
but keep in mind the PVP hardware addresses words (64 bits), not bytes.
So a pointer to character is a 24- (XMP) or 32- (SV1) bit word address
plus a 3-bit byte offset, netting an effective 35-bit (SV1) pointer.
In memory this 35-bit pointer is stored as 64 bits, with the word address
in the bottom 32 and the byte offset in the upper 3.

[Code that assumes this:
char *one, *two;
long diff = (long)one - (long)two;
is the same as this:
char *one, *two;
long diff = one - two;
usually doesn't work on PVP machines.]

So the "small main+SSD" restriction on the SV1 is really a hardware
limitation, not a software limitation.

I like to think of UNICOS 1.0 (1985) as one of the first (if not *the*
first) 64-bit UNIX ports, given the 64-bit long, 64-bit file offset,
and 64-bit pointer. (But again, this depends on your definition of
"32-bit" or "64-bit" OS.)

-Andrew Hastings

[Martin Ouwehand]

Dans l'article <c13j10$877$***@wolfberry.srv.cs.cmu.edu>,
Andrew Hastings <***@spam.acm.org.not> écrit:

] I can imagine that low-level routines altering and searching bit and
] byte arrays would be hand-vectorized CAL for performance, but it's
] unlikely the remaining filesystem code would be anything but C.

I remember a Cray analyst telling me that there was absolutely no
vectorisation in the Unicos kernel, otherwise they'd have to save
the vector registers during the context switches.

[Per Ekman]

Post by Martin Ouwehand
I remember a Cray analyst telling me that there was absolutely no
vectorisation in the Unicos kernel, otherwise they'd have to save
the vector registers during the context switches.

How would that work? Presumably both the switched out and switched in
processes use the vector registers so the kernel can't avoid
saving/restoring them, can it? For system calls I see a point.

*p

[Andrew Hastings]

Post by Per Ekman

Post by Martin Ouwehand
I remember a Cray analyst telling me that there was absolutely no
vectorisation in the Unicos kernel, otherwise they'd have to save
the vector registers during the context switches.

How would that work? Presumably both the switched out and switched in
processes use the vector registers so the kernel can't avoid
saving/restoring them, can it? For system calls I see a point.

There are two types of context switch:
a) Between kernel and user within one process. This happens on interrupts
and exceptions, not just system calls.
b) Between two processes.
UNICOS saves and restores all the vector registers for b) but not a).

A routine in the UNICOS kernel can use vector registers as long as it
saves the user values on entry and restores them on exit. Note that
only the vector registers used by the routine need to be saved/restored,
which may be less than the full set of vector registers. Essentially,
the vector registers are callee-saved registers for function calls within
the kernel.

-Andrew Hastings