the current server problems are likely due to the fact that the latest abinitio runs were sent out with nstruct 10 rather than nstruct 50 to avoid the max time problem, but this is creating too much traffic for our web server as some of the jobs are very short.

David Kim has a very nice fix for all of the work unit time related problems. The new app will have a default target run time of 8 hours, and this rather than -nstruct will determine how many structures are generated per work unit. You will be able to change this target run time to fit your individual preferences--dial up users may wish to make this somewhat longer to reduce traffic still more.

We are also increasing the work unit turnaround time limit from one week to two weeks on most jobs. really high priority calculations will still get the one week maximum, but these we will try to keep in the minority.

---

Great, Great news. Good job.

Now I'll be able to suggest to others to run Rosetta, because I was concerned that they would start and drop from the project soon afterwards, due to the traffic requirements.

Any chance for an optimised app? ;-)

---

Best UFO Resources
Wikipedia R@h
How-To: Join Distributed Computing projects that benefit humanity

....and what is happening on the WU size front? Is compression not far away to reduce the bandwidth required?

....and what is happening on the WU size front? Is compression not far away to reduce the bandwidth required?

(David Baker) You will be able to change this target run time to fit your individual preferences--dial up users may wish to make this somewhat longer to reduce traffic still more.

I believe that if we can increase the run time of each WU, that should do a lot to help this, effectively getting more compute time done for each megabyte downloaded.

Mostly to David, but if this change happens, how will we be able to control this?

Or did I completely miss the point?

---

....and what is happening on the WU size front? Is compression not far away to reduce the bandwidth required?

(David Baker) You will be able to change this target run time to fit your individual preferences--dial up users may wish to make this somewhat longer to reduce traffic still more.

I believe that if we can increase the run time of each WU, that should do a lot to help this, effectively getting more compute time done for each megabyte downloaded.

Mostly to David, but if this change happens, how will we be able to control this?

Or did I completely miss the point?

I believe that that users may be able to control this editing your rosetta@home preferences

However I did edit my preferences for home and did not find this option yet
*nor on global preferences nor on rosetta preferences

BTW: Is need a option to control how many streams for (up/dl) the client app
opens simultaneus --- actually it opens 2 streams
and that 2 files transfers at the same time, is clogging my 14400 bps dialup
blocking me to surf internet while download -or- upload occurs

*If it transfers 1 file at each time my access to internet would not be blocked
and all transfers will occurs quickly w/o too frequent upload/download errors

be understand correct -> I have 2 files to upload -or- download
actually app try sendind -or- receiveing the two files simultaneously

what is need is: upload 1 file, when this upload done, then upload the 2nd file
*the same for downloads

---

Click signature for global team stats

BTW: Is need a option to control how many streams for (up/dl) the client app
opens simultaneus --- actually it opens 2 streams
and that 2 files transfers at the same time, is clogging my 14400 bps dialup
blocking me to surf internet while download -or- upload occurs

*If it transfers 1 file at each time my access to internet would not be blocked
and all transfers will occurs quickly w/o too frequent upload/download errors

be understand correct -> I have 2 files to upload -or- download
actually app try sendind -or- receiveing the two files simultaneously

what is need is: upload 1 file, when this upload done, then upload the 2nd file
*the same for downloads

This is a boinc client issue not a rosetta client issue, so you should post on the boinc msg boards.

---

Mostly to David, but if this change happens, how will we be able to control this?

When this was initially discussed, I believe it was said that there would be a section added to the rosetta preferences page.

Similar to say what CPDN has done... CPDN has added a graphics section to control their screensaver.

---

....and what is happening on the WU size front? Is compression not far away to reduce the bandwidth required?

(David Baker) You will be able to change this target run time to fit your individual preferences--dial up users may wish to make this somewhat longer to reduce traffic still more.

I believe that if we can increase the run time of each WU, that should do a lot to help this, effectively getting more compute time done for each megabyte downloaded.

Mostly to David, but if this change happens, how will we be able to control this?

Or did I completely miss the point?

you will be able to control this, and we will post instructions as soon as the new app is released later this week

---

I just got some of thses units with the 8 hr. run time and 2 week deadline. Just started running one, will be able to tell after that if it takes much longer.

---

Pizza@Home Rays Place Rays place Forums

sounds great .

I always like to hear that our feedback is listend to and is important

thanks for the updates

---

IS there any way we can get rosetta to purge old or past due work units with out suspending and aborting them on our machines.I have several that have been running older units that are the past due date time.This needs to be adressed for the people running farms.

---

i know that you can manualy delete the old Work Units

I am sure there would have to be an update to the BOINC code to make it posible to remove past due work units though. (i could be wrong though)

---

Since the change to WU matched to processing time to minimize transfer losses, I have seen my daily averages and my overall average WU/day soar. I also noticed the total project Teraflops go up. Good move. I noticed that the number of pending WU is much lower on each machine. I assume this is also good for the project, since there is less work at risk of a lost/delayed machine, you will be able to lower the level of redundant WU's sent out to insure total coverage. Net higher throughput and higher reliability.

---

.... you will be able to lower the level of redundant WU's sent out to insure total coverage. Net higher throughput and higher reliability.

Yuo cannot get lower than one to send out.....the redundancy level is currently one....

---

Since the change to WU matched to processing time to minimize transfer losses, I have seen my daily averages and my overall average WU/day soar. I also noticed the total project Teraflops go up. .

great! the solution that David Kim is working on now should catch most of the remaining errors

---

would it be possible for someone to write in a script that would automatically abort a wu if it's stuck at 1% for more than say an hour? for those of us running farms this would be a godsend until the 1% stall problem is solved.

---

I'd second the automatic abort thing, sounds like a great idea until such time as the bug fix is worked out.

I would think that the script would probably be needed for Boinc manager rather than the Rosetta client as it's the manager that handles individual jobs.

Would this be feasable?

It would certainly ease the presure to get a fix in place for those of us have have farms and are running out of patience...

---

When I created this thread, I was only thinking of myself, and other crunchers.

https://boinc.bakerlab.org/rosetta/forum_thread.php?id=1287

But, the subject, better compression of the files you send out, would help to relieve some of the stress on your servers when "crap happens". As well as decreasing your bandwidth during normal times...

---

would it be possible for someone to write in a script that would automatically abort a wu if it's stuck at 1% for more than say an hour? for those of us running farms this would be a godsend until the 1% stall problem is solved.

I just yesterday emailed David Anderson asking whether such a feature could be incorporated into boinc. haven't heard back yet. if someone can figure out how to do this outside of boinc it would be great.

---

would it be possible for someone to write in a script that would automatically abort a wu if it's stuck at 1% for more than say an hour? for those of us running farms this would be a godsend until the 1% stall problem is solved.

I just yesterday emailed David Anderson asking whether such a feature could be incorporated into boinc. haven't heard back yet. if someone can figure out how to do this outside of boinc it would be great.

Any word back yet? There is a lot CPU time being wast evey day by this

---

If You Want The Best You Must forget The Rest
---------------And Join Free-DC----------------