Whatever the weirdness, yesterday there were some Nautilus patches and today there was a small gloobus patch that also hooks into Nautilus Elementary and libtracker which also works to make Linux faster. Today I was doing quite a bit on the machine and kept 2 DDDT2 and 2 CEP2 concurrently running and several finished, one with 9:08 hours reported CPU time and "just" 27 minutes to add for system/user elapsed or 3 minutes per hour or 95% efficiency. That promises something for the coming nights/days when the system is kept full "crunch only" state. And the bonus, credit very close or better than claim.

E200265_ 510_ A.23.C17H8N4S2.128.4.set1d06_ 0-- 1292373 Valid 8/20/10 13:13:56 8/22/10 16:14:31 9.08 163.6 / 156.7
E200265_ 304_ A.23.C17H8N4OS.141.set1d06_ 0-- 1292373 Pending Validation 8/20/10 13:22:27 8/22/10 14:05:37 7.03 126.6 / 0.0
E200265_ 346_ A.23.C17H8N4OS.30.set1d06_ 0-- 1292373 Pending Validation 8/20/10 11:54:48 8/22/10 05:48:25 7.97 143.7 / 0.0
E200265_ 385_ A.23.C17H8N4OS.55.4.set1d06_ 0-- 1292373 Pending Validation 8/20/10 10:37:23 8/22/10 01:40:34 6.76 121.8 / 0.0
E200264_ 727_ A.23.C17H7N3OS2.136.1.set1d06_ 1-- 1292373 Pending Validation 8/20/10 05:04:52 8/21/10 21:14:42 6.55 118.1 / 0.0
E200263_ 879_ A.23.C17H12N2OS2Si.28.0.set1d06_ 0-- 1292373 Valid 8/20/10 04:51:29 8/21/10 13:07:11 6.40 115.4 / 118.9

Going for goldness... still needing 5 days per noon stats.

hi Ummon,

Of course your client is set to run 100% and nothing of background indexing is running secretly and all these other bits such as running off a HD with the fastest native file system (ext3 / ext4). Have you looked for those odd time losses as some have reported round about the checkpoints?

Efficiency varies here for unknown reason, some 95%, some 92%, maybe multiple concurrent causing bottlenecking. I continue to make sure to run mix and suspend jobs on the quad whenever I see more than 2 running and let anything else skip ahead, HCMD2/HFCC/C4CW now too. Can only imagine the resource battle that occurs when a quad with hyperthreading goes off to do 8 simultaneous. Seeing any high page faulting numbers and or delta there-off?

Ummon, plz look in your BOINC manager and check if "Run Always" is selected in the Activity menu and or the Local Preferences the CPU Time % is set to 100. Probably is, but just wantto rule this pissue out where BOINC default is to process only at 60% load.

(soft) page faulting is when the CPU has to go out and fetch more data not already in memory and explained here: http://en.wikipedia.org/wiki/Page_fault

Some have more than others. When it runs in the tens or hundreds of thousands per second it affects throughput considerably.

OK, had to open up the books myself, walking the walk to go with talking the talk:

In a terminal window enter top, that opens an interactive process window. Hit Capital A i.e. shift A, which subdivides the view to show many fields. The columns to look for are nFLT and nDRT

To watch a specific process easier first do top and choose a CEP2 process, then hit q to quite top then enter

top -p PID

where PID is the process number (don't know yet how to isolate a specific process from within a running top).

then, shift A to see all fields

Also 'u' can be used to see only the boinc owned processes and then do shift A to see the detail. Easier on the eye.

Source of my newly learned:

http://www.linuxforums.org/articles/using-top-more-efficiently_89.html

I'm just seeing 1 or 2 nFLT on the CEP2 processes and nDRT is 0, so not an issue here. Above 10 seems to be bad.

What's frustrating with the hundreds of distros and versions is that something may work in 1 and not the other. Found something that peaked my interest on /dev/shm and some commands to mount something to speed things up and essentially requiring more book reading... I'm so addicted to the GUI way of things and hitting help to find an answer.

Closer examination, had 0 or 1 on CEP2 and 2 on C4CW for nFLT. The nDRT has continued to be zero for the whole time that TOP was up (long refresh time set to minimize load). 6 is 3x more than 2 and 6x more than 1, so not sure how many cycles go to those events. I suppose you might want to closely watch the checkpoint / CPU correlation. See posts JmBoullier as to what he did to determine 6-7 minutes going nowhere on his system at some checkpoints, when Linux loads up a new job. Certainly anything that uses OpenGL extensively is OFF and of course, if you have the graphics on screen that can seriously eat time.

Sorry to not be much of help getting closer to capping that black hole.