Fanless gbit pfSense router?
-
So, use them for something else… I'm sure you must have some need for those cores elsewhere?
I think what he's trying to convey, is that in the industry where multicore has been gaining ground for 12 years; BSD and Pfsense by default, is stuck in the past, sure the old enterprise "it's stable so why change it" applies in quite a few minds, BUT;
everything else has "gotten with the times"cisco, juniper, even UBNT.com's new Edgerouter Lite, are all multicored now.
I can't think of many things that can't (with proper programming) be made MUCH better with multi-core support (SNORT anyone?)
-
Yep - I go that, but in the mean time asterix can make use of those cores and ram for something else running beside pfsense. Maybe some other useful server? By the time that sort of advance is made in pfsense, asterix will have upgraded hardware. I'm just suggesting use those resources in the mean time.
-
Yep - I go that, but in the mean time asterix can make use of those cores and ram for something else running beside pfsense. Maybe some other useful server? By the time that sort of advance is made in pfsense, asterix will have upgraded hardware. I'm just suggesting use those resources in the mean time.
LOL.. you forget.. its on ESXi VM. I have 5 other servers running in there along with pfSense. Dr_Drache got it right this time.. heheh :D
-
So, use them for something else… I'm sure you must have some need for those cores elsewhere?
I think what he's trying to convey, is that in the industry where multicore has been gaining ground for 12 years; BSD and Pfsense by default, is stuck in the past, sure the old enterprise "it's stable so why change it" applies in quite a few minds, BUT;
everything else has "gotten with the times"cisco, juniper, even UBNT.com's new Edgerouter Lite, are all multicored now.
I can't think of many things that can't (with proper programming) be made MUCH better with multi-core support (SNORT anyone?)
Well Snort, Dans and Squid all need to move to multi-core sooner or later.. sooner would be better. But maybe its because of lack of support (maybe lack of enthusiasm ;) ) from FreeBSD on moving towards multicore.
-
"I have allocated all 8 cores, even though pfSense won't be able to utilize them."
That threw me…Cool - Coffee time.
-
Yeah I agree on that. I have allocated all 8 cores, even though pfSense won't be able to utilize them.
You should take a read through some of the docs that explain how multiple vCPUs work inside ESXi. You're potentially harming performance by allocating more cores than you need to. Make particular note of your ready and co-stop metrics.
-
I agree. I will never ever buy an Atom as it makes no real sense when it comes to $ v/s CPU power. Some folks who are using Atom are sorta die hard fans (even when they know within that they should had gone for a G530/i3 ;D ) and swear by it.
Frankly, for a fully loaded UTM I cross out Atom immediately. Even if someone is trying to build even a basic pfSense firewall with no add-on packages, its just makes no sense by not going the G530/i3 route for a few extra bucks, unless you are extremely tight on budget and every dollar counts for your end decision.
It's not about the bucks, it's about heat and electricity use. A D525 Atom uses only 13Ws vs 65Ws for a G530. For a basic pfSense firewall with a couple of packages running, it's barely pushing 5% CPU; so all those extra cycles on the G530 is wasted, and consuming electricity. So over the course of a year, you're paying about 35.00 in extra electricity costs for what? Also, my box can pretty much fabless versus a G530 which would at least require a CPU fan.
I'm happy with the performance, never goes past 10% CPU utilization with the packages I'm running and the processor can easily do 200mbps+ of throughput.
Since sandy bridge the desktop cpus downclock and idle very well, the 24/7 system power gap is not what you think it is. The performance gap is far worse :)
The price difference is small to none, and better to have some breathing room than throw out the whole thing because you get a better isp or want to turn on more modules or run everything through a VPN. (its not like anyone is sniffing your traffic these days…)
G530 don't use 65W and real world users with power meters know it, that is just intel being intel with market segmentation and putting up an arbitrary catch-all number on the ark site.
Today the fast-but-cheap choice is G1610 2.6, 22nm ivy core is even more efficient.
Worst case according to ark.intel.com is 55W, but considering an 200mhz faster i3 with more L2, larger GPU and hyperthreading is rated at 35W, I'm pretty sure the webpage is pure BS. For more illogical specs, I have a E3 1265L V2: 2.5 quad core, eight thread, full feature, full cache xeon that turbos to 3.5 but is rated at 45W.All the atoms so far just suck, behind on process nodes, dated cpu cores and extremely neutered features, all combined with barebone chipsets. At the time they were paranoid about undercutting their bread and butter cpus and wanted to put their older fabs to work printing tons of cheap tiny cores, so atom was crippled from the start.
Now that they are more worried about ARM, atoms are getting first tier design and manufacturing support and doing things like SOC designs. They might actually be worth considering soon.FWIW the euler has cooling headroom, my 3220T barely gets it warm. (cheapest known good choice at the time, I would do different now)
-
Yeah I agree on that. I have allocated all 8 cores, even though pfSense won't be able to utilize them.
You should take a read through some of the docs that explain how multiple vCPUs work inside ESXi. You're potentially harming performance by allocating more cores than you need to. Make particular note of your ready and co-stop metrics.
Not sure if I was clear on stating that I turned off all VMs on that host and allocated the CPUs to just this pfSense VM for doing a simple WAN throughput test :) My typical setup has just 2 individual physical CPUs configured with single cores from each.
-
Yeah I agree on that. I have allocated all 8 cores, even though pfSense won't be able to utilize them.
You should take a read through some of the docs that explain how multiple vCPUs work inside ESXi. You're potentially harming performance by allocating more cores than you need to. Make particular note of your ready and co-stop metrics.
Not sure if I was clear on stating that I turned off all VMs on that host and allocated the CPUs to just this pfSense VM for doing a simple WAN throughput test :) My typical setup has just 2 individual physical CPUs configured with single cores from each.
If you did I didn't read it.
Assuming that you were using a well-threaded application though I'm betting your best bet on a throughput test like this would be n-1 vCPUs. I did some testing on that when I was setting up a XenApp farm on vSphere with boxes a couple years ago that had 16 cores each and my best performance came from (4) VMs per box, (3) with 4vCPUs and (1) with 3vCPUs, followed very closely by (2) VMs per box, (1) with 8vCPUs and (1) with 7vCPUs. When I allocated the last core to a VM and then hammered all of them I started seeing a lot of contention for CPU resources due to the way vSphere schedules. That problem went away when I removed 1 core and essentially left it for vSphere itself. This is far less of an issue if your servers aren't heavily loaded (which they typically wouldn't be outside of a load test).
-
Right now, I can't find a good excuse to run pfsense on a machine with more than two cores UNLESS I want to run some sort of high availability / fail-over scenario. If I had a machine with many cores just for pfsense, I might do that so that I could upgrade in place without shutting down or maybe with round-robbin scenario for higher throughput. Its not necessarily a waste - depending on what is going on.
-
Just FYI.. with 2 virtual socket and 1 core per socket with full 50Mbps WAN throughput on a fully loaded pfSense my CPU consumption is 17%.. up from 8% from 2 virtual sockets and 8 cores per socket.
-
G530 don't use 65W and real world users with power meters know it, that is just intel being intel with market segmentation and putting up an arbitrary catch-all number on the ark site.
That's not an arbitrary number, it's the thermal design power. It does not reflect what the actual power consumption might be in any particular application but rather what the maximum power the cooling solution must be able to deal with.
Steve
-
cisco, juniper, even UBNT.com's new Edgerouter Lite, are all multicored now.
I can't think of many things that can't (with proper programming) be made MUCH better with multi-core support (SNORT anyone?)
Well Snort, Dans and Squid all need to move to multi-core sooner or later.. sooner would be better. But maybe its because of lack of support (maybe lack of enthusiasm ;) ) from FreeBSD on moving towards multicore.
Unfortunately:
-
Some problems are inherently "serial" so can't be speeded up by more cores
-
writing bug free "parallel code is generally still more difficult than writing bug free serial code
-
use of multiple cores by applications such as snort, squid and dans is outside the scope of the FreeBSD kernel - multi-threading applications is the responsibility of the application writers
Substantial parts of the FreeBSD kernel are multi-threaded but the packet filter is not (yet) multi-threaded.
I know of no reason why dans, snort and squid can't run in parallel if there is enough work, for example it is probably possible for each of them to be working on a different packet at the same instant.
-
-
G530 don't use 65W and real world users with power meters know it, that is just intel being intel with market segmentation and putting up an arbitrary catch-all number on the ark site.
That's not an arbitrary number, it's the thermal design power. It does not reflect what the actual power consumption might be in any particular application but rather what the maximum power the cooling solution must be able to deal with.
Steve
I understand the differences between worrying about wall draw and choosing a heatsink very well, and I still think the ark site specs are arbitrary and only loosely based on reality.
They are good at binning their chips, but not so good that with nearly identical cores a 2.8 Ghz chip will not exceed 35W of heat output while a 2.6 could require a 55W heatsink. Their manufacturing isn't that inconsistent, if anything its the opposite.
A ton of 22nm cores are in people's hands now and the voltage spread is very tight at normal clocks. (north of 4 Ghz, the gap widens a lot and then you start to feel the bin lottery)