Yep, each task will still have the same required download files, but you will be able to spend much longer working on each task. And because your machine is happily working on stuff, it doesn't contact the project as frequently for more work and etc. So, overall, the number of MB used per month drops. Good for the Rosetta servers, good for your bandwidth, good for your ISP.

If BOINC's use of the network is conflicting with your use of your computer, you can either schedule network access to specific times of day (be sure to request enough work on hand to keep your machine busy during the times it is not allowed to use the network), or you can set limits on the data rate you allow BOINC to use for uploads and downloads. By setting it to, for example, half of your maximum speed, it assures BOINC always leaves half of the pipe available for you to do your downloads, surfing, etc.

Yep, it is the amount of CPU time you would PREFER to have each task run. The longer you let them run, the more models they complete from the starting point of that task. More models = more science results. So you get more work done with the same downloaded files. The resulting upload is proportionately larger based roughly on the number of hours you spend crunching on it. So upload per WU is larger, but per day is not.

I put PREFER in caps, because it is not an upper limit. Some tasks can and will exceed your preference. Rosetta has a watchdog in place to assure they don't exceed it by more then 4 hours. Otherwise the watchdog will mark the task completed and report it back. In general, it does a great job of meeting your preference, so long as it is 3hrs or more.

The problem people can get in to is just that if you have 50 WUs already on your machine, the runtime for all of them will increase when you change the setting. And this can lead to missing deadlines. So it is best to change when number of WUs is low. And yet don't go overboard because BOINC still hasn't seen how long the new tasks take, so it orders work assuming they'll take about as long as they have historically (i.e. 3hrs). So even if your slate of work is empty, BOINC can still end up requesting too much because when it requests 24hrs of work, it will get 8WUs, not knowing that they EACH will now take 24hrs (or the time of your new preference).

The opposite can also be a problem. If you have a 24hr preference and then want to drop it down, the running tasks on your machine will try to comply with the new preference. If your new preference is 6 hrs, then the watchdog sees the task that has been running for 10 or more hours out of what was originally 24 as having run "too long" (i.e. exceeds the new 6hr plus 4hrs of total runtime allowed) and wraps it up.

So simplest thing is just to only change the preference a notch or two each day or longer. This helps BOINC request approximately the proper amount of work, and helps the watchdog stay out of the way.

What queue setting do you guys run with? .. I'm thinking of putting 4-5 days cache or something like that... Should be enough...

If you have other projects configured, I would leave the 1/2 to 1 day queue. On the other hand, if you get one climate task per CPU, your machine will be committed for some time to climate. Just depends upon what you desire your resource shares to be. I always felt I had to set climate to no new work whenever I got a task, because BOINC would sometimes try to get more, and I didn't want to crunch them.

If you are crunching 24/7 now, I would also suggest (while your queue of work is small) that you increase your runtime preference. This is done in your account profile, in the Rosetta preferences. I generally recommend only make gradual changes to runtime preference. But once you get it bumped up to 12 or 24 hours, this will reduce your traffic to the servers, and also tend to keep your machine happily crunching through most periods where work is not available (which typically only last less then a day, depending on the cause).

Have you run out already?

Why would you increase your queue if none are coming down? That would just increase the number that don't come down. It's only worth increasing your queue AFTER the problem's fully fixed and IF you've run out. This is what your queue is for.

If you increase your queue you only prolong the number of people who are without work (if any). Another solution may be to increase your run time a little.

your Xeon scores do look low - I'd recommend limiting the number of running Rosetta processes to the number of physical CPUs per box (setting available under BOINC preferences). I would expect that hyperthreading would have a beneficial effect by letting other processes run along-side Rosetta more smoothly, but with the added advantage that two Rosetta processes aren't competing for cache.

HTH
Danny

I can make a change to show my machines. But one question. Will the hostname of the machines be showed?

no - you can only see the hostname and IP if you're logged in.

with Hyperthreading on the Xeon, the CPU time won't be increasing at wall-clock speed - it'll be running somewhere around half that, so although two jobs are running at once, they'll both be running at half the speed, I'd expect. You might get some benefit from HT over running a single copy, but I don't think it's much (as far as Rosetta is concerned anyway, as the CPU only has limited FPU resources and that's what Rosetta is heavily dependant upon).

Not sure how much you know about how Rosetta packages tasks up, but in case you don't, two jobs that run for, say, 8hrs on a fast machine and a slow machine won't get the same credit, because the fast machine will generate more models (decoys) within that 8hr task. Basically a computer will run as many decoys within a task until it can't fit any more decoys into the time limit, so two 8hr tasks aren't necessarily equal. Each decoy is credited the same, so the granted credit is the credit per decoy multiplied by the number of decoys reported.

Your Celeron will process more decoys within a task than your Xeon will, although your Xeon is doing four at once. Your computers are hidden so I can't be any more specific though...

HTH
Danny

are the xeons using hyperthreading?

The Celeron is one of the few Celeron's that is actually a pretty good CPU as it's based on Conroe. It'll be a much more efficient cruncher than the P4 based Xeons so you'll get more per cycle from it...