iptables. 32 or 64?

[Lisa Kachold]

Hi Joseph,

That is, of course, depending on his hardware and distro?

On Sun, Jul 22, 2012 at 11:18 AM, Joseph Sinclair <plug-discussion at stcaz.net
> wrote:

> In the early 64-bit chips 64-bit mode was slower because the pointers and
> instructions are twice as large, so cache and memory bandwidth were
> overstressed.
> This is compensated for by the fact that 64-bit more has many more
> registers and other enhancements; but early 64-bit versions of software did
> not take advantage of these.
>
> Current kernels actually run faster, in most cases, when compiled 64-bit
> on 64-bit hardware, simply because of the optimizations in place to use all
> the extra hardware available in 64-bit mode.
> For iptables filter/mark you shouldn't notice much difference, if any;
> that path is pretty well optimized in all recent kernels so it runs fast
> regardless.
>
> You will use slightly more RAM in 64-bit mode, so if you're pushing the
> limits of RAM stick with 32-bit.  If you have some headroom (e.g. you never
> hit swap and there's always at least 10% free RAM), then 64-bit should be
> fine.
>
> Also, the "32-bits isn't tested" is old advice; 64-bit testing is required
> for recent kernels and applications, because almost all servers run pure
> 64-bit at this point (even Windows servers run only 64-bit mode).
>
>
> On 07/22/2012 07:35 AM, kitepilot at kitepilot.com wrote:
> > Thanks Lisa, just to clarify:
> > I am compiling EVERYTHING from the kernel up, either 32 or 64, so the
> '64-in-32-userland' issue does not apply.
> > This box will have everything freshly compiled from source from day one.
> > It will be a 'pure' 64 (or 32) box.
> > Now, from distant times I remember that 16 bit processors were generally
> faster than 8 bit, 32 were faster than 16, how come the 64 bit processor is
> slower than the 32?
> > In a 'pure 64' environment does that still apply?
> > I can understand that iptables has not been thoroughly tested in a 'pure
> 64' environment, but why would it run slower?
> > Inquiring minds would like to know...
> > ET
> >
> >
> > Lisa Kachold writes:
> >> Hi!
> >> Great question:
> >> On Sun, Jul 22, 2012 at 4:04 AM, kitepilot at kitepilot.com <
> >> kitepilot at kitepilot.com> wrote:
> >>> Hello World:
> >>> I run my firewall on a LFS box.
> >>
> >> You might also consider a hardened kernel with:
> >> http://grsecurity.net/
> >>
> >>> Everything on it is compiled from source.
> >>> No bells and whistles, only the essential software is installed.
> >>> The hardware is 64 bits but I've been running 32 bit OS.
> >>
> >> 32-bit iptables doesn't work on a machine running amd64 kernel, when run
> >> it reports:
> >> ===
> >> # iptables -L
> >> iptables v1.2.11: can't initialize iptables table `filter': Module is
> >> wrong version Perhaps iptables or your kernel needs to be upgraded
> >> iptables has to be 64bit to talk to a 64bit kernel due to an alignment
> >> issue in the kernel structures for iptables.  So you do need at least
> >> the 64bit iptables binary and associated libs.
> >>
> >> This time around I am wondering...
> >>> The question is:
> >>> Is there any advantage to compiling the whole iptables enchilada in 64
> >>> bits?
> >>
> >>
> >>    - 32 bit is faster than 64 bit
> >>    - 32 bit is well tested, 64 bit isn't tested at all
> >>    - 2039 is still long way off
> >> The only reasons to compile anything in 64bit architecture:
> >>    - It needs to access more than 4GB of memory. In the real world this
> >>    only applies to huge databases.
> >>    - It needs to talk to the kernel directly. Some applications, like
> >>    iptables, contain ugly hacks to support the 64 bit kernel/32 bit
> >>    userland thing.
> >>    - It is a kernel.
> >> For you to talk with your 64bit kernel, you need 64bit iptables!
> >>
> >>> Should it be avoided?
> >>> Please note that the 'normal' rules like 'more than 4GB and/or
> >>> 32-bit-adobe' do not apply here, what I am looking for is whether
> >>> filtering/marking will be faster/slower and (if known) why.
> >>> Any ideas?
> >>> Tnx
> >>> ET
> >>
> >> --
> >> (503) 754-4452 Android
> >> (623) 239-3392 Skype
> >> (623) 688-3392 Google Voice
> >> **
> >> <http://it-clowns.com>Safeway.com
> >> Automation Engineer
> > ---------------------------------------------------
> > PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> > To subscribe, unsubscribe, or to change your mail settings:
> > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> >
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>



-- 
(503) 754-4452 Android
(623) 239-3392 Skype
(623) 688-3392 Google Voice
**
<http://it-clowns.com>Safeway.com
Automation Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20120722/eb1b8278/attachment.html>