A couple months ago we got an IBM RAMAC disk array. This box is like Raid++. 1.6 Terrabytes, double redundency (meaning recovery from any dual drive failure), battery backup 4 Gig cache, hardware compression, self tuning, 8 fibre channels...

Today we powered up the new brain, a dual CPU model 2003 CMOS mainframe. Sort of like a dual CPU motherboard, but with 2 System/390 processors! They're tightly coupled, so you can run a string of instructions on 1 CPU, and after a task switch, pick up of the other CPU if it's free first. About as parallel as you can get in this architecture.

Pretty cool to see CPU usage at 200%... :grin:
Posted on 2003-04-14 22:49:56 by S/390
Cool, can you play PONG on it ? :)
Posted on 2003-04-14 23:10:45 by donkey
S/390, I'm sure you'll find new and interesting way to fully utilize that hardware - have fun! :)
Posted on 2003-04-15 00:03:20 by bitRAKE
Did you see my Linux on the Mainframe post:

"His test system finally ran out of resources at 41,400 Linux images"

Yea, I'ld say we can do PONG. Maybe 100,000 games at a time... :grin:
Posted on 2003-04-15 00:04:10 by S/390
I can emulate 1000 z80's on my PC - maybe you could do a few million? :)
Posted on 2003-04-15 00:19:30 by bitRAKE

battery backup 4 Gig cache

A disk cache for the raid stuff? Or?

Sounds like a bit of a monster anyway.
Posted on 2003-04-15 02:21:32 by f0dder
We get a fibre channel library with 13.7 TB space and a bunch of 2GHz CPUs soon at work :)

I have a few days off now, else I could check the vendor :(
Posted on 2003-04-15 04:12:58 by bazik
bitRAKE,

Sadly, much of the new CPU power is already accounted for, thanks to all these darn COBOL (and RPG) programs. If everything here was Assembly, we wouldn't need a 2nd CPU. :rolleyes:

f0dder,

Yea, it is sort of a monster. :grin:

One of the things the array cache provides is "fast write" support. The CPU can send a block of data at full channel speed, freeing up the channel that much sooner. The drive controller operates on the "back end" and deals with seek and rotational delays, and writes the data at it's own pace. If there was a power failure between the time the channel thought it was done with the data, and the time it takes to actually write it, the data could be lost. Hence the battery backup for the cache. Any unwritten cached data is recorded to the drive when powered back up.

:)
Posted on 2003-04-15 21:48:36 by S/390
Seti@Home ;)
Posted on 2003-04-15 23:19:21 by jademtech
hrm, still sounds a bit confusing to me. Is the "backend" storage slow, or is the cache drive goddarned fast? I would have thought the backed would have been striped, and thus able to operate faster than a single drive? :confused:
Posted on 2003-04-16 02:37:49 by f0dder
f0dder,

Yes, it is striped. But the mechanical delays of head movement and drive rotation are still slow, even on the fastest drives, compared to the electronic speed of fiber to cache...

:)
Posted on 2003-04-17 20:32:24 by S/390
S/390,

It sounds like a great toy. :tongue:

Regards,

hutch@movsd.com
Posted on 2003-04-18 04:14:17 by hutch--
Ok, I still don't get it. Is the cache a disk drive, or a huge amount of memory? Or a solid state drive?
Posted on 2003-04-18 07:25:04 by f0dder
When I read or hear cache, I always assume it's memory. You can think of it as a big buffer. Logically, it stands between the slow storage device and the speedboat needing access to it.

IIRC, you can connect more than one device on an IBM mainframe channel. Thus the desire to "free" up the channel as quickly as possible.
Posted on 2003-04-18 15:13:12 by tenkey
I too think memory when I hear the word cache - but the addition of "4 gig"... :P
Posted on 2003-04-18 16:44:04 by f0dder
Well, I can get 512M on a single memory stick, so eight of them will be 4G bytes.
Posted on 2003-04-18 18:42:08 by tenkey
I have a couple 512M DDR sticks and 2GB DDR is avaible if you have the money - I am certain it is memory.
Posted on 2003-04-18 20:34:57 by bitRAKE
tenkey is correct, on both points. :grin:

The cache is exactly that, a big memory buffer, between the channel speed and drive speed.

Also correct that a channel is connected to many devices, but only talks to one at a time. The mainframe does have multiplexer channels, but they're normally used by slower devices, like modems and some terminals. Multiplexer channels can interleave bytes from many devices, and reassemble them on the other end. But block channels (or selector channels for you old timers) are used by fast devices, like disks and tapes.

Actually, there's a third level in the architecture, the "control unit". In theory the channel talks to the control unit, and the control unit talks to the devices. In some cases, the control unit and device are the same box, like a printer. But many times, like a string of tape drives, the control unit is a separate physical box. For example, a row of 8 tape drives can be connected to a single control unit. If that control unit has only one channel path, then you can talk to only one drive at a time.

But some control units can have multiple channels attached. Traditional IBM disk controllers often came with 2 or 4 channel connections. This means that they can transfer data with up to 4 separate drives at a time, out of the 16 attached to that control unit.

Today we have the RAMAC array, that can be connected with up to 16 fiber channels at a time (we "only" have 8). In the "old days" of copper channels, it really didn't matter if you kept the channel busy while the drive recorded the bits, since the speed difference really wasn't that much. But with the speed of fiber, it's sort of silly to keep the channel busy, while you wait for the drive to spin enough to be able to write the next bit.

So, one of the things the array cache does is allow the channel to dump its load of data at full speed, disconnect, and go start the next I/O operation, aka "fast write". The cache is also the work area between the uncompressed data on the channel, and the compressed data that's actually recorded on the drive. And just like the old SMARTDRV cache used read ahead, the array cache can have anticipated data ready with 0 physical I/O time, since it stages entire tracks.

Considering all of the things that it does, and considering that it tries its best to keep 16 fiber channels busy, I'ld say 4 gig is a pretty good compromise.

:)
Posted on 2003-04-18 22:54:35 by S/390