How to calculate calculate how many PPS per NIC
-
Greetings all,
I was looking thru the documentation and could not find a direct answer. Is there any sort of matrix that defines how many packets-per-second a particular NIC can handle for pfSense? I have looked at the sizing guide, and it only references thruput (not packets-per-second)
We have a pair of QuadCore Intel 2.6GHz servers with Intel GigE NICs (Intel PRO /1000 cards) and 4GB RAM that sit in front of our web servers. I was wondering how many packets-per-second the pfSense firewalls can handle based upon an average 2KB in and 15KB out. The WAN NIC is hardcoded for 100Mb right now.
Not looking for an exact number, but something our management team can use to make some rough estimations on if/when we need additional firewall horsepower.
Thanks!
-
The limiting factor for PPS isn't typically the NIC, but rather the CPU. The NIC mostly just receives the data, places it in a buffer, and tells the CPU to deal with it. The CPU has the burden of figuring out which protocol and port the packet is for, if any firewall rules apply, traffic shaping, etc. The driver for the NIC will play a part in the CPU usage as well, but it can be balanced with either a NIC with a better driver or with a more powerful CPU. Assuming an infinitely powerful CPU, a 1Gbps NIC could reasonably handle saturating the line with the smallest packets possible. Note that the actual bandwidth for saturating a line varies with PPS since there are inter-packet delays and protocol size overheads that are part of the various protocol specifications.
The amount of CPU required to handle a certain PPS of traffic will vary with the amount of analysis pfSense is doing. If you have firewall rules setup, use NAT, or run other services like snort, you will need more CPU than a pfSense machine just doing pure routing.
The short answer: no, there isn't a matrix or even a formula for estimates since it varies pretty widely with configuration. If you have a pfSense machine and the time to experiment with different PPS/packet size/configuration/NIC combinations, I'm sure it would be interesting to others on this forum.
-
A useful guide would be to look at the CPU utilisation, conveniently graphed for you in the RRD graphs that can be displayed by the web GUI. Depending on how important it is to not run into overload (and your budget) you might decide to add some additional compute power to your firewall array when the utilisation peaks at over 50%, 70%. Other RDD graphs will provide information of how much data is going through your firewalls.
Standard ethernet frame size is about 1518 bytes so its quite likely your typical frame sizes are rather lower than 2K in and 15k out. (The firewall/router CPU has to deal with "frames" not "transactions". A "transaction" might involve the display of a web page which may need to be fragmented into a number of smaller sized "frames" for transmission to another computer.)
-
Thanks for the replies. Unfortunately, we consistently run 0% CPU and 1% RAM utilization so it is difficult to forecast if/when we will hit 50% utilization. I have read other threads on this forum that seem to indicate PPS is more important than thruput. In other words, you can run out of PPS well before you run out of CPU. However, I guess this must only apply in certain cases in which the packets are in the 64-128k range (must smaller than the standard ethernet frame size).
I routinely check the RRD graphs for CPU and bandwidth utilization to keep an eye on overall system performance. So far, everything looks very good with no CPU spikes and traffic running nicely.
Thanks for the hint about CPU vs PPS. If we start getting above 50-75% CPU, I can deploy a second set of firewalls, or get faster CPUs…
-
You can only run out of PPS before CPU when you hit that constraints of minimum frame sizes and required delays in the protocols. In that case, you aren't really running out of PPS, but rather, you are running out of bandwidth and time due to overheads. The fix would be the same as running out of bandwidth due to large packets: add another NIC.
-
Interesting, so just adding another NIC and binding them together would allow more traffic? This assumes we are not out of CPU, right?
Thanks…
-
Assuming you can do link bonding or BGP and don't hit a bug in pfSense, yes.
-
Thanks!