Network performance update

June 11th, 2007 by Chris Buechler

I deleted the last two posts on network performance because they contained some incorrect and misleading information, because of some problems we discovered.

We’ve eliminated the performance issues discovered in 1.2b1 in current snapshots starting several days ago. We kept some kernel patches that show measurable performance gains, and removed others that showed no gains. We’re now about 15% faster in 1.2 than in 1.0, and about 10% faster than m0n0wall 1.3 (pf patches now make it faster than ipfilter in m0n0wall).

m0n0wall 1.2 still makes us look silly (1.5 times as fast), but that’s to be expected with its FreeBSD 4.x base. FreeBSD 6.2 has closed that gap considerably from the disaster that was FreeBSD 5.x, and FreeBSD 7 looks to draw nearer to 4.x performance. Note that I’m strictly talking about single processor machines, SMP systems are a much different story, but I won’t comment on those until I get a chance to do some testing.

To explain what I mean by X% faster, or Y times as fast, what we’re measuring is simply maximum achievable throughput on a given piece of hardware. For the tests mentioned above, I used 200-350 MHz pfSense machines because I don’t have the resources to max out anything faster than that. The resultant speed is measured using a single TCP stream with 1500 byte packets.

Chances are none of the mentioned improvements will have any noticeable effect on your systems, unless your hardware is undersized. For example, let’s say you’re running a Pentium II 266 MHz PC system on a 10 Mb Internet connection. If that system could previously push around 50 Mbps, now you’ll be able to push more like 55-60 Mbps. But it doesn’t matter since you only need 10 Mbps throughput for your Internet connection.

As a second example, say you have a Pentium III 800 MHz system with 100 Mb NIC’s. It could push 100 Mb wire speed already, so the only benefit from this is very slightly reduced CPU usage while pushing 100 Mb wire speed.

I’ll be posting numbers on a variety of tests on a number of different hardware platforms in the near future.

7 Responses to “Network performance update”

  1. Toro Says:

    Offtopic: 1.2-BETA-1 has a bug, I can´t update my DynDNS account properly. Also an option would be nice, to manage and use additional DynDNS accounts in pfSense.

    Another thing is that the (Web-) Interface is accesseble from WAN in the default configuration – on a firewall this shoudn´t be the case.

    Another question, is there a clamav plugin available for the proxy on pfSense?

  2. Chris Buechler Says:

    This is not a place for support questions, take them to the list or forum.

    The webGUI is absolutely NOT accessible from the WAN side by default and never has been. If yours is, you entered a rule to make it so.

  3. Apu Says:

    have been trying the 1.2 beta and I like it so far. very stable and the penalty IP works so well ! expecting to see a better squid package for this. Good work, chris, scott and others !

  4. Joe Says:

    When is 1.2 final release coming?

  5. Chris Buechler Says:

    When it’s done. Might be a long time, might not be.

  6. redbeard Says:

    I think you had mentioned substantial differences between the WRAP boards and the Soekris boards in the deleted posts. Do those differences still apply or did you find they were incorrect also?

    Also, have you been able to test the net5501 boards yet? If so, how did they perform?

    Thanks.

  7. Chris Buechler Says:

    That is still correct, the WRAP boards are measurably faster than 4801′s as they’ve always been. The difference is somewhere between 10-20%.

    We don’t have any 5501′s. Though PC Engines has donated several WRAP boards, we’ve never gotten a single contribution from Soekris. The Soekris hardware we have available was purchased by other companies. If we get a hold of a 5501 from Soekris or elsewhere I’ll post a review of it here.

Please don’t post technical questions or off-topic comments. It is far more likely that your questions and concerns will be addressed effectively through one of our support channels.

Leave a Reply