|
![](/i/fill.gif) |
Warp wrote:
> What would they be replaced with?
A google-like cluster. Distributed processing.
Google is very reliable in its processing too, but it isn't transactional.
The thing that makes mainframes difficult to build is that they're both
reliable and transactional. You can clear 100,000,000 credit card
transactions an hour and not lose any. Contrast with Google, where when one
of their 5,000 PCs doing the anaylisis crashes, they start that bit up again
on a new PC. That doesn't work when you're trying to account for money in
real time.
And, too, it's I/O. The mainframe I worked on in college has 8-port RAM.
One port for each of the two CPUs, one port for the "slow I/O" of printer
and cards, one port for the tapes, and four ports for the disks. I think the
four for the disks were two for the large disks and two for the one fast
disk, which was damn impressive in itself. The fast disk had 6 heads per
track and rotated at something like 10,000 RPM, in spite of this being built
in the 70's and the disk being about two feet in diameter and looked like it
probably weighed 20 pounds just for the platter. It took something like 12
minutes to spin up and 18 minutes to spin down, if I recall.
The OS was arranged so that you could swap out several processes (for want
of a better word) and swap in another set all without rotational latency or
talking to the CPU. The kernel calculated the layout of swap pages on the
disk such that it left enough latency that when the job information table
got into memory (I don't know what Linux calls this, but it's basically the
slot in the table "ps" gets all its data from, the memory maps, etc)...
Well, the system arranged it so that when the job information table got into
memory, the CPU had enough time to service the interrupt and fill in the
list of pages where it wanted the rest of the process to be read into
memory, and then dispatch a disk controller to handle it, just as that first
page was coming under the head of the disk, and the shifting of the
electronics to read subsequent pages took just the right amount of time to
get the next sector under a read head. (Six heads per track, 8 or 16 sectors
per track, leaving about half a sector to switch heads before the next
sector hit.) Lots and lots and lots of care went into the IO processing.
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
![](/i/fill.gif) |