I may have jumped the gun a little here. Of course the lack of proper and valuable information about BG's OS does not help. Not even their monitor provides the really valuable data one needs to properly evaluate a system's performance.
Depending on how they implement the Windows paging algorithm this may not be as bad as it seems.
I claimed that the system was paging heavily where in fact I cannot monitor paging activity as such, I can only see the page fault rate.
They may use an algorithm that flags pages to be paged out at the next cycle should a shortage of real storage develop. The real storage manager (RSM) then only turns on a flag indicating that this page should be paged out. This marks the page as invalid. However the page is not actually paged out and moved to disk. If I remember correctly the whole thing was called 'preemptive paging' in the mainframe world from which I retired many years ago.
When the processor needs to access the page the RSM only has to turn off the flag rather than paging it in from disk. This takes very little cpu time indeed.
It is possible that this happens because BOINC runs at a low priority (actually the lowest priority) and pages of low priority tasks become the first candidates for paging out.
One mystery remains i.e. why this BOINC task and not the others. Today I am running two new tasks and there is virtually no page faulting although the other memory indicators are largely the same as yesterday.
By the way today's processes are HCC (help conquer cancer) and yesterday's process in question was HPF2 (Human protein folding 2).
Believe me when I say that I understand and share your feelings of frustration and exasperation with the Windows OS. I have 2 GB of real storage and run with 2 users on my system. When I logoff the other user the whole system freezes for up to 20 seconds. Compare that to a mainframe system with lower clock speed and less real storage (1GB) supporting up to 5000 users with sub-second response time no matter how many users were logging off or on. It is beyond my comprehension that the system would slow down at all just to logoff a user.
In any event I can probably proof if my assumptions are right by increasing the priority of the next HPF2 task that seems to have a lot of page faults. I'll update this post should I be able to do that.

jsobry, you aren't jumping the gun. On the contrary, you are late to the party :-)

The whole paging issue was examined in great detail. For most people, soft faults are now reduced to a reasonable amount. However, if you have insufficient L2 cache, you may see more page faults than most people.

These are soft faults, not hard faults. The disk is not accessed.

Actually, you don't give Bill Gates enough credit. The way the Windows memory manager works is well documented. It is instrumented, too - you can track soft and hard page faults for a process using Performance Monitor.

Thank you for the updates good people. I'm curious to know what you, Sekerob, mean by BG's overarching engine "standards".
Also you do seem to imply that this is somehow the application's fault. Do we think the page faulting is caused because we do not touch certain code pages often enough?

Hi jsobry,

I had/have the same issue (if you wanna call it that way). Usually that happens when I used some specific Microsoft program (sorry don't' wanna point the finger). But this is OK, since you still crunch - especially when you finished with your work and close the other application it should return to normal (and even if not, you still support the good thing).

cheers.