This thread originally started with a discussion of issues surrounding
performance of firewalls. At the end of my post I will return to this
issue, but first I need to clear up some issues.
someone else commented on my posting:
> >ATM at 622 Mbits/sec. Our firewall houses an Intel Paragon
> > ...
> 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.
>
> 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.
Our Paragon only runs the bloated OSF (Obese Software Foundation :p )
on a few nodes for Unix-like services where they are really needed,
and runs a lightweight kernel called SUNMOS on the other 1872 nodes.
SUNMOS occupies 250K per node, and has been clocked sending data from
application to application at 175 megabytes/second. SUNMOS stands for
Sandia UNM Operating System. For more information, see
http://www.cs.sandia.gov/~rolf/puma.html.
> 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."
As are most benchmarks. Agreed. That's not what the machine was
bought for and not what it is used for.
> 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.
This is definitely on the mark. I was frankly surprised by the
suggestion of another poster to use a parallel machine for a firewall,
because external I/O is one of the major potential bottlenecks in
firewalls, and this is the Achilles heel of all MP machines. Consider
a machine with an aggregate memory bandwidth at 750 gigabytes per
second using an ethernet to communicate to the outside world
... hmmm.
> If you want to do the PP firewall thing, get a bunch of cheap
> workstations and have each do one thing.
I could not agree more. The internal network would be useless because
different proxies have no apparent need to talk to each other.
As I commented to Marcus, firewalls can suffer from two kinds of
performance problems that I can see:
- an inability to service many simultaneous connections adequately,
- an inability to service one or a few connections at a very high
level of performance.
The former is probably more common, but I provided the example of our
huge MP machine to give an example of the demands that trigger the
second case. The difficulties in using large MP machines are serious
and real, but are essentially orthogonal to the firewalls issues. The
MP machines are producing huge amounts of work for a small number of
people, and stress the demands of firewalls in one direction. Most
people will probably be interested in the problem of many simultaneous
connections, and the approach to solving it will be different. Let's
get back to those issues.
Kevin McCurley
Sandia National Laboratories
References:
|
|
