I'd say depending on hardware.
There is no 'distro' here, it is ALL compiled from source from the kernel
up.
I think that I'm going to give it a shot to the 64 bit...
ET
Lisa Kachold writes:
> 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@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@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@kitepilot.com <
>> >> kitepilot@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@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@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
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)