5 Oct
2007
5 Oct
'07
4:20 p.m.
On Fri, Oct 05, 2007 at 03:14:52PM -0400, Tim Shoppa wrote:
As far as I'm aware - correct me if I'm hilariously wrong - mainframes
were (and are) less renowned for their raw number crunching power but
more for massive I/O capabilities and the ability to translate that into
a metric arseload of parallel activities (sessions, transactions, ...)
going on at the same time.
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Will wrote:
Oh, the one emulate-mainframe-on-other-CPUs approach I'm remotely familiar
with was emulating BS2000 maainframes (the SIEMENS version of a slightly
modified S/390 with their on version of the OS on it) on SPARC CPUs running
Solaris. They used a two-pronged approach:
- non performance critical path: simply run /390 (their version of
the S/390 architecture) machine code in an emulator
- performance critical path (sorting routines and stuff): treat /390
machine code as high level language, compile to SPARC machine code
and load that inside the emulator
To set it all up, they took a standard Fujitsu-SIEMENS SPARC machine
(reasonably similiar to SUNs stuff, I believe) with stock Solaris and
proceeded by ramming a _honking_ big kernel module down the throat of
Solaris to speed things up with tricks like grabbing a huge chunk of
memory away from Solaris and mucking around with the VM setup themselves
and so on as well as containing the emulation environments guts and
running them in kernel space.
It appeared to work - they even offered what machines as "mainframe and
UNIX server in one box", basically a SPARC server with their mainframe
emulation environment in there.
That, btw, was the second generation approach. Their first version of
that apparently was based on using MIPS based machines and massively
molesting the kernel of their own UNIX variant to support the mainframe
emulator infrastructure. The guys we talked to told that the SPARC based
approach was much less complex and much faster as well.
They apparently also were emulating much of the mainframes I/O
environment in terms of storage and communication links and mapping them
to what was available on the host system. And they even went as far as
clustering their UNIX/mainframe machine bastards into a failover
cluster.
All of this information was gleaned from a trip our operating
systems professor organized to their (SIEMENS) mainframe development
labs while I was studying CS and was around 1999/2000 or so. So consider
it with a grain (or more) of salt ;-)
I wrote:
> The ECL technology used in the VAX9000 was gate arrays with roughly the
> same timing parameters as 100K ECL (0.5 to 1.0 ns propogation delays).
Yes, but I do not think that was the cutting edge
anymore. Considering
the 9000 was supposed to be the machine that finally convinces the
mainframe world to accept DEC, it may have been a poor choice. We
probably will never know. 9000 may have been as big of an
embarrassment as the KC10.
The 9000 was obsoleted by the NVAX chip before the 9000 hit the street.
"the mainframe world" acceptance of a CPU is the stupidest-ass thing
a company could ever ever want. On a.f.c there were some references
to emulating Unisys architectures on Intel hardware, and I followed the
links to the trade press rags, and the rags were filled with a bunch of
useless self-important balloon-filling about CPU technologies with no evidence
that anywhere anyone understood what the emulation layer actually
did. I came away not knowing what the emulation layer actually did either I am thinking
raw horsepower - all the benchmarking stuff. Looking at
the KL10 (or the other DEC ECL machines), it justs seems like they
should have been better number crunchers.
Mainframes are really good at some things, sometimes they are decent
number crunchers in terms of pure FLOPS but it has been three to four
decades since they delivered any punch in terms of FLOPS per dollar.