I get this message.

2006-09-01 16:40:33|rosetta@home|No work from project

Anybody?

Anders n

---

Getting same here - do the admins know?

---

If you go to the R@H homepage (top right corner, "Server Status"), presently it says 6 wu's in queue.

Usually, theres a few thousand.

Getting same here - do the admins know?

just emailed DK incase they don't know about it...

---

I've emailed the staff, it's just after 8am here so it may take a bit for the coffee to kick in.

---

it's just after 8am here

Are you guys not in Washington?

---

TestPilot, AKA Administrator

it's just after 8am here

Are you guys not in Washington?

They are in Seattle in the State of Washington, not Washington D.C.

Now that CASP is over and the turnaround times are not so critically any longer I suggest to increase the work buffer again in order to have for a longer time work available even if the make_work_process dies. Although it was requested to increase the deadline again to 2 weeks (or 10 days).

I've submitted 11,000 new work units to the queue, the home page should be updated soon. I'll put a quick message into the Active Workunits Thread in the next hour. Thank you all for keeping an eye on this, and my apologies for letting the workunit queue run dry.

Increasing the buffer is a great idea, I'll talk to David Kim about doing this.

Cheers,

James

I get this message.

2006-09-01 16:40:33|rosetta@home|No work from project

Anybody?

Anders n

---

Now that CASP is over and the turnaround times are not so critically any longer I suggest to increase the work buffer again in order to have for a longer time work available even if the make_work_process dies. Although it was requested to increase the deadline again to 2 weeks (or 10 days).

Hey Tralala -- Noticed you once mentioned a reason you liked Rosetta was
"User setable length of Work units!"

Unfortunately, I'm not finding where that setting is.
In general preferences, or in boinc manager, or?

---

You'll find this feature in 'Your account' > Rosetta@home preferences > Target CPU run time.

You'll find this feature in 'Your account' > Rosetta@home preferences > Target CPU run time.

Thank for that. In trying to keep my computers from waiting for work, perhaps you can recommend a very short or very long interval to maximize work done?

For context, the machines have lots of cpu power, terabytes of disk, T3+
networks, and are 100% testing/dedicated to Rosetta. Seem to return a
result approx. every 2.5 hours and have 4-8 cores each.

---

You'll find this feature in 'Your account' > Rosetta@home preferences > Target CPU run time.

Thank for that. In trying to keep my computers from waiting for work, perhaps you can recommend a very short or very long interval to maximize work done?

For context, the machines have lots of cpu power, terabytes of disk, T3+
networks, and are 100% testing/dedicated to Rosetta. Seem to return a
result approx. every 2.5 hours and have 4-8 cores each.

In order to not run out of work you may want to increase your reconnect time. This is in your general settings: "Connect to network about every"
(determines size of work cache; maximum 10 days). Standard is 0.1 you may want to up this to 0.5 or even 1. More is not needed a downtime of more than 24 hours is not likely.

SG Tralala just posted what I was going to. But I wanted to also point you to the caution mentioned in the QA item on the WU runtime pref. Basically, don't change BOTH your WU runtime preference and General preference for connect every ...days at the same time nor in large steps.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

SG Tralala just posted what I was going to. But I wanted to also point you to the caution mentioned in the QA item on the WU runtime pref. Basically, don't change BOTH your WU runtime preference and General preference for connect every ...days at the same time nor in large steps.

Tralala and Feet1st:
Thank you, that is most helpful in getting a quick understanding of maximizing these computers for the purpose of the results to Rosetta. (ah, the beauty of community...)

Your data suggests setting runtime to 1 day & reconnect to 2 days. If anyone
has a better idea, I'd appreciate hearing it. Our compute environment:
- Each computer = 2x/4x fast Opteron; dual-core; 1Gig memory/core
- 4-12 terabytes of disk per computer; RAID5
- multi-T3 network,
- 100% dedicated to Rosetta, as each computer is brought through testing.

---

Your data suggests setting runtime to 1 day & reconnect to 2 days. If anyone
has a better idea, I'd appreciate hearing it.

That is a great suggestion.
It should work for you, very nicely.

~Joel

Your data suggests setting runtime to 1 day & reconnect to 2 days. If anyone
has a better idea, I'd appreciate hearing it.

That is a great suggestion.
It should work for you, very nicely.

~Joel

Thanks, Joel. Hope this gets more work done...the true objective. We only
powered on current computers on Aug. 21. Gratifying two weeks. Will be good to
see the actual Rosetta results with a testing node at 1/2 power. [128 cores vs.
32 now) And in few months w/quad-cores. [256 cores=full node]

We remain open to more suggestions to optimize for actual work results...

---

Be sure, but I'm sure it's done, to select 'Leave applications in memory while suspended'. This is important but only if you run several projects.

Getting a "no work sent" message from the Rosetta servers, due to "reached
daily quota." This may be a simple problem to fix, but hasn't been easy so far (looked in FAQ's, etc.). It only effects the faster (8 core) machines, all the others are getting and crunching jobs just fine.

Any suggestions on how to get new jobs to these big idle machines??

[quote]
Your data suggests setting runtime to 1 day & reconnect to 2 days. If anyone
has a better idea, I'd appreciate hearing it.

That is a great suggestion.
It should work for you, very nicely.

~Joel

---

the daily quota is per cpu(core), not per machine.
errors and aborted WUs decrease the quota, valid returned WUs increase it again.
quick dirty workaround would be reset project (or re-attach? not 100% sure there), but find out why the quota got down that far first. :)