[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