What you are experiencing is the UD Agent checkpointing a large file. Help Defeat Cancer can write some very large files (130MB or more). This causes a problem with UD Agents because when we checkpoint with UD, it compresses and stream encrypts the files to be checkpointed to backup files. This causes the I/O to take a relatively long time to complete (it's about 7-9 times slower than straight I/O). This is the I/O lag you are seeing.

Knowing this, we "throttle" the I/O for the program. Instead of writing a lot of data at once, we write out the data in chunks and pause slightly between the chunks so that our application doesn't impact the user's machine with I/O. This also saves some memory. This makes a much larger difference in UD where all I/O is stream encrypted. While this I/O "throttle" (not to be confused in any way with the CPU throttle) certainly helps, there is nothing we can do when we checkpoint and UD backs the files up. That code is out of our hands.

What happens under the covers is this:
* The science app writes out files as it progresses through the code. All I/O in UD is stream encrypted and thus slow. The I/O read/written by the science app is "throttled" as described above.
* We reach a point in the code where we can checkpoint. For UD, we call their checkpoint routine. All it basically does is look at the list of files that are considered checkpoint files and backs them up. This is where you are seeing the I/O hit. For BOINC, we call our own checkpoint class which backs up the files for us. Under BOINC this is very quick compared to UD, so it should barely be noticable. After the files are copied and the state updated, we tell BOINC we've completed our checkpoint.

This answer is much longer than I anticpiated it would be, so I hope it's clear.

i hope it's not one of those 'anti-virus' problems like with mcafee.

that virus scanner used to conflict with WCG a lot. i only found out about it by opening task manager and figuring out what else was taking CPU power.

Retsof, when desperate one looks at anything.....the timestamp point very very valid, to the extend that i disabled the WinXp clock sync function as it corrupted twice a WU in BOINC (latest official 5.4.9).

In UD that behaviour might be a bit more friendly...restart the WU, but could the clock synching be a factor?

The 33.33% is an observed one. Similar to HPF2, these present batches of FAAH are split in very large segments. Put a post out, seeing types existing of 6, 3, 2 and one resetting for even 90 to zero, suggesting a no segment at all ????? What ever is said about the frequent checkpointing, i wait with closing until it passes these percent hurdles just to be totally save......nothing so annoying than loosing 4 / 5 or more hours of crunch.

The Porting to a different computer...zip....copy....move pc ..unzip been successfully deployed by DPC members a few times without hearing of troubles.....lucked out.

Swapfile on a 2nd drive helped total system performance quite a bit. Also it sits in its private partion there of 2gb, so never has issues of fragmentation when on autosizing. PageDefrag it once a while, but usually it says its already in 1 space.

Same here. It's impossible to work on my computer with something like that. I'm ignoring this project.

ALL: Please read my earlier post on 25 July. It appears no one has read it. The problem with the I/O hit should only be happening with the UD Agent, as I described in my earlier post. If the I/O is affecting you, I would recommend running the BOINC client (at least for the HDC project), which doesn't have the I/O overhead that UD does.