[Beowulf] hpl size problems
Luc Vereecken
Luc.Vereecken at chem.kuleuven.ac.be
Wed Sep 28 09:32:19 PDT 2005
At 05:21 PM 9/28/2005, Robert G. Brown wrote:
>On Wed, 28 Sep 2005, Mark Hahn wrote:
>
>>>workstations, because of both security and performance. Things like
>>>ipchains or ipfilters tend to be "expensive" overhead on all TCP/UDP
>>>connections, and overhead in parallel computations is anathema. So one
>>
>>has anyone actually measured this? I suspect that the marginal overhead
>>for iptables is ~1 us, and at least with gigabit, that's almost in the
>>noise (say 3%). I don't think anyone who is satisfied with gigabit
>>would care...
>
>I haven't measured it per se, so this is perhaps anecdotal. However,
>anecdotally I've observed an effect (or thought I did) in years past,
>sometimes to the point where it was annoying in interactive operation.
>I used to turn it off altogether on many systems.
>
>Looking again for the answer to this I did find this:
>
> http://iptables-tutorial.frozentux.net/iptables-tutorial.html#INTRODUCTION
>
>which is basically EVERYTHING you could ever have wanted to know about
>iptables except how expensive it is. Which they likely cannot say
>because after all it depends on the complexity of the iptables ruleset,
>right? Which does damn near regexp-like matching of damn near arbitrary
>combinations of damn near any relevant networking field (src, dst, port,
>service, ip ranges...).
>
>If they've moved this "into" the TCP stack it may have sped it up a lot
>from my early experiences, but there are still a lot of conditionals to
>traverse to make a decision per rule per packet and, may be a lot of
>rules. So maybe I'm wrong here -- it would be lovely if I were, at
>least for a minimal/default (ssh only inbound) firewall.
>
> rgb
Most of the complex firewall rules have to do with carefully defining
what you want to go in, out, or through your machine. However, most
of the trafic/packets are related to a connection that was
established earlier and that was checked and allowed by the complex
set of rules. If you use connection tracking (which you basically
have to to write a robust set of rules that allows more than only
port 22) you can significantly reduces the number of rules that needs
to be checked by putting a check on RELATED/ESTABLISHED very near the
beginning of the ruleset. On my head node, 98-99% of the packets only
go through this one rule. The other 200+ rules are only visited by
unknown connections that need to be checked in more detail (once the
connection is allowed to be made, it's too late to do much checking
later on anyway).
Luc Vereecken
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
More information about the Beowulf
mailing list