• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

Multiple cpu|cores

Scheduled Pinned Locked Moved Hardware
8 Posts 6 Posters 8.1k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • K
    kosta
    last edited by May 30, 2008, 6:53 PM

    Hey Guys, hope all is well. Im about to embark on a nifty solution for a couple of projects I have, and wanted to know how pfsense handles multiple cpus. I only saw one or two brief posts about this, so sorry in advance if Imissed anything.

    Does it make sense to have at least cpu's, possible multiple core to run on? I want to build a box that is bullet proof ( of course redundant as well ) and make sure it can handle all of our project needs. firewall/nat/proxy/snort as well as a few other addons will be used.

    Any feedback would be great!

    thanks,

    kosta

    1 Reply Last reply Reply Quote 0
    • C
      Cry Havok
      last edited by May 30, 2008, 7:46 PM

      If you install the SMP kernel you'll be able to make full use of the available cores.

      From a practical perspective, it's largely irrelevant how the cores are physically arranges, whether it's (say) one quad core, 2 dual cores or 4 single cores.

      1 Reply Last reply Reply Quote 0
      • K
        kosta
        last edited by May 30, 2008, 7:48 PM

        So its good idea to use multiple cpu/cores then ( that was the main point of my post if I wasnt clear =] )

        thanks,

        kosta

        1 Reply Last reply Reply Quote 0
        • P
          Perry
          last edited by May 30, 2008, 7:50 PM

          a good read http://www.bsdcan.org/2008/schedule/attachments/66_pfSenseTutorial.pdf

          /Perry
          doc.pfsense.org

          1 Reply Last reply Reply Quote 0
          • C
            Cry Havok
            last edited by May 30, 2008, 8:44 PM

            In general that's always going to be the case for anything that's doing more than one task.  If it's only a firewall then multiple cores is likely a waste.  However once you start throwing in proxy servers, and particularly snort, more processing power and more cores is a good thing.  Memory is also important once you start using squid and snort.  I'd suggest that 1 GB should be the absolute minimum you consider.

            1 Reply Last reply Reply Quote 0
            • T
              thekurgan
              last edited by Jun 16, 2008, 11:23 PM

              If you were JUST running openbsd or freebsd with pf, then one cpu is all you would need. pfsense does many other functions, like drawing graphs, pumping data across http/https using php, dhcp, dns, etc. so other cpus are helpful in that respect, as they offload those duties away from a cpu that can process packets.

              1 Reply Last reply Reply Quote 0
              • C
                cmb
                last edited by Jun 22, 2008, 1:42 AM

                Though pf in FreeBSD is giant locked still (meaning it can't run on multiple cores simultaneously), there are some network throughput benefits to SMP, and given that other services are also running, there are definitely benefits to using SMP.

                1 Reply Last reply Reply Quote 0
                • V
                  Valhalla1
                  last edited by Jun 29, 2008, 10:07 PM

                  the only issue I've seen with SMP is in multi wan configs,  the slbd process which does the load balancing will run away with one of the cores for some reason, and/or spawn multiple instances  on the SMP kernel.  This didn't seem to be a show stopper on my box, but I wasn't running snort or ntop or other cpu intensive things. This apparently will be gone with 1.3 as they transition off slbd I believe

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                    [[user:consent.lead]]
                    [[user:consent.not_received]]