2

this is my first question and I hope I do everything correct. Thanks for setting up serverfault - such a site was missing in the internet for a long time now.

In the next few weeks I will get my VDSL 25 connection (at best it's 25 Mbit Download and 5 Mbit Upload). So now I was thinking about setting up my own router for VDSL because i dont want to use the Speedport router I'm getting with VDSL 25.

I'm really into OpenBSD and I found a nice guide about Using OpenBSD with VDSL. In a german article about setting up the FreeBSD based pfSense for VDSL i read that the computer should have at least 1 GHz with 1024 MB RAM.

My machine will be a 800 MHz Pentium 3 with 512 MB RAM but I consider to buy a 30$ Intel Gigbit NIC with TCO (TCP Checksum Offloading). A co-worker suggested this to me because he ment that would heavily decrease the CPU load and my 800 MHz P3 could be more than enough then.

So do you have some experience about the "hardware requirements" for VDSL and if a NIC with TCO could help there?

Thanks in advance for all your answers!

2 Answers 2

3

The recommended specs for pfSense are way, way, way overkill. Your machine should handle that load quite handily. For a point of reference, I used a Soekris Net5501 in production for a little while and it fell over at about 45Mbps. It was spec'd out with a 500MHz Geode, 256MB RAM, and some of the worst NICs ever created (Via Rhinestone - vr driver).

In my experience, the most common big performance obstacle on a router like this is the context switching required by rapid-firing interrupts. Shitty NICs like the Rhinestones fire an interrupt for every single packet they receive. This becomes a major problem because each packet has to be processed, but oops! In the middle of processing it, another one comes in. So you pull that out, get interrupted, etc etc. Context switching is an expensive operation and quickly overwhelms a slow CPU.

Good NICs (Intel and Broadcom are both solid) have interrupt mitigation capabilities, which means they only bug the CPU when they have a certain number of packets accumulated, or when a timer hits 0. Operating in chunks like this is far, far more efficient than constant context switching.

Some operating systems attempt to mimic interrupt mitigation with polling - the kernel ignores the NIC's interrupts and just checks its buffers every so often. This can lead to much higher throughput and lower CPU utilization, but at the expense of latency, possibly losing packets if the NIC's buffers fill up, etc. OpenBSD has not implemented polling. In my experience interrupt mitigation is superior to polling, and the price of decent NICs is low enough that there's not much excuse.

Memory really should not be an issue. OpenBSD and PF are very efficient. On a pretty slow day (today), one of my production routers has about 17.5k states in memory. It's also running spamd, logging all blocked packets, and doing a tcpdump on its most active interface. Using 191MB of RAM.

So all that to say your specs are more than enough, TCO or no.

2
  • thank you for your answer and experiences! I thought it would probably require a "good" cpu because of the VLAN tagging which VDSL requires. OpenBSD and PF are really pretty efficient - so thanks to get me an inside view on how much ressources it takes in real life production use. May 31, 2009 at 19:53
  • VLAN tagging requires minimal resources - it already has to build/parse the layer 2 packet, this is just another field that has to be filled in or looked at. OpenBSD makes VLAN handling super-simple from a configuration standpoint too, so it shouldn't be a problem to get going.
    – sh-beta
    May 31, 2009 at 20:32
-1

OpenBSD doesn't support TCO so you won't get any benefit from such card.

3
  • Actually it does on several different drivers. Example is em(4) - the main Intel driver: openbsd.org/cgi-bin/…
    – sh-beta
    May 31, 2009 at 21:26
  • Hmm, strange onlamp.com/pub/a/bsd/2007/11/01/whats-new-in-bsd-42.html in this interview they say it won't be supported.
    – cstamas
    May 31, 2009 at 22:47
  • Those comments refer to engines that take a large part of the TCP stack into the hardware realm as opposed to the TCP Checksum Offloading. The latter is just error-checking math that can be safely offloaded to hardware without bypassing any of OpenBSD's specialized network stack. Full TCP offload or segmentation engines try to handle a large part of TCP processing in hardware. Nominally good for performance, but trusting hardware black-magic is not something the OpenBSD crowd is very in favor of.
    – sh-beta
    May 31, 2009 at 23:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .