Michael J McCafferty wrote: [...]
In actual production use one would never want to go near 100% interrupt time. In production I notice things get a little shaky at 50% interrupt time (brief transients can get too be too much). My chief complaint is that OpenBSD doesn't use both cores for this work. I mean, I don't even think you can buy a single core CPU anymore... can you ? (rhetorical question).
Use GENERIC instead of GENERIC.MP ? [...]
In my current real ruleset and real traffic, PF uses about <10% interrupt time, and the network traffic uses 40% interrupt time (determined by turning PF off to see the delta in interrupt time). But, if I could use both cores (and assuming an unrealistic 100% linearity), I could handle twice the traffic. This is where I need to be for the next 12 months. Beyond that, who knows.
We have segmentet our network which means more physical firewalls but also much less traffic per firewall and less damage should a redundant firewall pair die on us (which never happend but still ...).
Your numbers are 75kpps at 100% (right?). In practice I'd not want to run at over 50% of maximum capacity on a regular basis to leave room for anomalies. So, we'd want to be at under 32.5kpps. In my network, my traffic is very close to even in pps inbound vs outbound. So, that's ~16kpps in each direction. I use 13kpps in each direction each afternoon now @ 40% interrupt time total. So, my "real" numbers confirm your test numbers. Nice test ! :o)
Remember that we flooded all 4 bridge devices during that test. Flooding only 2 bridges yielded much better performance.
I have asked this question before: Will FreeBSD's ability to use both cores but older PF code make it's overall capacity in pps higher than OpenBSD with the newer improvements in PF and on the same multi-core hardware ? My hypothesis is YES since the majority of the interrupt time is not PF but is the network traffic. Need to test to get that answer. Thanks for posting your results !
It was my plan to test FreeBSD 7-RC1 but I ran out of time :(
Mike
[...]
-- Med venlig hilsen / Best Regards Henrik Johansen [EMAIL PROTECTED]