Taking some liberties with the details of all this to save space I will jam a few of the FAQs from the FAQ list together to try to make this clearer-

All of the new format WUs are generally physically (number of bits) the same size. The time factor tells the system how long you would "like" your system to work on a single WU creating different models as it goes. Based on the benchmarks done for that class of WU when they were created, the server knows how many models can be run for that WU in the time you asked for. In every case the WU will run at least one model no matter what you set the time to be. In any case your computer will be told how many models to run before returning the result as a part of the data that comes with the work unit. For small proteins this could be 30 models in 4 hours, for large proteins it might only be 1. In some cases it might take 9 hours to run a single model, and your system will spent 9 hours on the WU no matter what your time setting is, because all WUs run at least 1 model.

You can judge for your self if the protein you are working on is large or small by looking at the graphic. If there are a lot of "joints' in the protein, long strings, and it looks complex, it is large. Obviously small would be the opposite of that.

From a user stats point of view each WU represents a single result when it is turned in. The longer it runs the more credit it will claim. But from a science point of view each "model" represents a single result so each of your turned in results can represent anywhere from 1 - 100+ science results. That is why the default time is set to 8 hours (more science per WU). In most cases this will return between 1 and about 100 results depending on protein size. The faster the system the more models it can run in the alloted time. Because the models differ in size there is no way to calculate the number of credits per model. It is possible to make an estimate of credits per hour per system. The work unit itself has no bearing on this at all.

All of this means simply this. The project used to be based on having each WU produce a specified number of models for each protein run, no matter how long that took. say 60 models per WU. Now the system is set up to run for a certain length of time, no matter how many protein models that might produce per Work Unit, but it will always complete at least one model for each WU no matter how long that takes.

Now this can lead people to think they have a WU stuck when they don't. Depending on how the Wu is configured, some may have over 1,750,000 steps in the first model and still not reach 1%. This can take over 5 hours of CPU time. There are a few even larger ones.

The time settings in your preferences have a lot to do with what the jumps in percent complete will be as the WU progresses. If you have your time set to say 2 hours, and one of the large WUs comes along, it is possible for it to run for well over five hours showing 1%, and suddenly jump all at once to 100% and finish. If the Wu is one of the smaller ones, running with the same settings, it might only run 5 min or less, doing about 35,000 steps for each model, and the percent will jump to something like 5% and keep rising until it hits about 1 hour and 55 mins and finishes. By the way, that first 1% is the set up at the begining of the WU run. You can see that in the grafic display if you have it up when a WU first starts.

So look at the graphic display and see what is going on every so often on these longer ones.

The project has said they are working on "leveling" all of this out so there is not so much variation. Those WUs should start appearing soon.

So now we get to the problem of forcing the system into a work deficit when you use the new Rosetta time feature.

BOINC does not know anything about any of what I just described. A lot of people who are used to the normal way BOINC controls the loading of the work Queue still have their systems set to a long connect time to get more WUs. But for the new Rosetta system this can cause you trouble, and it is unnecessary.

BOINC will ask for a certain amount of work (number of seconds of work) based on how much time you have left in your work queue. But it does not know that you can download what seems like a very small number of rosetta WUs, that in fact are large in terms of time because you have set the time for rosetta to a large number.

BOINC just downloads the WUs and suddenly they are taking a lot longer than BOINC expected. Now to be fair BOINC will adjust a little for this as it runs. And for short connection times (small work queues) it will adjust fairly well over a day or so, because it will figure out that the WUs are all about the same size and it will adjust the DCF to make things work.

So, For Rosetta it might be best for farmers and people on low bandwidth, or modems who run only rosetta to readjust the system for a small queue. Say .1 days. Then set the time factor for a long runtime say 2-4 days. This will allow BOINC to think it should just get a few seconds of work to keep your system going, but it is really getting one or two WUs that will run for 2-4 days each. BOINC of course will try to connect about every 2 hours or so all day long, but if you are not connected (turn off network activity) or turn off your modem, it will just hold the results until you do connect. BOINC will take care of holding the results until then.

Now if you are on a constant internet connection with these same settings, BOINC will be connecting nominally the same 10 times a day, but it will just keep crunching rosetta for the same 2-4 days per WU until they are done. If you are running other projects under these conditions, they will be feeding and reporting all day long on the shorter queue using the standard BOINC reporting and queueing system.

So basically you have to play with the two parameters of Times to connect per day (queue size) and run length of the WU (Rosetta time setting) until you find the balance that fits your particular system requirements.

One caution of people who pay connection time by the packet is that if your connect time is set to a short length, it will send a few packet every time it tries to connect, but this should not be a large number. For people interested in local credit monitoring with the BOINC GUI stats tab, the stats will be more current.

Sorry for the length of this post but this is not standard BOINC functionality and a lot of people are confused by it. So it deserves some explanation.

---

Moderator9
RALPH@home FAQs
RALPH@home Guidelines
Moderator Contact