Having the same CPU rising behaviour on our PCEngine ALIX with Nano Intall (2.1.4 stable). In France, we experiment loads of trouble over xDSL connections. Mainly loss, caused even by a bad synchro or by a user that get the line to saturate because of big downloads / uploads. This causes pf to experience a hight CPU load when GW is considered as offline by PF. We did the trick of gateway polling in "Routing->Gateways->Edit gateway" : - Advanced->Packet Loss Thresholds = 20% / 40% (default 10% / 20%)   - Probe Interval = 5s (default = 1s)   - Down = 60s (default = 10s) For what we experienced so far with those values is a better responsivness of PHP UI, and RRD graph shows a fall of CPU load. Still having those settings for test for few hours on PF that are experimenting DSL sync difficulties. It looks good so far, and looks like increasing apinger tests and faillure decision, gives the ALIX more time to execute what it has to execute, and CPU graph falls dramatically (so far…). Sounds to be a good and quick idea to play with the values above.

You should be good for a few years with that though. Unless everyone's gone to 10Gig WAN by 2016! I can't see that happening.  ;) The i350 card you linked to is one of the incredibly cheap type coming out of China. If you buy those direct from Intel they are a lot more expensive. Others here have used them though and had no complaints: https://forum.pfsense.org/index.php?topic=74158.0 Not all reviews are favourable though: https://forum.pfsense.org/index.php?topic=74180.msg408756#msg408756 Steve

@dgcruiser: I know this is a couple months back, but just wanted to chime in: I bought a Supermicro motherboard a while back for a FreeNAS build, and it ended up having a bad temp sensor on it (the CPU fan would be at max RPMs all the time).  You can check the temperatures in BIOS to better see if it is a problem with the sensor itself or with the mobo interfacing with pfSense.  Just a thought. I ended up RMA-ing the mobo and getting a new one.  The temp sensor works fine on the second one :) Hi so temp problem could be because of a defective motherboard?

ic thanks guys :D i think ill with with apu

I am also rocking a Intel I350-T2 over here, rock solid from the day of snapshot 2.1.

@FreeYourMind: Thanks for your reply. I am still uncertain about this, you are absolutely right a few firewall rules here and there won`t affect the performance of the ALIX system very much but if i throw squid + squidguard maybe clamav and snort into the mix i am concerned that the ALIX can handle all that with ease. I dont wanna overkill the whole thing and buying a A1SRi-2758F sounds a little bit overkilled considering the internet connection is only 6MBit but i dont have practical experience with the new ALIX appliances and the Relatek NICs won`t make the choice easier for me. Are they able to handle VLAN tagging properly? The old Alix boards and the new APU have nothing in common.  The new one will meet your needs, the old ones will not if you're using squid, snort, and ClamAV.

The bios doesn't have any fan setting but it may be possible to configure via the ipmi\BMC interface Added the 8GB but that cause a slight issue with the ATX power blocking the 4 dimm slot which may be an issue if i add a second disk for a RAID 1 set-up Replaced the PEG2BPI card with a Dell dual port nic which is seen as 2 Intel (R) Pro/100 Network Connections 7.3.8 The iso image didn't work with Rufus so i used the usb image and then the DD option Just looking at a Intel Xeon L3360 (Quad core 2.83Ghz 12MB L2 Cache) to max out the board

@dgcruiser: I was certainly leaning towards the C2758.  I've heard similar things about Rangeley in other places as well. So, I understand that FreeBSD and pfSense are always lagging behind on the latest and greatest hardware features, but would one of those Supermicro boards at least run pfSense, or is the hardware too new that it wouldn't run at all? Also, I read somewhere that a Marvel controller is used in these Supermicro Atom boards to help with the Quad GbE LAN ports.  Would that be an issue? Obviously, I'm hoping that the boards would at least run pfSense, and then just become more awesome as pfSense matures even more. I've got a SuperMicro C2758 at home and it works fine.  The NICs are Intel i354 with a Marvell PHY.

The TP-LINK TL-WDN4800 definitely won't work in 2.1.4. It should work in 2.2 snapshots though. https://wiki.freebsd.org/dev/ath_hal%284%29/HardwareSupport https://forum.pfsense.org/index.php?topic=70575.msg387318#msg387318 Steve

That number seems to be in dispute currently. Netgate/ESF published some numbers for their C2758 box but at least one member here has reported much better numbers.  :) I would not expect the C2558 to be much behind those, probably identical for firewall/NAT. If you run more than 4 heavy processes you might see if fall behind. Once 2.2 is out the 8 cores in the 2758 will puch it ahead. Steve

At this point 'readily available' for PCI wifi cards is going to mean 'commonly available on ebay'. You might consider using a PCI-miniPCI adapter since there appear to be many more miniPCI Atheros cards available. I second Bryan's point that wifi access points can be had very cheaply these days and offer a number of advantages. There are USB devices which work well. wikidevi is your friend here. Look for cards that feature an Atheros chipset AR5XXX 802.11B+G only. For example the TP-LINK TL-WN651G. Steve

Thank you for getting back to me so quickly!  I certainly appreciate your taking the time to help me out. That's comforting to know that the CPU has more than enough power to handle the throughput I'm looking for.  I wonder how fast it could go before I'd have to upgrade to an actively cooled, rack mounted option? As for the board, I'm hoping the Supermicro will work…I noticed in that bug report that most people were using consumer boards (ASRock, Gigabyte, etc) that were only aimed at supporting Windows and the like, but Supermicro is designed for servers and such so hopefully it has better support for FreeBSD based OS's?  I'm encouraged by the fact that the board that is mentioned in the "working" post is the exact same board I'm planning on using (he used the -L model which is a few bucks cheaper but loses some of the expandability, but it's the same board really). I followed the links in the bug report to an insightful post for FreeBSD in general.  It seems to be a problem more commonly seen with the Intel NUC boards using Baytrail-M, if I'm reading it correctly. I'll certainly keep it in mind, though, to make sure the vendor does returns if I end up going with it! Does anyone else have any input/suggestions?

What I meant was that with a normal AP you'd expect your client to be fast at 5/5 and get progressively slower until the signal drops at 0/5.  With the LR AP, the client still thinks it has a decent signal at 1-2/5 but most lack a transmitter powerful enough to get data back to the AP.  My example wasn't talking about absolute distance from the AP, but apparent signal strength on the client.

Thanks Steve. I shall try and experiment with whatever ESXi is now called before I buy a new box. I really appreciate the time you have taken to respond to my questions.

REVO South Africa dude??? @roccor: nah the new cabling alleviated that.  I'm rocking out with my **** out now!.

@jimp: … no, there is no way to do that on NanoBSD. You could mount the card on a FreeBSD box (or another pfSense box) and copy the config over, but for most it's easier to put the card in, boot it up, and then restore the config from the GUI. Could you please provide me with the location in the file system to copy the config.xml to? No modifications of the backup file necessary with and w/o RRD data?

Did you purchase the unit from Netgate? Or somewhere else? The Netgate APU firmware should have LED support, but I'm not sure if that's setup in a way that will work with either gwled or blinkled yet.

Nope, you shouldn't have to restart it ever (within reason!)  ;) What are the symptoms? Anything in the logs? (if you can reach them) What sort of traffic levels/types are you putting through the box? A common cause of the box stopping routing is running out of space in the routing table or some other state exhaustion. That can often be caused by torrent traffic or similar high connection numbers. Which interfaces are you using? I've never seen a problem after adding that one line to /boot/loader.conf.local but some other users have recommended disabling MSI globally. I've not seen any evidence that that helps and it removes the ability of anything alse to use it robbing the system of interrupts. Steve