Thank you Keith for your hard work and nice explanations. I hope your upcoming weekend is uninterrupted.
Cheers

I understand MCM1 WUs are no longer being sent out in order to remove pressure from the server but I keep (slowly) getting new MCM1 files to my main machine. I am guessing these are the ones rejected or not finished by others but even then if you really need to shut off MCM1s then I recommend pausing the resends as well.

Cheers.

Despite MCM1 has started issuing work again, I'll answer this.


While disabling sending-out resends can initially look like a good idea, as long as disk-space isn't completely full continuing sending-out resends can actually be an advantage, atleast if project needs 2 (or more) results for validation-purposes. Let's take a quick look on wu-distribution, using completely arbritary size on files.

1: A new wu's 1 MB input-file is put into the servers download-directory.
2: Two tasks for this wu is generated in the database, ready to be sent-out.
3: Two different computers downloads these tasks, and both downloads the 1 MB input-file.
4: N seconds later one of the computers is finished and upload a 10 MB result-file, this is put into the servers upload-directory.
4a: At this point, total server-side disk-usage is 11 MB.
5: Where's multiple choises here, but let's say the 2nd. computer finishes and uploads a 10 MB result-file.
5a: At this point, total server-side disk-usage is 21 MB.
6: Both computers reports their finished tasks and this is saved in the database.
7: Normally within 10 seconds after the last task was reported, Transitioner triggers Validation, tasks validated & credited, triggers Assimilation, results assimilated, triggers File-deletion, all corresponding files for wu & results is deleted from upload & download-directory.
7a: At this point, disk-usage is again down to zero.
8: After a project-defined waiting (24 hours or something), the DB-purger archieves and removes all traces about the wu & results from the database.

As can be seen above, if have already got 1 result for a wu, this will use example 10 MB on disk. Until the 2nd. result is also returned and wu can be validated, the disk-usage will continue being 10 MB in upload-directory. For this reason keep re-sending any tasks will often be a good idea, since this is the only way to recover the already-used disk-usage. Especially if a task times-out by reaching the deadline a re-issue is a good idea, since in most instances there's a 10 MB result-file waiting for this 2nd. result.

Now, if none of the tasks is returned, you'll still use 1 MB in the download-directory, and this can block generating of other types of work if too many wu's is in this state. Still, atleast in this example where upload-size is >> download-size, not sending-out work for wu's never sent-out at all before is a good idea.

For re-issue on the other hand, in many instances this is the only way to decrease server-side disk-usage again.

I have never encountered so many suck in a DC project as are here now - DC work is voluntary and paid for by the cruncher and for your info I have been probably crunching longer than most persons here I started back in 1999 on the SETI Project that gives me 14 years real time crunching of which I have worked on and off and clocked up 32+ years crunching with WCG since they started and they have from day one always tried to get participants to crunch the projects they want - time to move back to F@H

Result Status: User Aborted