Looks like I have a hardware load problem.



  • I have just changed from Cable (10000Mbps)  to ADSL2. I am getting a sync speed of 19500. When I run a speedtest I get 6.85Mbps with the pfsnese firewall in the mix. If I remove pfsnes and instead use a dd-wrt router (wrt54g) to handle the PPPoE link I get speed results of 17Mbps. A fair amount above 6.85Mpbs. I have eliminated everything else in the system to make sure it was pfsense.

    Checking the RRDGraph in the system I see a spike of 70-80% CPU each time the speedtest is run. Idle is 2-5% normally.

    pfsense system is a Thinkpad a22e laptop with a Pentium Mobile or Celeron Mobile 800/850Mhz CPU. pfSense is 1.2.2 installed to a HD. 256Meg ram.

    Traffic shaper is currently turned off.

    Is my speed limit simply not enough resources in the system ? I find it hard to belive the dd-wrt router with a 216Mhz CPU and 32Meg ram can out perform it.



  • @covert:

    Is my speed limit simply not enough resources in the system ? I find it hard to belive the dd-wrt router with a 216Mhz CPU and 32Meg ram can out perform it.

    In some work loads a faster CPU may actually be a disadvantage.  Here's why. Interrupts are a high overhead activity: not only does the previous context have to be saved and restored but the cache can be trashed by high interrupt rates. You may have an application running. That application has high locality of memory reference so that most of its memory accesses are satisfied from the cache. An interrupt happens and for a while most of the memory references for the interrupt handler can't be satisfied from the cache but from much slower main memory. By the time the interrupt handler returns there may be very little of the application's memory in the cache so when the application runs again the cache gets refiled with application data and code.

    If there is a heavy network load and the CPU is fast enough that it generally processes only one frame per interrupt then the cache related overhead will be considerably higher than it would be on a CPU that was somewhat slower and consequently processed more frames per interrupt.

    Some NICs have a mechanism allowing the device driver to specify that interrupt requests should be delayed some short time to increase the likelihood that there will be multiple frames available for processing by the interrupt handler.

    You don't say what NIC is in your system so I can't comment on whether it has that interrupt delay capability.

    Some people have found that enabling polling (from the web GUI, System -> Advanced, check the box Use device polling in the Miscellaneous section) produces a considerable improvement in throughput. (This comes with a cost of a somewhat increased latency but the increase should generally be no more than about 1 mS and will often be much less).


Log in to reply