Which Intel Core processor (Haswell) for 120+ Mbps with IPS and web filtering

Any of you guys noticed fluctuating speeds as of late?  I still need to just hook directly into the modem to see if I see the same results, but from places I use to get 1.5-2.5MB/s I'll be lucky to get 500-700Kb/s.

I even turned off IPS and HTTP Proxy and still see the same.

Hi, I'd check ifconfig for interface errors, but it sounds like an ISP or upstream issue.

Barry

So if I were try to draw a conclusion from this for improving IPS performance, what tips would I draw? Conceptually it sounds like we need to force/trick the CPU into running at full speed because modern Intel CPU's are too aggressive in scaling back for power consumption reasons.

What suggestions would you give for:

1) Bare Metal (Appliance or Software)
2) Virtualised (ESXi or Hyper-V)

Hi Drew,

What connection speeds (LAN->DMZ and/or Internet) are you looking at, and how many users?

fwiw, this isn't just the CPU's fault, it's also the OS Kernel (Linux) for using an obsolete scaling algorithm. 
In fact, the CPUs now perform better at the same idle power with any of the algorithms, so the CPUs are actually much better than 3 years ago when there WAS a big power penalty for not cutting the idle clockspeed.
Even Windows 8.1 has the same problem, at least when on 'balanced' mode. I haven't tried 'performance' mode on Windows yet, but I think you still have to override the idle settings. 'Balanced' mode won't even let you change the idle in Windows.


Assuming good NICs (Intel, Broadcom)...

For under 100mbps and just a few users, any i3 is probably fine. A faster CPU would improve the A/V performance, but IPS shouldn't be a bottleneck.
A new Avoton (Atom) system might be OK also, but I haven't seen one actually tested.

For up to 300mbps, the fastest i3's should be fine for couple users, and an i5-4670 should handle several to many users at that speed.
For LOTS of users at that speed, an i7-4771 or the fastest Haswell Xeons (but note the clock speeds are lower on the Xeons). Maybe even Active-Active clustering if the CPU loads are still too high, and/or create some IPS exceptions for local/DMZ traffic.

Based on my testing, it is not possible to get more than about 300mbps of HTTP traffic through the IPS for a single user, on ANY CPU (nothing really has a faster clock speed than the i5-4670).
For multiple users, the multiple cores should help the multiple Snort processes achieve higher total bandwidth, although I have not personally tested this myself.

HTTP seems to be the worst case for the IPS (presumably lot more Snort tests & rules for HTTP). Other protocols should be faster based on my Iperf tests, but I don't have a fileserver fast enough to confirm that.

Another user reported 500-600mbps through the IPS on a Xeon to his DMZ with a file server protocol and multiple users; I don't remember if it was NFS or CIFS though. I wouldn't be surprised if an i5 could achieve that as well.

All of the above holds true for virtualized as well, but add more cores if you'll be sharing the CPU with other VMs. I don't know how much of a performance penalty ESXi or Hyper-V add. 
My understanding is the penalty should be small in ESXi if you use modern server-grade NICs and the VMXNet3 drivers.

Maybe William can speak for Hyper-V?

For over 200mbps http, if you don't have a lot of users, or a busy proxy / A/V, you're going to have to 'trick' the CPU by either using the 'performance' setting I mentioned earlier, or doing the equivalent in the BIOS and/or ESXi.
Again, there's no power penalty at idle for doing this, and the load power shouldn't be significantly worse as with the faster setting it'll get back to idle more quickly, so it might even be more efficient. Worse case, it might use a few watts more at medium load.

Barry

Hi folks,
more testing stuff.
Just ran the same tests with the same configuration on the i3-3220t system. In summary, 10 watts less peak, 100Mb/s more with snort and peaking to 700Mb/s without snort.
Snort ran to 90% cpu and 3% mem.

Hi Ian, are the NICs better in the your i3-3220t system (compared to your other i3)?

Barry

So if I were try to draw a conclusion from this for improving IPS performance, what tips would I draw? Conceptually it sounds like we need to force/trick the CPU into running at full speed because modern Intel CPU's are too aggressive in scaling back for power consumption reasons.

What suggestions would you give for:

1) Bare Metal (Appliance or Software)
2) Virtualised (ESXi or Hyper-V)

Any of you guys noticed fluctuating speeds as of late?  I still need to just hook directly into the modem to see if I see the same results, but from places I use to get 1.5-2.5MB/s I'll be lucky to get 500-700Kb/s.

I even turned off IPS and HTTP Proxy and still see the same.

Hi folks,
more testing stuff.
Just ran the same tests with the same configuration on the i3-3220t system. In summary, 10 watts less peak, 100Mb/s more with snort and peaking to 700Mb/s without snort.
Snort ran to 90% cpu and 3% mem.

Ian[:)]

Update:

I installed the Beta, and updated to 9.171.

Power consumption:
31W idle with 2 NICs plugged in @ 1gbps (Atheros NIC unplugged)
(27-29W all NICs unplugged)

31W with Iperf port 80 @ 120mbps 
55W with Iperf port 80 @ 300mbps AND openssl test running (see notes below)
my expectation is that typical home power consumption would be 31W unless under heavy load. Note I am not running the HTTP proxy though.

Some basic Iperf test results are at:
http://www.astaro.org/gateway-products/hardware-installation-up2date-licensing/49427-ips-performance-tests-hardware-benchmarks-unofficial.html#post250520

William is absolutely right about the CPU throttling affecting performance.
It is so bad that I suspect even a dual-core i3 would be affected.
I had to run the openssl speed test to get the CPU to run at 3.4GHz, enabling much higher IPS throughput.
The best way to watch the CPU frequencies in Linux seem to be:
watch -n.1 'cat /proc/cpuinfo|grep MHz'

I am really surprised that snort using high CPU (70% of one core, throttled) isn't enough to trigger the CPU to run at a higher speed. I will do some research and more testing...

After the IPS tests, I turned on all of the following: Application Control (aka Network Visibility), PortScan and Flood protection, and ATP. No reduction in performance was noticed, nor did I see any of those processes (e.g. afcd) using any CPU in 'top'. I was somewhat surprised by that.

Barry

THis mirrors my findings...if http proxy kicks(which is high MT) then the cpu will scale properly and snort "wins".  Intel has gotten hyper aggressive with their power management.  This along with their cpu's being MT focused leads to this issue.  You can get around it by changing the power profile and Barry has indicated above...

Here' one article:
Errata Security: Multi-core scaling: it’s not multi-threaded

Hi Barry,
finally got away from the other afterhours activity to concentrate on this one.
CPU i3-4130 3.4ghz with HT
with snort running around 260Mb/sec
without snort around 500Mb/sec
Snort when running peaked at 85%cpu ans 1% memory.
I ran a second download from a website which did cause a higher throughput on iperf with snort running to around 300Mb/sec.

I found out that QOS does indeed work. Took me about 30 minutes to figure out why I could not get faster than 750Kb/sec. Disabled QOS on external external interface and bingo blinding speed.
I know that on the same switch the MAC can transfer around 800Mb/sec to the W8.1 PC.

Power went from 30w to 38w. Test times around 200 secs.
Ian

Another change that also does seem to work is:

echo -n 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

Hi, 
I tested that too, but for me, it still resulted in worse performance than with the SSL test running or the 'performance' governor, and the idle power draw is the same.

Barry

I'm running the UTM as a VM in ESXi 5.5 and dedicated 2vCPU's to it.  Each of my whitebox hosts are running i7-4770S.  

I only have a 30Mbit Internet connection, but I'm maxing it quite a bit and CPU has never been an issue.  CPU average is about 20% for an entire month.