I hope you have forgotten some smiley, otherwise I would have to call Tedi...

That's precisely because I know how much CEP is "page-faulting" in Windows that I had my first good surprise.
And the second surprise is related to your many posts giving high kernel times (which seem normal with so much page faulting).

I should add that I was surprised by the 27 % system with four HCCs. I don't remember having noticed such a high figure in the past. But honestly I don't start top in Linux as often as I do with TM in Windows. And perhaps my recent upgrade of Ubuntu from 804 to 810 has changed something in this area?

Cheers. Jean.

I've just started on two CEP units on my quad core machine running Kbuntu 8.something (not sure what the number is, the previous one to the current one - whatever it is). The other two cores are running DDT units ATM.

As you can probably guess I'm not a hardcore linux geek, and hadn't heard of the top command until now - I usually use the graphical process monitor KSysGuard if I want to see what's running. I use Linux cause it works and doesn't hog all my resources, crash, get polluted with nasties, etc. I've had my fill of fixing MS machines that have gone wonky.

Anyways, I tried out top, added the page fault view option and I can confirm Jeans view of low page faults. Now this may not apply in all circumstances, perhaps I was lucky with these two units but the fault count seems pretty reasonable. I've copied the figures below and included my highest page faulting process for comparison.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM   TIME P nFLT COMMAND
 6433 boinc     39  19  244m  25m 2152 R   99  0.8  61:45 3    1 wcgrid_cep1_6.2
 6436 boinc     39  19  277m  87m  976 R  100  2.9  61:36 1    1 wcg_dddt_autodo
 7113 boinc     39  19  277m 107m 1040 R   99  3.6  50:46 0    1 wcg_dddt_autodo
 7158 boinc     39  19  257m  35m 2172 R  100  1.2  34:05 2    1 wcgrid_cep1_6.2
 7153 boinc     39  19  277m 106m 1032 S    0  3.5   7:45 2    1 wcg_dddt_autodo
 5573 root      20   0  409m  49m  10m S    1  1.6   0:48 3  171 Xorg

The "P" column is the core it is running on and nFLT seems to suggest a single page fault has happened on BOINC work in the past hour whilst running at 100% load for all that time. Doesn't seem too bad to me.

If it's of interest here's my boinc setup:

Starting BOINC client version 5.10.45 for x86_64-pc-linux-gnu
Libraries: libcurl/7.18.0 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.1
Processor: 4 GenuineIntel Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz [Family 6 Model 15 Stepping 11]
Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
 pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc 
 arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
OS: Linux: 2.6.24-23-generic
Memory: 2.95 GB physical, 8.65 GB virtual

Mabye CEP is just more sensitive to the config of the rig it's running on than most projects?

Thanks for reacting! That's why I asked for a trained Linux user's supervision...
And which tool should I use to see soft page faults?
Although it seems that it is HCC which is affected by this problem more than CEP under Linux. Unless I have also taken the wrong figures for system % in top's summary?

Cheers. Jean.

I was looking in the wrong place. I had this discussion on IRC. Logs are my friend.

Anyway, the command is sar. It is dependant on the sysstat service. So, you need something like:

/etc/init.d/sysstat start
(wait for it to collect data)
sar -B 3 4

I've upgraded some machines to Lenny and suprise:
It contains boinc_client version 6.2.14!!
Still not 6.2.15 thow, but much better than the 5.4.11 from Etch.