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]
