CPU Maxes 100% When Running Torrents
-
Is there a good reason you are running a snapshot build from last October rather than pfSense 1.2.3 RELEASE? suggest you upgrade. (I don't know that the upgrade will fix the problem but its possible this problem was noticed and fixed before the release.)
-
@LuanGilbies:
I am having the same problems here too would be great to hear out some fixing….
What version of pfSense are you running?
-
Hi
Thanks for your reply, I'm running….1.2.3-RC3
built on Mon Oct 5 22:57:46 UTC 2009
FreeBSD 7.2-RELEASE-p4 i386I did try the snapshot, but I still had problems with that also...
I have been trying difgfrent hardware configs with diffrent NIC cards, but its no good. -
Sorry Dave, I asked LuanGilbies about the version in response to a statement they were having the same problem. It looks as if that statement has been deleted. The information you already posted told me which build
you were running.I did try the snapshot, but I still had problems with that also…
Which snapshot did you try? I suggested you try the release build. What problems did you have with the snapshot you tried?
I have been trying difgfrent hardware configs with diffrent NIC cards, but its no good.
What types of NICs did you try? What types do you have available?
For comparison, my pfSense runs on a 800MHz VIA C3 and it has no trouble downloading a torrent at over 400kB/sec (over 3200kb/s). I have a 12Mbps USB NIC for my WAN and a VIA 10/100 NIC for LAN.
There was a problem reported with fxp NICs: the driver would erroneously think that some fxps had checksum offload capability. Suggest you try turning off checksum offload (from web GUI, System -> Advanced, tick the box near the end Disable Hardware Checksum Offloading).
-
Hi
I installed the latest build version from the upgrade page within the firewall.
I have an Intell 1Gbs Pro NIC (em0) and an unknown 100Mbs NIC (fxp0). I origionally had the problem with just only one 1Gbs card installed, With all interfaces on VLAN'S
On another note, the CPU is allways stone cold, I would expect that a CUP running at 100% to be tostie warm??? (2.8Ghz)
I tried the disable hardware checksum last night, but the problem is still there.
I have taken a screen shot of the tasks this morning….
I am a littloe lost on things to try, is there any way I can debug the problem??Kind Regards
Dave -
Your screen shot shows 25% idle time. The CPU is not fully used. This is not evidence of your reported problem.
-
Looks familiar from this post
http://forum.pfsense.org/index.php/topic,20360.0.html
Try enabling or disabling device polling from your current setting.
In the webGUI System/Advanced in the Miscellaneous section
And some more reading: http://forum.pfsense.org/index.php?topic=16236.0
-
Hi
Thanks for the links, I have tried the links, but no-one seems to have an answer for this problem.
I have disabled Device Pooling and also disabled Hardware Checksum Offloading, but it hasnt made a diffrence.
I have attached another screen shot with no idle cpu, which takes a very long time to load!
Is this a BSD Version 7 Problem???
Can anybody recomend a good Gbs NIC card, if the problem is related to intell cards???Kind Regards
Dave
-
I've been running em cards for over a couple of years now with zero issues. I'm wondering if maybe this has something to do with vlans.
-
This is definitely a challenging problem.
I looked at your second ps output and saw irq18: fxp0 is the biggest consumer of CPU time. The startup output shows irq18 is shared by fxp0 and atapci0. This means the disk driver is called every time the fxp requests an interrupt. This is suboptimal. There may be a BIOS setting to set the disk controller into LEGACY mode rather than NATIVE mode. In legacy mode the disk will use irq14 and irq15. The shell command vmstat -i can be used to check interrupt line assignment. See if you can get the disk to use irq14 and irq15 and see if that makes a difference to who is using the most CPU.
The next biggest CPU consumer is em0 taskq. The startup output shows irq16 is shared by vgapci0 and em0. Again, this could mean (I don't know if the vgapci driver uses interrupts) the vga driver is called for every em0 interrupt. It could be worth trying to eliminate that sharing by (possibly) moving the Intel GigE NIC to another slot so that em0 get assigned a different irq (not 16 and not 18). It appars the video card is a AGP card so there is probably no scope for moving that to a different slot to eliminate interrupt sharing.
Since there are no USB devices listed in the startup I presume the BIOS has been configured to disable USB devices. This is a good idea (if you aren't using USB devices) since it helps reduce interrupt sharing.
I don't know if the motherboard includes any PCI Express slots. If it does, it could be worth trying an Intel PCI Express GigE NIC because the OS may be able to initialise it to use MSI (Message Signalled Interrupts) which would give it a dedicated interrupt line. However, the system chipset might be too old to support MSI correctly.
I took another look at the information you provided and it appears that though the FreeBSD startup says the disk controller atapci0 uses irq18 the interrupt listing says its using irq14 and irq15. Perhaps the system is confused in which case it could be worth seeing if it has the most current BIOS and updating if there is a more recent BIOS available.
