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 > 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 >> >> ** >> >> 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 > ** > 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