someone write:
>ATM at 622 Mbits/sec. Our firewall houses an Intel Paragon
>supercomputer that set a record for the fastest MP linpack this year.
>To give you an idea, it has 38 gigabytes of RAM, 330 gigabytes of
>internal disk,
>and about 3,840 50Mhz processors.
yes, and it's a big clunky piece a crap that runs an OS so bloated one
can only get reasonable performance by running user codes almost
directly on the metal. That linpack record is sort of like saying
"Well, my '84 MBZ is the fastest car in the world after I replaced
half the parts, got a dedicated track, a team of support engineers,
the wind from my back, the moon ahead of me, blah blah blah."
I helped program/run one of those boat anchors for NASA for a year or
so. The OS takes at least 6MB of ram *per node* just to boot, is a
full OSF1/AD kernel running on a Mach microkernal and destroys any
hope of reasonable performance out of a grid. If one hand-codes
everything (as David Scott so excellently did on the iPSC/860), one
gets great *vector floating point* performance. (Which is not scalar
IO performance, the i860 really sucks for that.)
Oh, and that's if you can get it to stay up and running without
someone watching over it all the time. Ask yourself why we had to
have at least one, if not two, on-site people from Intel to help our
experienced team take care of our Paragon. Ask us why it sat idle
while people used the "old" iPSC/860 and CM-5 systems.
Its "parent", the iPSC/860, is a fine workhorse once one gets used to
programming it. The Paragon is moderately useful for electromagnetic
codes, and that's about it.
padgett> thing about PP, the boundary equations and crossbars, would
padgett> not be a problem since each would be essentially independant.
unless, of course, the IO paths routed across one another. A big
problem with the Paragon (and most MIMD parallel supers) is getting
data in/out of the system without hosing various processors.
On the Paragon, *ALL* io to disk/network goes through a small cluster
of dedicated IO nodes. On the CM-5, it goes through one of many
dedicated backplanes. On the iPSC/860, it mostly goes through a very
slow, 386-based IO node.
The problem is that each node would have to have its own IO. At that
point, you've wasted a huge amount of money on the cross-connects,
which are sitting idle.
padgett> The real point is that PPs are inherantly scalable,
padgett> reconfigurable, and with a bit of effort, redundant. Are any
padgett> firewall vendors working here ?
I hope not. I hope they get way, far away from anything other than
simple MP/SM systems (Sparc-20/1000/2000, big SGIs, etc.)
If you want to do the PP firewall thing, get a bunch of cheap
workstations and have each do one thing.
A guy who spent about 6 years doing parallel systems programming and
benchmarking and trying to keep the damn things running and usable,
not getting any sleep because they kept crashing if you did anything
slightly abnormal in your code, yelling at vendors to fix
work-stopping bugs, and who misses every second of it. :-)
--
J. Eric Townsend vox #: USA 408.774.4252
work: jet @
genmagic .
com AT&T PersonaLink: A5803643645 @
attpls .
net
play: jet @
well .
sf .
ca .
us or get my card from directory information
Follow-Ups:
|
|
