Calling Techs: Blue murder time!

E000021_ 495A_ 00031w013_ 1-- Valid 12/12/08 08:23:27 12/13/08 13:28:37 7.62 38.9 / 38.9 < Yeah right if you're gullible.
E000021_ 495A_ 00031w013_ 0-- Valid 12/12/08 08:23:21 12/13/08 09:01:10 13.96 143.2 / 38.9 < Moi

How the credit logic for this project works is a complete riddle. Until resolved not going to waste further electricity at just running at 27% throughput.

This is not the first credit joke seen on CEP and I do know for sure that the parallel jobs running HCC get 100% on the same CPU.

good night and good luck.

[Edit: See Current CEP bugs / problems ]

It might be interesting to compare CEP throughput under 64-bit Windows or Linux vs that under the 32-bit versions. Kernel activity, including the disc cache, should run faster in 64-bit, while the 32-bit user code should run at the same speed. A big difference in throughput would suggest that the page-faulting is slowing down CEP.
FWIW, I recently performed this test for FAAH, HCC and HPF2 by running the same single WU from each of these projects under Windows XP-32 and XP-64. I found XP-64 to be about 1% faster in each case.

So the page faults aren't happening anywhere near Discworld. Thanks, Didactylos. I wasn't sure about the nature of the page faults, but the fact remains that the high pf rate (delta) means that the o/s is getting a hammering.I think that CHARMM is not only allocating the memory, but then releasing some of it, over and over. If you observe the startup of an FAAH WU, using Task Manager, you will see that it too generates many page faults as it grows its VM size to about the same 300MB, but then the page fault rate declines and the VM size stays constant. FAAH Autodock may be using user-mode heap management functions instead of the o/s.
CHARMM's approach, which would be leaving as much system memory to other processes as possible, would be the correct one in a multitasking environment where memory was scarce and expensive, provided that it was releasing a big proportion of the memory that it had grabbed. However, the VM size is remaining fairly constant, so recycling memory internally might be a better scheme.

[Added] Didactylos' next post sounds reasonable to me. I hope that we haven't lost tekennelly, the originator of the thread, with all of this tech talk, and that we've all gained some insights into what is happening.

As I suggest in thread 2 WUs stopped early ..., I am wondering whether the high pf rate is responsible for the various errors that people are experiencing with CEP:
Error after 9 hours of crunching, big difference in run times/credit claims, What are these errors about?.
If you get an error or early termination of a CEP WU, I suggest you note:
- Your operating system and its version
- Whether it was on a single-CPU machine or a multi.
- If a multi, would more than 1 CEP WU have been running at the time of the error?
[Edit: Later observation by me suggests that early termination of CEP WUs does not seem to be related to running multiple CEPs simultaneously.
See Current CEP bugs / problems ]

I suspect that some of what may be happening with the severe underclaimers is, that while running CEP clogging things up with the page faults, their benchmarks have run, producing lower than usual numbers. I've noticed a big difference before in the benchmark here while running HPF2, which seems to have very inefficient coding as well. Running HCC gives me great benchmarks though, if it has to pause and restart automatically.