As a consequence, the project never completely downloads, so I am unable to participate in the project. I have detached from and attempted to re-attach to the project on several occasions, but the result is always the same and the files always stop downloading when they reach a certain size.

just a comment about these (lr5_E_yf_chbond_05_rlbd_1bq9_SAVE_ALL_OUT....) tasks. for me they go very very quick. had 99 decoys in 1hr and 17 mins on one task. think that is the fastest i have ever done 99 decoys. another one reached 99 in 2hrs plus. still very fast.

just a comment about these (lr5_E_yf_chbond_05_rlbd_1bq9_SAVE_ALL_OUT....) tasks. for me they go very very quick. had 99 decoys in 1hr and 17 mins on one task. think that is the fastest i have ever done 99 decoys. another one reached 99 in 2hrs plus. still very fast.

this is normal 1r5 tasks have always reached 99 decoys fast. I am unsure as to why this is the case though.Have a crunching good day!!

just a comment about these (lr5_E_yf_chbond_05_rlbd_1bq9_SAVE_ALL_OUT....) tasks. for me they go very very quick. had 99 decoys in 1hr and 17 mins on one task. think that is the fastest i have ever done 99 decoys. another one reached 99 in 2hrs plus. still very fast.

this is normal 1r5 tasks have always reached 99 decoys fast. I am unsure as to why this is the case though.

looks like it is just the yf tasks that have this speedy result. i had a new icoor task that ran the full 4hrs. yf must be a simple task.

My client (works only with rosetta) can\'t get any work units.
It is saying that I need 39 Gb of space.
(And that requirement is increasing. Every time it connects to get work units it asks for slightly more space.)

I\'m running task lb_alnmatrix_threading_alncap__hb_t313__IGNORE_THE_REST_12577_3074_0 right now. The elapsed time is over 11 hours now, predicted are another 30. This was the same with lr5_D_rama_map_iter05_rlbn_1kpe_SAVE_ALL_OUT_NATIVE_NOCON_12603_60_0_0. The outcome is nothing really special so I wonder if this is normal. Usually, at least in the previous version, I needed between 3 and 5 hours for a task.
The current task\'s graphics also cannot be displayed. This is all a bit strange - is it due to the new minirosetta version?

(By the way, I\'m running a Vista64 system with 2x3,25 GHz and 4Gb RAM)

Looks like BOINC thinks you\'re running on 8 CPU cores. Do you actually have that many, or is hyperthreading making it look like you have twice as many as you actually have? Hyperthreading allows BOINC to use any cpu time that the other workunit on the same cpu core does not use, but BOINC is unable to keep good track of which workunits use now much CPU time when hyperthreading is in use.

Also, I\'d expect the total memory requirements to be increased when that many workunits are trying to run at once. Just how much RAM memory do you have?

I traced through your aborted workunits to the information BOINC maintains about your computer. It thinks you have 8 CPU cores and 4 GB of memory. I\'ve found that at least under Vista SP1, you need at least 1 GB of memory per CPU core to run minirosetta, and some of those WCG programs, at full speed. Is your motherboard capable of handling another 4 GB of memory, and can you afford it?

WARNING - don\'t use the usual Crucial program for telling how much memory your motherboard can handle under any 64-bit operating system, unless you\'re prepared for an immediate operating system crash. It seems that program hadn\'t been adequately tested under 64-bit operating systems the last time I tried it on my 64-bit machine.

By default, BOINC won\'t use more than about half the available memory unless you go out of your way to tell out of your way to tell it that it can. Therefore, just currently not using much more than half of it doesn\'t mean that BOINC has enough for the workload you\'re giving it. To check how much effect this has, try running BOINC with the setting not to use more than half your CPU cores at a time, and see how much effect this has on the speed at which minirosetta workunits run.

On my 2 CPU core 32-bit machine, I found that either the default of 10 GB disk space or the default settings for how much swap space BOINC could use weren\'t enough. It\'s hard for me to tell which, because I changed them both at once.

I\'d suggest that you change only one of these at a time, and record what the effects are:

1. Increase the disk space to 10 GB times the number of CPU cores. Expect BOINC to divide the allowed swap space equally among all the BOINC projects it\'s been told to connect to, before deciding how much to allocate to each workunit. Therefore, some BOINC projects can run short of swap space, while others aren\'t using all they\'re allocated.

2. Allow BOINC to use a higher percentage of the swap space, since BOINC is probably all you\'re running on that machine that needs much swap space, and Vista will base the total size of the swap space on how much of it is used.

Note that when the number of apparant CPU cores has been doubled by hyperthreading, you cannot run all of the new number at full speed at the same time, and BOINC has problems judging how much CPU time is used on one of a hyperthreaded pair when the other member of the pair is also in use. Therefore, don\'t expect hyperthreading to increase your total throughput very much over using only one member of each hyperthreaded pair.