I installed BOINC back in March and until recently two project executables have been running at about 49% CPU utilisation each (I have a single HTT CPU) with boinc.exe using very little of the CPU.

However, I have noticed that now boinc.exe runs at between 5 to 25% all the time.

If I suspend BOINC processing on the machine (i.e. no work units are being processed), boinc.exe still uses between 5 to 25% all the time.

Using Task Manager, shows that my computer is spending around 5 to 20% of the time in the kernel. If I stop the BOINC service, this drops to negligible amounts.

The only things that I have changed on my computer recently is replace Norton with McAfee (but disabling it doesn't make a difference to boinc.exe's CPU usage) and install a graphics card.

What other things could account for such high boinc.exe utilisation?

---

Just realised I forgot to say I am running Windows XP (with all the latest patches).

---

I have had a bit more of a look at this. In a recent 60 seconds, boinc.exe input and output approximately 7,598,000 "other" bytes according to Windows Task Manager. I am not quite sure what "I/O Other" is - it is separate from I/O Read and Write.

It also had 112,000 page faults in a minute.

Any suggestions anyone has as to what my problem might be are welcome.

Regards,

Peter

---

It also had 112,000 page faults in a minute.

It sounds like virtual memory thrashing - is it possible that one of the projects you're attached to is now using more RAM than before? Or some of your RAM has gone bad and is no longer visible? Or something else is running that takes quite a bit of memory? Or... your new graphics card uses "Hypermemory" (system RAM)? This is what I would expect to see in a "very low RAM" situation. If you have GBs of free RAM, there's some other issue...

---

I've got over 1/2 GB spare RAM. The project processes aren't using more RAM than usual and they don't have the I/O rates that I am seeing in the boinc.exe process. I'm not having problems with anything else so I doubt its a bad RAM problem.

The graphics card doesn't use system RAM (that's one of the reason's I got a new card - I use to just use the onboard graphics "card").

I think the problem is something else. Nevertheless, thanks for your suggestions.

---

BOINC, particularly with SETI@Home has an issue with page faults. Rom made a change (I think it was Rom) to mitigate this. However, I am not at all sure which application/version contains the change.

As I recall the discussion, the page faults were benign in impact. In other words, reducing the page faults did not increase the speed of processing.

I cannot find the thread as search for "page fault" returns lots of pages discussing green stars for whatever reason. The discussion of this issue was at least a month ago ...

---

It also had 112,000 page faults in a minute.

Any suggestions anyone has as to what my problem might be are welcome.

Regards,

Peter

One of the enhancements in the seti at home enhanced version is a dramatic reduction in page faults. Althought the page faults are not really a bad thing in themselves enough of them can result in fragmented memory allocation. This can cause the same kinds of slowdowns that a fragmented hard drive does plus can make the system unstable in time, or at least it seems that way to me. This seems to be a general problem with windows and it has caused me to adopt a policy of restarting my computers rather than logging off when I am through with one.

---

BOINC WIKI

BOINCing since 2002/12/8

I have had this problem too with 5.2.13 (Win32). I had boinc.exe using up to 2 hours of cpu time a day, with the same page fault and mystery I/O signs, and over 1GB of nominal free RAM, on a stable system. It was running 2 processes, 1 per CPU.

The only workaround seems to be to limit boinc to one process(or). If you only have one processor, limiting it to zero should do the trick too...

You can always put the other processor(s) to work on other projects. You don't want them sitting back and relaxing and getting ideas.

I started a post on the Manager thread about this problem, but the question belongs here. Original thread at

http://boinc.berkeley.edu/dev/forum_thread.php?id=630
_

---