POV-Ray : Newsgroups : povray.off-topic : Weren't we talking about mainframes here? : Re: Weren't we talking about mainframes here? Server Time
3 Sep 2024 21:15:49 EDT (-0400)
  Re: Weren't we talking about mainframes here?  
From: Darren New
Date: 2 Aug 2010 15:56:07
Message: <4c5722d7@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.